The GLib documentation says G_STRLOC includes the function name
but that is a lie[1]. Change ws_debug() to not use G_STRLOC and receive
__FILE__, __LINE__ and G_STRFUNC separately instead.
[1]https://bugzilla.gnome.org/show_bug.cgi?id=69097
The esp_sa_record_add_from_dissector function is passing a null pointer to
the err argument of uat_esp_sa_record_update_cb, which then dereferences
it. Apparently esp_sa_record_add_from_dissector is not called anywhere in
Wireshark, but it's exported and available for external code to call it.
Fix by passing a pointer to a local char* instead.
Bug found by clang static analyzer.
The selectedProtocol field in RDP_NEG_RSP packets was not handled correctly,
it's a single value not some flags.
RDSTLS has also been added in the protocols list.
clientRequestedProtocols in TS_UD_SC_CORE has also been adjusted as it's supposed
to be the list of supported protocols sent by the client in the RDP_NEG_REQ packet.
So it's union of flags, not a single value.
VLAN_MAX_NESTED_TAGS is a misnomer, it sets a maximum on the total
number of tags in a packet, nested or not. It's possible to surpass the
current value of 10 with legal packets, e.g. jumbo frames that carry
entire DVB Base Band Frames with GSE (or TS/MPE) that have fifteen
PDUs each with a IP/VLAN/ARP. Raise it to a somewhat higher but still
small finite limit.
DSACK blocks (the first SACK block in a TCP SACK option, with right edge
being lower or equal to the ACK filed) are now identified correctly.
Closes#17315
Add support for Transport Streams carried over DVB Base Band Frames,
passing them to the MP2T dissector. Add an endpoint type for the ISI.
Update comments. Use standard true false strings in a couple cases.
Create a header file for MP2T, since the BBFrame dissector needs to
know about the MPEG2 TS packet size and sync byte.
Move compiler information from last sentence to "compiled with"
paragraph.
Before:
Compiled (64-bit) with ...
Running on Linux ...
Built using gcc 11.1.0.
After:
Compiled (64-bit) using GCC 11.1.0, with ...
Running on Linux ...
When byte escape sequences, that is hex \xhh or octal \0ddd,
are interpreted at the lexical level it is not possible to
use strings with embedded NUL bytes. The NUL byte is interpreted
as a C string terminator. As a consequence, for example, the
strings "AB" and "AB\x00CDE" compare as the same. This leads to
unexpected false matches and a poor user experience.
Disallow embedded NULs for regular strings (strings literals that
do not begin with 'r' or 'R') for this reason.
It is possible to use a raw string instead (eg: r"AB\x00C")
to match embedded NUL bytes, although that only works with regular
expressions. Normal escape rules would also work with regular
expressions (eg: "AB\\x00C"). This is the same string as the previous
one, written in an alternate form. What won't work is "AB\x00C", this
string is synctatically invalid.
So the expression: data matches r"AB\x00C"
will match the bytes {'A', 'B', '\0', '\C'}.
However the expression: data contains r"AB\x00C"
won't match the fvalue above. Because the "contains" operator
doesn't compile a regular expression it literally tries to
contains-match the bytes {'A', 'B', '\\', 'x', '0', '0', 'C'}.
Therefore raw strings are very convenient but it is still necessary
to be aware that the matches operator has an extra level of indirection
than other string operators (same as in Python).
Fixes#16156.
Add support for a literal string specification copied from Python
raw strings[1].
Raw string literals are enclosed with r"..." or R"...". Double quotes
can be include in the string but they must be escaped with backslash.
In escape sequences backslashes are preserved in the final result.
So for example the string "a\\\"b" is the same as r"a\"b".
r"\\\a" is the same as "\\\\\\a".
Raw strings should be used for convenience wherever a regular expression
is used in a display filter expression.
[1]https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
Create a tvbuff that covers the data portion of a block, and use that to
dissect all data in the block, including but not limited to the options.
Catch ReportedBoundsError exceptions and treat them as an indication
that the block length was too short - add an expert info to the block
length item indicating that.
Have separate routines for each block type that dissects the data in
that block type.
While we're at it, check whether the trailing block length is equal to
the header block length and, if not, report an error in the trailing
block length.
Fix the tests to match.
For 802.11n if the bitrate is not supplied then the calculated bitrate is used. This change does the same for 11ac and 11ax.
Sniffer traces taken on recent versions of Macos no longer supply the bitrate for 11ac frames in the RADIOTAP header, this change allows the wireless timeline to work with these traces.
Fixes#17419.
It runs up to either the end of the option data or the terminating
end-of-options option (readers MUST handle lists of options that
contains an end-of-options option and lists of options that don't).
Put the PV0 dissection into its own routine.
Add a small routine for unknown protocol versions.
Have the top-level dissector just call the PV0, PV1, or unknown version
routines.
Have the PV1 routine create an 802.11-protocol top-level tree item,
rather than putting the header fields at the top level.
dissect_ieee80211_ranging_trigger_variant(), when passed a subtype
other than 0 through 3, will return 0, causing
add_he_trigger_user_info() to loop infinitely on a TRIGGER_TYPE_RANGING
frame.
This change checks for a return value of 0 and terminates the loop.
This probably needs a better fix that reports an error (and maybe
requires dissect_ieee80211_ranging_trigger_variant() to handle subtype
4; I don't have the latest 11ax draft to check).
Fixes#17418.
REC_TYPE_PACKET is 0, so if it's been initialized to 0, and never gets
overwritten, this fixes code withotu fixing a visible bug, but it should
be done anyway.
An inadvertent change in f6ad48 caused sub-dissectors to be called
with their data argument set to the message topic.
This isn't required for the SparkplugB heuristic dissector (or any
other it seems).
As we don't know which dissector we call we don't know which data type the
subdissector wants. Therefore we should only call with data for specific
dissectors.
João Valverde