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
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.
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
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.
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 0dab2494ca
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.
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>
./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
This patch allows each configured parameter to be filtered and
therefore to be used in io graphs as well.
Fixes#17122
Be aware that this patch changes the format of:
- SOMEIP_parameter_list
- SOMEIP_parameter_arrays
- SOMEIP_parameter_structs
- SOMEIP_parameter_unions
Specification:
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vencrypt
Has been tested with tigervncserver / xtigervncviewer
with several security types and combinations:
/usr/bin/tigervncserver -SecurityTypes VncAuth
/usr/bin/tigervncserver -SecurityTypes TLSVnc
/usr/bin/tigervncserver -SecurityTypes X509Plain
/usr/bin/tigervncserver -SecurityTypes TLSVnc,VncAuth
Dr. Lars Völker
Vadim Yanitskiy