Age | Commit message (Collapse) | Author | Files | Lines |
|
The SOME/IP dissector did not update its dynamic hf config, after a
config changes. This patch fixes this by updating the internal data
after the UAT post update CB.
Closes: #17197
|
|
Added to the protocol a new option to display the decimal representation
of floating-point values.
Minor fixes: Avoid the double 'return' on dissect_goose_UtcTime function
and fix the simulation BLURB to follow other fields approach.
|
|
S1G adapters should be shipping soon since Silex America has a dev-kit
available, so it is about time to add support for this.
Change-Id: I0225d87f78efbcbe88476921d4fce3d56a3ce0cd
|
|
This has been tested with captures I have from WFA. There is some additional
stuff I want to add to capture info about STAs that support SAE as well, but
will need another commit for that.
Change-Id: Iafbba52094856192e63a21f1c32bb7d785221d66
|
|
Update manuf, services enterprise numbers, translations, and other items.
|
|
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
|
|
For sip, we have two different statistics tables for requests and responses.
Create each table only once, check if it already exists.
|
|
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
|
|
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
|
|
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
|
|
Pull the code to register plugin taps, and the loop to register built-in
taps, into a single register_all_tap_listeners() routine.
This leaves it up to libwireshark, not to the programs using it, to know
how to register them.
|
|
Working on #6683 introduced this bug because of a lack of
control on the conditions when calculating in-flight.Closes #17186.
|
|
Config.h must not be installed so configuration must be performed by client code.
Fixes #17190.
|
|
|
|
If you load a capture file and open any statistics dialog, you'll see the
list of collected items. Each time you press the Apply button (without entering a
display filter) another list of items will be created as a top-level entry
of the statistics tree. Only the first list will have the correct values,
all subsequent lists will not be populated.
Each statistic module defines a stat_tap_table_ui structure that contains a
stat_tap_init_cb function. This init function is called by
SimpleStatisticsDialog::fillTree before the tap listener is registered. This
happens each time we collect the statistics.
However, it seems that all init functions create a new stat_tap_table each
time they are called, even if they already have an existing stat_tap_table
of the same name.
This patch adds a stat_tap_find_table function to find a table by name.
As a first step, we update the ANSI A-I/F BSMAP Statistics to check if its
table is already registered. If it is, the table will not be created again.
|
|
from 802.11ai(-2016).pdf
Closed: #17135
|
|
|
|
Fix for previous fixes to #17179.
|
|
It has the "feature" that, if handed a negative value, it might just
exit. gmtime() doesn't have that "feature", and is sufficiently
thread-safe for our purposes; use it instead, and check to make sure it
doesn't return a null pointer.
The previous fix for #17179 still used gmtime_s(); this doesn't, so it's
a better fix for #17179.
|
|
At least on Windows, gmtime_s() will *not* succeed if passed a negative
value.
Fixes #17179.
|
|
An invalid signature ("a{sa}") caused a segfault when the array inside
the entry had a length of zero. An array signature code ("a") must be
followed by a single complete type, and "}" is not one of them. Check
additional restrictions for structs and dict entries, which aren't
related to this bug.
Fixes #17176
|
|
This triggered a dissector bug:
epan/dissectors/packet-dbus.c:796: failed assertion "DISSECTOR_ASSERT_NOT_REACHED"
Fixes #17176
|
|
Not popping all subtrees triggers a dissector bug:
epan/proto.c:1136: failed assertion "ptvc->pushed_tree_index == 0"
Fixes #17176
|
|
Fixes #17177
|
|
It corresponds to LINKTYPE_ETW in pcap and pcapng files; the structures
in the record format come from the Event Tracing for Windows (ETW) API
rather than directly from Event Trace Log files.
While we're at it, explain what extcap/etl does.
|
|
|
|
Replace the somewhat weird field format
"[Checksum: [missing]]"
with
"Checksum: 0x0000 [ignored or illegal value]"
Improve code redability and fix XXX comment.
|
|
Closes #16972. See also #6232.
|
|
In Git's packfile transfer protocol[1], the initial server response
contains the version of the Git Protocol in use; version 1 or version 2
[2].
Parse out this information following up on work started in MR !805 [3]
by Izabela Bakollari and advice provided by Ronnie Sahlberg, add it as a
field for ease of reading and filtering.
[1] https://www.kernel.org/pub/software/scm/git/docs/technical/pack-protocol.html
[2] https://www.kernel.org/pub/software/scm/git/docs/technical/protocol-v2.html
[3] https://gitlab.com/wireshark/wireshark/-/merge_requests/805
Related to #17093
|
|
|
|
This fixes issue #17182.
|
|
According to the LINKTYPE_BLUETOOTH_BREDR_BB Packet Structure specification
(http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html), the
Bluetooth header should be formatted according to the Bluetooth
specification Volume 2, Part B, Section 6.4. However, right now
wireshark expects the header to be in a weird format,
specifically it expects the header fields to be MSB but the bits
within each header field to be LSB. (Bluetooth standard is all
LSB). Furthermore, it computes the HEC (header check, i.e. the header
CRC) with 4 bits arbitrarily masked.
This patch decodes the header according to the spec. It still accepts
the old format (if the broken HEC matches), and displays a warning.
|
|
|
|
|
|
Occured when a control procedure packet was logged without connection
context.
The bug was introduced in 0dab2494ca5e20c5ab90ea7fbe11ada1316e41ee
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
|
|
|
|
TCP in flight calculation was based on Sequence analysis only.
We now also look at the SACK blocks and give a more accurate
view of the in flight reality. Closes #6683.
|
|
See Bluetooth Core Spec, Vol 6, Part B, Section 5.3
If the event counter is available, the procedure is marked as complete
when the instant is reached.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
|
|
|
|
10204490d7 / MR 80 ensured that we didn't grow field.usages due to an
underflow, but it neglected to check for a sane array size. Add another
check to make sure we don't wmem_array_grow() too much. Fixes #17165 and
fixes #16809 more completely.
|
|
Replace mismatched g_strdup() + g_free()s with
wmem_strdup_printf(wmem_packet_scope(), ...). Fixes #17124.
|
|
|
|
- fixed some datatype issues (detected by scripts of gitlab environment)
- shift some flag informations of info-column
|
|
Reference: https://www.rabbitmq.com/resources/specs/amqp0-9-1.extended.xml
It's obviously a copy paste error from way back, but method id 51 is what
rabbitmq sends back on Exchange#UnbindOk so they've kept the "error".
|
|
Fixes Coverity 1472261
|
|
This makes it easier to read logs where both the master
and slave initiate control procedures at the same time.
Retransmitted packets are not part of the request/response
tracing.
In order to perform the analysis, direction information must
be available.
The matching is implemented by storing control procedure contexts
for each direction for each connection object as each direction
may initiate its own procedure.
Limitations:
- When there is a control procedure violation where a device
initiates a new procedure before the previous is complete,
only the first procedure is traced.
It would be possible to create more advanced tracing by
storing a list of contexts per frame.
However, as this is anyways a specification violation, this
adds unnecessary complexity.
- Control procedures involving an instant are marked as completed
when the last frame is sent even though the control procedure
is completed when the instant is reached.
This is the best possible approach when the event counter is
not available.
Due to this limitation, we are not able to detect the control
procedure violation where a device initiates a new procedure
before the instant is reached.
The following control procedure violations are detected:
- Starting a control procedure before the previous is complete.
Control procedure violations where a new procedure is started
before the instant is reached is currently not detected.
That requires knowing the event counter.
- Control procedure packets that are not valid responses to an
existing ongoing control procedure.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
|
|
Update manuf, services enterprise numbers, translations, and other items.
|
|
|
|
./tools/check_typed_item_calls.py --commits 1 | tee item_calls_check.txt
Examining:
epan/dissectors/packet-vnc.c
epan/dissectors/packet-vnc.c:1289 proto_tree_add_item called for hf_vnc_tight_tunnel_type - item type is FT_UINT8 but call has len 16
epan/dissectors/packet-vnc.c:1532 proto_tree_add_item called for hf_vnc_vencrypt_auth_type - item type is FT_UINT8 but call has len 4
epan/dissectors/packet-vnc.c:1545 proto_tree_add_item called for hf_vnc_vencrypt_auth_type - item type is FT_UINT8 but call has len 4
3 issues found
As explained here:
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#tight-security-type
The capability consists of a code, a 4 byte vendor string and an 8 byte signature string
|
|
|