IEEE 802.11-2020, Section 12.4.7.6 says that an SAE Confirm message,
with a status code not equal to SUCCESS, shall indicate that a peer
rejects a previously sent SAE Confirm message. In this case, the Confirm
message may not carry a Send-Confirm field or a Confirm field, as
hostapd does. So we simply ignore possible fields following Status code.
Signed-off-by: Chien Wong <m@xv97.com>
Only dissectors are using this function and there is no use case,
as far as I know, that requires its use. Any limitation of length
is imposed transparently by the UI backend.
This function is problematic because it is not Unicode aware and
will truncate a string on an arbitrary byte boundary for multibyte
strings.
Replace its use with a normal strbuf without a length limite and
remove the function because it is not useful and the ITEM_LABEL_LENGTH
parameter does not belong in wmem anyway.
The wmem_strbuf_new_label() creates a new buffer with a length limit
in octets. With multibyte strings this is likely to generate invalid
UTF-8 errors.
Remove the artificial limit on the value size. The
function proto_tree_add_string() sets the value, and truncating
that to an arbitrary limit is not really correct.
The display label will be truncated to a preset length by the UI.
This mechanism uses ws_label_strcpy() and is designed to avoid
the invalid truncation.
While here use wmem_strbuf_get_str() instead of wmem_strbuf_finalize().
Accepted best practice is to let the scope free the memory.
Removing the finalize call avoids an unnecessary realloc.
Fixes#18653.
https://ask.wireshark.org/question/29235/
MAC addresses shown in WLAN statistics do not appear in the capture!
Initialize the address types then check if set when tapping.
This an action frame to update the EMLSR / EMLMR mode.
This adds partial support for this frame.
It is fairly hairy to parse it because of its variable format, so for
now, just parse the EMLSR part and leave the EMLMR part for later.
packet-ieee80211.c:10060 proto_tree_add_item called for hf_ieee80211_hs20_icons_avail_len - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:11869 proto_tree_add_item called for hf_ieee80211_ff_key_data_length - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:21328 proto_tree_add_item called for hf_ieee80211_s1g_short_beacon_interval - item type is FT_UINT8 but call has len 2
packet-ieee80211.c:32379 proto_tree_add_item called for hf_ieee80211_pentapartial_timestamp - item type is FT_UINT8 but call has len 5
packet-ieee80211.c:32932 proto_tree_add_item called for hf_ieee80211_pv1_cnt_bat_bitmap - item type is FT_UINT16 but call has len 4
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)
Martin Mathieson