Age | Commit message (Collapse) | Author | Files | Lines |
|
Add the frame control flags string to a new field. This can be
used in a custom column, similar to TCP Flags.
|
|
This adds the following KDEs defined by the Wi-SUN FAN specification:
- Pairwise Transient Key KDE (PTKID)
- Group Transient Key Liveness KDE (GTKL)
- Node Role KDE (NR)
- LFN Group Transient Key KDE (LGTK)
- LFN Group Transient Key Liveness KDE (LGTKL)
|
|
The Wi-SUN FAN specification describes the format of the EAPOL-Key frame
in section 6.5.2.2 (Authentication and PMK Installation Flow):
Descriptor Type = 2
Key Information:
1. Key Descriptor Version = 2
2. Key Type = 0
3. Install = 0
4. Key Ack = 0
5. Key MIC = 0
6. Secure = 0
7. Error = 0
8. Request = 1
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 = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = 0
Key Data Length = length of Key Data field in octets.
Key Data = PMKID KDE if the PMK is live, PTKID KDE if the PTK is live, GTKL
KDE, Node Role KDE, and LGTKL KDE.
The current dissector will try do decrypt if the Key Type is 0 while the
Encrypted Key Data is unset, which appears to be for supporting
non-standard WPA implementations. The Key Data is not encrypted in
Wi-SUN, so a workaround is made to dissect the Key Data if the Key
Length is 0.
|
|
Tag number 221 (Microsoft WPA Information Element) contains an AKM type.
Save this to fix wlan decryption when this tag is used by Access Point.
|
|
Change ENC_NA to ENC_LITTLE_ENDIAN for following Short SSID items:
- hf_ieee80211_ff_fils_discovery_short_ssid
- hf_ieee80211_short_ssid
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
for LCI Report
|
|
|
|
From 802.11-2020.pdf
|
|
|
|
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.
|
|
|
|
!18574
|
|
|
|
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.
|
|
Fix 18610
|
|
|
|
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:33184 hf_ieee80211_addr_ta called consecutively at line 33184 - previous at 33183
|
|
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
|
|
/packet-ieee80211.c: - filter "wlan.fixed.publicact" appears consecutively - labels are "Public Action"" and "Protected Public Action""
|
|
Fix a length check issue introduced in 85a9e05c52.
|
|
Replace looped snprintfs with wmem_strbuf_append_printfs.
|
|
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
|
|
|
|
!18504
|
|
Reduce the number of chars used so we can fit in the 240-byte limit.
Fixes #18504
|
|
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.
|
|
Fix #18436
|
|
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
|
|
Makes sure "Unknown" is added to tree for unknown vendor-specific types.
|
|
Dissector only supports type 1: AP Name.
|
|
|
|
A conversation in Wireshark might have two endpoints or might have no
endpoints; few if any have one endpoint. Distinguish between
conversations and endpoints.
|
|
More {host, hostlist} -> endpoint.
|
|
It's an endpoint table, not a table of hosts.
|
|
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.
|
|
Fix subframe length issue.
Add padding.
Signed-off-by: Chien Wong <m@xv97.com>
|
|
Signed-off-by: Chien Wong <m@xv97.com>
|