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.
Python only creates the default argument once and reuses it for
further invocations. Instead, of mutating the default list,
set the default argument to be None and then create a
list, if needed. For more info, see
https://docs.python-guide.org/writing/gotchas/
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>
extcap_register_preferences is only called with the -G option
(to dump information) and extcap preferences are not loading,
loading it unconditionally avoids this, as it is done in the
GUI startup.
./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
Try to fix
run/libwireshark.so.0.0.0: undefined reference to `dot11decrypt_derive_pmk_r1'
run/libwireshark.so.0.0.0: undefined reference to `dot11decrypt_kdf'
run/libwireshark.so.0.0.0: undefined reference to `dot11decrypt_prf'
run/libwireshark.so.0.0.0: undefined reference to `dot11decrypt_derive_pmk_r0'
run/libwireshark.so.0.0.0: undefined reference to `dot11decrypt_derive_ft_ptk'
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
IEEE 1733 uses a 32bit 802.1AS (gPTP) timestamp in RTCP. In order
to correlate these timestamps to the timestamps in 802.1AS the
following translation is needed:
ts_32 = (ts_s * 10^9 + ts_ns ) mod 2^32
This patch adds suport for this 32bit timestamp in order to allow
analysis of AVB with IEEE 1733 (RTP/RTCP).
Guy Harris
Vadim Yanitskiy