packet-ieee80211.c filter= wlan.he_ndp.sta_info.ru_start - mask has odd number of digits 0x3F800 expected max for FT_UINT32 is 8
packet-ieee80211.c filter= wlan.he_ndp.sta_info.ru_end - mask has odd number of digits 0x1FC0000 expected max for FT_UINT32 is 8
Appending to a string using snprintf inside a loop can be problematic
because you have to ensure that your start offset stays within the
bounds of your buffer and that your size (which is unsigned) doesn't
overflow. Switch to a wmem_strbuf.
Fixes#18527
I noticed while implementing the equivalent for 802.11be that the number
of bits for phi and psi angles was reversed. Also, fixed the spelling of
AvgSNR.
In section 6.5.2.3 ("PTK and GTK Installation Flow"), the Wi-SUN
specification says that the second message in 4 way handshake must have
these properties:
Descriptor Type = 2
Key Information:
1. Key Descriptor Version = 2
2. Key Type = 1 (Pairwise)
3. Install = 0
4. Key Ack = 0
5. Key MIC = 1
6. Secure = 0
7. Error = 0
8. Request = 0
9. Encrypted Key Data = 0
10. SMK Message = 0
11. Reserved = 0
Key Length = 0
Key Replay Counter = see [IEEE802.11] section 11.6.2.
Key Nonce = SUP generated SNonce
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = MIC(KCK, EAPOL) computed over the body of this EAPOL-Key frame
with the Key MIC field first initialized to 0.
Key Data Length = 0
Key Data = none
Thus, until now, the message 2/4 of 4 way handshake was identified as
message 4/4.
packet-ieee80211.c has the IEEE 802.11w-2009 class
indication lookup table included already but it's only
used to resolve the WFA HS2.0 OCI attribute when it
could also be used to resolve beacon/probe response tag
59. Adding that resolution and renaming the RVAL struct
from hs20_oper_class_rvals to simply oper_class_rvals.
Closes#18389
A conversation in Wireshark might have two endpoints or might have no
endpoints; few if any have one endpoint. Distinguish between
conversations and endpoints.
The "conversation table" mechanism supports two types of tables, one for
the "Conversations" menu item under "Statistics" and one for the
"Endpoints" menu item under "Statistics". The first of them shows
statistics for conversations at various layers of the networking stack;
the second of them shows statistics for endpoints at various layers of
the networking stack.
The latter is *not* a table of hosts; an endpoint might be a host,
identified by an address at some network level (MAC, IP, etc.), or it
might be a port on a host, identified by an address/port pair.
Some data types, function names, etc. use "host" or "hostlist" or other
terms that imply that an endpoint is a host; change them to speak of
endpoints rather than hosts, using names similar to the corresponding
functions for conversations.
Provide wrapper functions and typedefs for backwards source and binary
compatibility; mark them as deprecated in favor of the new names.
Clean up some comment errors found in the process.
When parsing wlan header above capwap, first two bytes are swapped (fcf
and flag). the offset was handled incorrectly, causing wireshark to
display incorrect fcf data in the tree summery and completely wrong
flags information (in the case of swap, the flags point to the same
byte as the fcf)
The format and meaning of the bits in the Capability information field
has been different than what was implemented since at least 802.11-2016.
Defined in 9.4.1.4 Capability Information field.
IEEE 802.11 SSID fields are officially unspecified encoding but
probably UTF-8 (and likely ASCII, with which UTF-8 is backwards
compatible), unless the Extended Capabilities bit indicating that
it's *definitely* UTF-8 is set.
Get the SSID bytes as a raw byte string without any encoding
validation for sending to Dot11Decrypt, and add it to the tree
as a FT_BYTES with BASE_SHOW_UTF_8_PRINTABLE, which does the
right thing most of the time, and more often than now. In practice
this does most of #16208.
To really finish the job, the Extended Capabilities bit needs to
be checked, but not only does that bit come in a later tagged element
than the SSID, it's not necessarily sent, and for Responses we'd have
to track if the bit was set in a corresponding Request in the same
conversation. However, it's not clear that any drivers actually do
set the bit. (In all the captures I've seen with UTF-8 or even non
ASCII/non UTF-8 SSIDs, the bit was unset.)
Repeated words were found with:
egrep "(\b[a-zA-Z]+) +\1\b" . -Ir
and then manually reviewed.
Non-displayed strings (e.g., in comments)
were also corrected, to ease future review.
Alexis La Goutte