packet-rtps-processed.c:321:13: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-rtps-processed.c:349:13: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-rtps-processed.c:356:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-rtps-virtual-transport.c:946:17: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-rtps-virtual-transport.c:995:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
Add section about common regex pitfalls and correct some examples.
Also add a more information about the string field type, including
an explanation of byte escape sequences.
Ping #15716.
Use wsApp->setLastOpenDirFromFilename() to convert a filename
to a directory name before calling wsApp->setLastOpenDir().
This will ensure to always store a directory instead of a filename
in the recent gui.fileopen_remembered_dir.
Add a generic function to write content to file. Use this on write
TLS session keys from UI and tshark, and for export objects.
Remove the now unused export_object_ui.[ch].
__VERSION__ is copied from GCC, clang has __clang_version__.
Apparently clang's __VERSION__ already includes the name:
Compiled (64-bit) using clang Clang 11.1.0
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.