Age | Commit message (Collapse) | Author | Files | Lines |
|
If we decode Exist bit as "1" but we are at the end of the message, and
all the Next items we'd read are expected to be possibly NULL, then swap
the Exist bit in the decoded structure as "0" in order to tell the
decoder user that the related information structure is actually unset,
as if "0" was received.
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=1859ec38cc4f4e3788e495a100fdec3787d25020
And fixup patch for that one:
https://git.osmocom.org/osmo-pcu/commit/?id=9ecdc11eb6b983748ae2fd6a1d07849c8106826f
|
|
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
|
|
|
|
|
|
Calculation used current_diff in place current_jitter in mean_jitter
calculation so it produced incorrect results. This patch fixes it.
Closes #17600.
|
|
|
|
|
|
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.
|
|
Set all pointers in Proto to NULL and check for valid pointers when
wslua_deregister_protocols().
Fixes #17668
|
|
|
|
Removed the type_id check when dissecting user data. That check avoids
dissection in valid cases.
|
|
|
|
Dissect MCX IE present in 802.11 packets like Beacon, Assoc Req, Assoc Res ...
|
|
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.
|
|
Closes #17666
|
|
Related spec: 3GPP TS 24.008 Table 10.5.146
|
|
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
|
|
|
|
Updated UUIDs to match new version from 1st October 2021
Change-Id: Ifab0296389fe3815f7ce9b15de841e8675faba32
|
|
|
|
Make sure man pages are included in the default build. Have the docs
and copy_data_files targets explicitly depend on the man page generator
targets.
|
|
|
|
/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
|
|
Try to make sure protocolID and saved_protocolID are initialized before
we use them. Another attempt at fixing #16342, #17664, and related bugs.
|
|
This fixes suite_unittests failures when adding new Bluetooth UUID
related contsants
|
|
This reverts commit 0aae44e145e90647338c3f7130f241d7f11124b8.
The fuzz builder has been running out of memory since the switch to
Clang 13, so revert back to 12 for now.
|
|
Fixes #17635.
|
|
Fixes #17661.
|
|
|
|
Should be more obvious that this error is caused
by a string syntax error and not something else.
|
|
|
|
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.
|
|
Some enhancements and visual fixes to version 3 dissector are also included.
|
|
Update manuf, services enterprise numbers, translations, and other items.
|
|
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.
|
|
The handling of unparsed values was rationalized by commits
c484ad0e5c6cadcda02a7079aa53b76be418c391 and
144dc1e2eefbb3e19b78ccb4a8c2c57bba9c212b. Update this comment
to reflect the new behavior.
|
|
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.
|
|
Should be faster.
|
|
|
|
|
|
Add support for websocket fragmented payload reassembly.
|
|
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.
|
|
|
|
In many cases, the "value offset" is actually the value itself.
Handle those cases correctly.
|