packet-tcpcl.c:1071:9: warning: Value stored to 'frm' is never read [deadcode.DeadStores]
packet-tcpcl.c:1706:21: warning: Value stored to 'sep' is never read [deadcode.DeadStores]
packet-tcpcl.c:1762:21: warning: Value stored to 'sep' is never read [deadcode.DeadStores]
packet-ieee80211.c:17423:9: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:17424:9: warning: Value stored to 'tag_len' is never read [deadcode.DeadStores]
packet-ieee80211.c:17430:10: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:17431:10: warning: Value stored to 'tag_len' is never read [deadcode.DeadStores]
packet-ieee80211.c:17437:10: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-ieee80211.c:17438:10: warning: Value stored to 'tag_len' is never read [deadcode.DeadStores]
Remove the generate_*_pages targets that were recently introduced,
since they're not really needed. Only add the "manpages" target
if we have Asciidoctor.
- Point all MSP related DATA frames to their MSP instead of
using wmem_tree_lookup32_array_le().
- Add test_grpc_streaming_mode_reassembly testcase for verifying
this feature.
close#17633
All additional release fields in RadioAccesCapabilities are considered
optional, and the CSN_DESCR for Content_t already marks almost all as such,
except DownlinkDualCarrierCapability_r7.
It has been found that some MS transmits a MS RA Capability with a Length=61 bits
where the last bit in the buffer is setting the Exist bit for
DownlinkDualCarrierCapability_r7 as 1. Hence, the CSN1 decoder failed to
decode the whole message because it expected to keep reading there
despite there's no more bytes to read.
While this is could actually be considered an MS bug, let's relax our
expectancies and simply consider the case { 1 <end> } as it was { 0 },
and mark skip decoding DownlinkDualCarrierCapability_r7. That what
wireshark (packet-gsm_a_gsm.c) or pycrate do for instance.
This patch itself doesn't fix the problem where actually the Exist bit
is stored as 1 in the output decoded structure, but simply allows keep
ongoing with decoding until the end. This issue will be fixed in a
follow-up patch.
This patch is a port from patch fixing same issue in the osmo-pcu.git copy of
csn1 decoder:
https://git.osmocom.org/osmo-pcu/commit/?id=ebdc0d8c170ee2dbf23b19056d6c2d0ef316b3c2
Op. Bulletin No. 1117 (1.II.2017) has an annexed list of Mobile
Country Codes that includes a number of which are not mentioned
in the MCC/MNC combined list in Op. Bulletin No. 1161 (1.XX.2018),
possibly because the MNCs are not reported to the ITU in a timely
fashion or because the assigned number is not actually used (e.g.,
Vatican City). See:
https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-OB.1117-2017-OAS-PDF-E.pdf
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.