Matches is a special case that looks on the RHS and tries
to convert every unparsed value to a string, regardless
of the LHS type. This is not how types work in the display
filter. Require double-quotes to avoid ambiguity, because
matches doesn't follow normal Wireshark display filter
type rules. It doesn't need nor benefit from the flexibility
provided by unparsed strings in the syntax.
For matches the RHS is always a literal strings except
if the RHS is also a field name, then it complains of an
incompatible type. This is confusing. No type can be compatible
because no type rules are ever considered. Every unparsed value is
a text string except if it happens to coincide with a field
name it also requires double-quoting or it throws a syntax error,
just to be difficult. We could remove this odd quirk but requiring
double-quotes for regular expressions is a better, more elegant
fix.
Before:
Filter: tcp matches "udp"
Constants:
00000 PUT_PCRE udp -> reg#1
Instructions:
00000 READ_TREE tcp -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_MATCHES reg#0 matches reg#1
00003 RETURN
Filter: tcp matches udp
Constants:
00000 PUT_PCRE udp -> reg#1
Instructions:
00000 READ_TREE tcp -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_MATCHES reg#0 matches reg#1
00003 RETURN
Filter: tcp matches udp.srcport
dftest: tcp and udp.srcport are not of compatible types.
Filter: tcp matches udp.srcportt
Constants:
00000 PUT_PCRE udp.srcportt -> reg#1
Instructions:
00000 READ_TREE tcp -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_MATCHES reg#0 matches reg#1
00003 RETURN
After:
Filter: tcp matches "udp"
Constants:
00000 PUT_PCRE udp -> reg#1
Instructions:
00000 READ_TREE tcp -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_MATCHES reg#0 matches reg#1
00003 RETURN
Filter: tcp matches udp
dftest: "udp" was unexpected in this context.
Filter: tcp matches udp.srcport
dftest: "udp.srcport" was unexpected in this context.
Filter: tcp matches udp.srcportt
dftest: "udp.srcportt" was unexpected in this context.
The error message could still be improved.
It is always an error to chain regexes using the logic for "le" and "eq".
var matches "regex1" matches "regex2"
=> var matches "regex1" and "regex1" matches "regex2"
Before:
Filter: tcp matches "abc$" matches "^cde"
dftest: Neither "abc$" nor "^cde" are field or protocol names.
Filter: "abc$" matches tcp matches "^cde"
dftest: Neither "abc$" nor "tcp" are field or protocol names.
After:
Filter: tcp matches "abc$" matches "^cde"
dftest: "matches" was unexpected in this context.
Filter: "abc$" matches tcp matches "^cde"
dftest: "matches" was unexpected in this context.
Bluetooth LE SMP protocol uses Little-endian byte order. Convert
Bluetooth LE Secure Connections debug public key to Little-endian
byte order to fix the problem that dissector did not properly
identify debug keys when they were used during the pairing.
This statement is at the top of the function, calls itself recursively
without changing any state, reaches the max recursion level, and then
travels back up the stack adding expert infos and returning -1, and
then at the end always causes a variable to be set to a known value.
Remove all that, and just set the variable to the value it's going to
have anyway. This speeds things up a lot and prevents adding dozens
of expert infos to dictionaries without otherwise changing the
behavior, which does seem to work.
Reducing the namespace for protocol names makes the display filter grammar
simpler and less ambiguous and error prone. We can't easily impose
stricter restrictions without breaking backward compatibility but names
starting with '-' are a pathological case because of negative numbers
and byte slices and in the unlikely event that any such names exist
they should be fixed.
It won't work with embedded null bytes so don't try. This is
not an additional restriction, it just removes a hidden failure
mode. To support matching embedded NUL bytes we would have
to use an internal string representation other than
null-terminated C strings (which doesn't seem very onerous with
GString).
Before:
Filter: http.user_agent == 41:42:00:43
Constants:
00000 PUT_FVALUE "AB" <FT_STRING> -> reg#1
Instructions:
00000 READ_TREE http.user_agent -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_EQ reg#0 == reg#1
00003 RETURN
After:
Filter: http.user_agent == 41:42:00:43
Constants:
00000 PUT_FVALUE "41:42:00:43" <FT_STRING> -> reg#1
Instructions:
00000 READ_TREE http.user_agent -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_EQ reg#0 == reg#1
00003 RETURN
FT_PROTOCOL and FT_BYTES are the same semantic type, but one is
backed by a GByteArray and the other by a TVBuff. Use the same
semantic rules to parse both. In particular unparsed strings
are not converted to literal strings for protocols.
Before:
Filter: frame contains 0x0000
Constants:
00000 PUT_FVALUE 30:78:30:30:30:30 <FT_PROTOCOL> -> reg#1
Instructions:
00000 READ_TREE frame -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_CONTAINS reg#0 contains reg#1
00003 RETURN
Filter: frame[5:] contains 0x0000
dftest: "0x0000" is not a valid byte string.
After:
Filter: frame contains 0x0000
dftest: "0x0000" is not a valid byte string.
Filter: frame[5:] contains 0x0000
dftest: "0x0000" is not a valid byte string.
Related to #17634.
The statistics that use the stats_tree API parse the -z option
without expecting a comma separator between the statistics name
and the filter. This is contrary to both the man pages and how
all the other options work. Fix that so it's consistent.
Fix#17656
The Linux SocketCAN header now uses the formerly-reserved byte in the
SocketCAN header after the "payload length" field as an "FD flags"
field, with a flag bit reserved to indicate whether the frame is a
classic CAN frame or a CAN FD frame, with two other bits giving frame
information for FD frames.
For LINKTYPE_CAN_SOCKETCAN, use that flag bit to determine whether the
frame is classic CAN or CAN FD. As some older LINKTYPE_CAN_SOCKETCAN
captures have SocketCAN headers in which the fields after the "payload
length" field were uninitialized, so trust that thge "FD flags" was
filled in, rather than possibly randomly uninitialized, only if the only
bits set in that field are the bits defined to be in that field and the
two reserved bytes after it are zero.
This will be needed when the current main-branch libpcap is released, as
it uses LINKTYPE_CAN_SOCKETCAN rather than LINKTYPE_LINUX_SLL for
ARPHRD_CAN devices; we add it now to future-proof the Wireshark releases
to which this is being committed. It also handles what existing CAN FD
captures using LINKTYPE_CAN_SOCKETCAN exist.
For LINKTYPE_LINUX_SLL frames, we have the protocol field to distinguish
between classic CAN and CAN FD, so we use that to determine the frame
type, rather than looking at the CANFD_FDF flag.
dissect_socketcan_common() now handles both classic CAN and CAN FD
frames.
Revert recent "docs" target changes. It made that target build faster,
but broke other dependencies. Keep the AsciidoctorJ changes.
Revert "doc: fix the macOS build."
This reverts commit 119667d886.
Revert "CMake: Try to make our man page builds faster."
This reverts commit 74747c4d2f.
Always use the internal API to access "deprecated" and initialize
the data structure on demand. This fixes a null pointer dereference
introduced previously.
Use reference counting to share the array cleanly and avoid memory
leaks.
Keep the pointer in dfwork_t.
The lexical rules for fields and unparsed strings are ambiguous,
e.g. "fc" can be the protocol fibre channel or the byte 0xfc.
In general a name is determined to be a protocol field or not by
checking the registry.
Resolving the name in the parser gives more flexibility, for example
to use different semantic rules according to the relation between
LHS and RHS, and allows function names and protocol names to co-exist
without ambiguity.
Before:
Filter: tcp == 1
Constants:
00000 PUT_FVALUE 01 <FT_PROTOCOL> -> reg#1
Instructions:
00000 READ_TREE tcp -> reg#0
00001 IF-FALSE-GOTO 3
00002 ANY_EQ reg#0 == reg#1
00003 RETURN
Filter: tcp() == 1
dftest: Syntax error near "(".
After:
Filter: tcp == 1
Constants:
00000 PUT_FVALUE 01 <FT_PROTOCOL> -> reg#1
Instructions:
(same)
Filter: tcp() == 1
dftest: Function 'tcp' does not exist
It's also a goal to make it easier to modify the lexer rules.
Ping #12810.
BUNDLE_RESOURCE_SHARE_MAN[14]_FILES shouold *not* have the generate_
prefixes; names with those prefixes are fake targets, not names of files
that we generate, so attempting to copy files with those names fails.
It should, however, have "doc/" before the names of the man pages, as
they're generated into the doc directory of the top-level build
directory.
We need to update global_ld.inpkts_to_sync_pipe as soon as we've written
a packet to the current capture file. If we're writing to multiple
files, then, if we delay counting until after we switch to another file,
the packet-count message we send to the parent before switching won't
include the packet, and the first packet-count message we send to the
parent *after* switching *will* include the packet, which could mean the
parent will try to read more packets than there are in the new file, in
which case it'll get an EOF and, at least in the case of TShark, treat
that as an error and stop capturing.
This should fix issue #17654.
While we're at it, don't send a "we have no packets" packet-count
message even for the packet-count message we send just before switching
files.
Depend on our generator targets instead of the generated files, which
allows parallel builds outside of Ninja. Don't reserve JRE memory when
building HTML and man page targets. This reduces the "docs" target build
time on my Windows VM here from over two minutes to under one.
Add endpoint type for uTP connection IDs.
Manage uTP conversations, creating generated stream ID to filter
on both sides of a conversation.
Display more information in INFO column, similar to TCP.
This is some progress towards #8792.
Jakub Pawlowski
Vadim Yanitskiy