When a Segment Routing Header is present in the IPv6 packet provisions
have to be made to setup the right destination address for the pseudo
header used in checksum calculations. When segments are left in the header
the first address in the list has to replace the destination address.
Closes#17097
(cherry picked from commit 7052994a19)
Two interlocking problems cause the dissection of FC to fail in some cases,
as shown in the capture of the related issue.
The FC dissector assumes that ETHERTYPE_UNK in the data structure passed
to it is coming from the MDS header dissector only, and thus that header
sizes have to be taken into account. This is not / no longer the case.
It always passes down ETHERTYPE_FCFT. Therefore the MDS header size
checking does not apply to ETHERTYP_UNK, so is removed as condition.
The other FC related dissectors were forced to setup a data structure to
pass to FC for it to handle that part of the frame. Because these weren't
related to ethernet, these lazily set the ethertype field in the data
structure to 0. This unfortunately matches ETHERTYPE_UNK, triggering the
MDS header size checking in FC, leading to this issue. With the first
problem resolved, now make it explicit that unknown ethertype is indicated
by ETHERTYPE_UNK, not '0'.
Addresses primary part of issue #17084
(cherry picked from commit 3f0fc1b232)
When the user enters row to SNMP Users table in wireshark and Authentication model is set to MD5, row is ignored in processing. The reason is that constant for MD5 is 0, but the code checks if the value is defined by simple 'usm_p.user_assoc' condition. Therefore 0 never succeeds.
As item can have only listed values, I think the check can be removed.
Function verified on sample.
I propose to cherry pick the change to all stable branches.
(cherry picked from commit 7f376c7ced)
We must be able to correctly detect valid coalesced packets and
recognize them from random padding.
Close#17011Close#16914
(cherry picked from commit 0af60377b4)
This bug affects Lua plugin dissectors for encapsulation protocols like
GRE. Typically the dissector creates a range for the payload packet, then
calls the next dissector with a tvb derived from the range, using
TvbRange_tvb(). The original version calls
tvb_new_subset_length_caplen() using the remaining capture length for the
reported_len argument. The fix passes -1 as the reported length, and
tvb_new_subset_length_caplen() calculates the new reported_len as required.
The bug only affects large packets captured with a snaplen and
truncated, then decoded with a Lua plugin for the encapsulation header.
Here's the typical bug symptom, gleaned from tshark decode of
an encapsulated IP payload:
[Expert Info (Error/Protocol): IPv4 total length exceeds packet length (114 bytes)]
[IPv4 total length exceeds packet length (114 bytes)]
Closes#15655.
(cherry picked from commit e7ec6739b6)
format_text uses the wrong bitmask when checking for two byte UTF-8
characters, resulting in rejecting half the possible two bytes characters,
including all of Arabic and Greek, and substituting REPLACEMENT CHARACTER
for them. Fixes#17070, and add some comments about the current behavior
that doesn't match existing comments.
(cherry picked from commit 770746cca8)
Fix error handlers in Listener draw() and reset() to avoid getting
LUA_ERRERR from lua_pcall(). Added error handler for Listener draw()
callback.
Handle LUA_ERRERR from lua_pcall() to avoid assert on this.
Changed some capitalized words in various error message.
Closes#16974.
(cherry picked from commit d104571e8a)
At least one ns-3 capture has DMG frames (as indicated by the channel
number being in the 60 GHz band - radiotap currently has no DMG metadata
field) that have the +HTC/Order flag subfield set but have no HT Control
field, causing them to be misdissected.
802.11-2016 says that DMG frames should never have +HTC/Order set; if it
*is* set in a QoS frame known to be a DMG frame, flag it with an expert
info item and don't treat it as having an HT Control field.
Update a bunch of comments to give more information, put comments in the
appropriate places, and speak of 802.11-2016 rather than older standards.
While we're at it, update the title and description of the +HTC/Order
flag to reflect its name as of 802.11-2016.
(cherry picked from commit 3c640ca04a)
Don't assume that the Internet has our best interests at heart when it
gives us the size of our decompression buffer. Assign an arbitrary limit
of 50 MB.
This fixes#16739 in that it takes care of
** (process:17681): WARNING **: 20:03:07.440: Dissector bug, protocol Kafka, in packet 31: ../epan/proto.c:7043: failed assertion "end >= fi->start"
which is different from the original error output. It looks like *that*
might have taken care of in one of the other recent Kafka bug fixes.
The decompression routines return a success or failure status. Use
gbooleans instead of ints for that.
(cherry picked from commit f4374967bb)
Make sure _proto_tree_add_bits_ret_val allocates a bits array using the
packet scope, otherwise we leak memory. Fixes#17032.
(cherry picked from commit a9fc769d7b)
Back in 2017, commit d7bab0b46e introduced
printing the TEI in COL_INFO. Unfortunatelky it contained a typo and
stated "TEI:1%u" instead of "TEI:%u". So TEI 0 became TEI 10, etc. -
causing some confusion.
Let's remote that extraneous '1' and at the same time print the sapi
with two digits for better alignment of multiple lines. It is a
two-digit decimal value (0..63).
(cherry picked from commit 9c5ea50b0a)
That's QoS-frame only; for non-QoS frames, the +HTC/Order subfield
doesn't mean there's an HT Control field.
Update the reference to the part of the 802.11 standard mentioning that
subfield to 802.11-2016.
(cherry picked from commit 1fa5687fad)
It's clearer to say
if (A) {
if (B) {
do this;
} else {
do that;
}
}
than to say
if (A && B) {
do this;
} else if (A && !B) {
do that;
}
(cherry picked from commit baee4a41c7)
Change
case DATA_FRAME:
if (condition) {
do stuff;
break;
}
do other stuff;
break;
to
case DATA_FRAME:
if (condition) {
do stuff;
} else {
do other stuff;
}
break;
to make it clearer that it's "do this if condition is true, else do
that".
(cherry picked from commit 258fb14821)
After a key update, we should update Packet Protection cipher but
we shouldn't touch the Header Protection one.
With the current code, PP and HP ciphers are quite entangled and we
always reset both of them. Therefore, at the second key update we
reset the used 1-RTT HP cipher too; no wonder even header decryption
fails from that point on.
To properly fix this issue, all the ciphers structures has been rewritten,
clearly separating PP code from HP one.
Close#16920Close#16916
(cherry picked from commit 5e45f770fd)
Fix dissecting of packets received on LE Coded PHY. These packets
will include the extra field "coding indicator" after the access
address.
The assignment of phy in the common bluetooth context was missing,
leading to this field being left out and the offset being wrong.
(cherry picked from commit c586f71a5c)
The pointer isn't incremented in get_ts_23_038_7bits_string_unpacked
so it just decodes the first octet length times.
(cherry picked from commit 5df3f5d05d)
coherent_set_tracking.coherent_set_registry_map uses a struct as a key,
but the hash and comparison routines treat keys as a sequence of bytes.
Make sure every key byte is initialized. Fixes#16994.
Call wmem_strong_hash on our key in coherent_set_key_hash_by_key instead
of creating and leaking a GBytes struct.
(cherry picked from commit 33e63d19e5)