In 3GPP 26.449 Codec for Enhanced Voice Services (EVS); Comfort Noise Generation
(CNG) aspects, Computational details and bit allocation:
For the EVS primary modes, the SID payload consists of 48 bits. The first bit of
the payload determines the CNG scheme, where 0 stands for the LP-CNG and 1 for
the FD-CNG.
Move our attributes.adoc includes to the very top of each man page.
Older versions of Asciidoctor complain if it's not at the top. and
additionally generate <file>.man instead of <file>.<section> if we don't
explictly supply an output file.
Asciidoctor lets us generate multiple documents at once, so do so for
our man pages. If we're using AsciidoctorJ this minimizes the number
of JVM instances we have to spin up. This reduces the build time on my
Windows VM here quite a bit, and will hopefully do so on the CI builders.
Add a .editorconfig file in cmake/modules.
Handle uTP payload to the bittorrent dissector.
Implement dissect PDUs to handle more than one bittorrent PDU
in a uTP payload.
Implement basic multisegment PDU tracking; not enough to actually
desegment, but enough to provide a hint to the start offset of the
next PDU when a PDU does span segments. (Provided that they're in
order, but OOO handling isn't implemented yet either.)
Improves #8792.
In 3GPP 26.449 Codec for Enhanced Voice Services (EVS); Comfort Noise Generation
(CNG) aspects, Computational details and bit allocation:
For the EVS primary modes, the SID payload consists of 48 bits. The first bit of
the payload determines the CNG scheme, where 0 stands for the LP-CNG and 1 for
the FD-CNG.
The APDU information element in Perform Location Request and Perform
Location Information messages is optional and not mandatory, as seen in
3GPP 49.031. This commit fixes a regression introduced in ga6ed603f5c.
Closes#17667
/home/pi/wireshark/wiretap/file_wrappers.c: In function ‘file_fdopen’:
/home/pi/wireshark/wiretap/file_wrappers.c:1136:27: error: comparison of integer expressions of different signedness: ‘__blksize_t’ {aka ‘long int’} and ‘unsigned int’ [-Werror=sign-compare]
if (st.st_blksize <= MAX_READ_BUF_SIZE)
^~
cc1: all warnings being treated as errors
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.
Joakim Karlsson
Pau Espin