Wireshark 802.11 Frame Challenge

Frame 17. Open its decode: Install=1, Key ACK=1, Encrypted Key Data=1 and a Key Data Length of 154 octets. M1 (frame 15) carries the ANonce with no MIC. M2 (16) carries the SNonce and the client RSNE. M4 (18) has Key Data Length 0 and a zeroed nonce, which is how you spot it at a glance.

QoS Data. EAPOL is EtherType 0x888E carried inside 802.11 Data frames, which is why it can only happen after association completes at frame 7. Every frame from 8 onward in this trace is Data. Wireshark: wlan.fc.type == 2 && eapol.

Frame 14, EAP Success. Everything before it is the EAP-TLS conversation being tunnelled through the AP to RADIUS. EAP Success is the point the PMK exists on both sides, which is why M1 follows 3 ms later. If you see EAP Success and no M1, the AP never received the PMK from RADIUS.

Frame 4 at 0.121450 to frame 18 at 0.563441 is 441.99 ms. Almost all of it is the EAP-TLS exchange: frames 4 to 7 (association) take 8.3 ms, frames 15 to 18 (the 4-way handshake) take 12.2 ms, and the remaining 420 ms is certificate exchange and RADIUS round trips. This is why 802.11r matters for voice: a full re-auth costs hundreds of milliseconds, dominated by EAP.

AKM 5 is 802.1X with SHA-256 and MFPR=1 makes PMF mandatory, so this is WPA3-Enterprise. It is not 192-bit mode: that requires AKM 00-0f-ac:12 with GCMP-256 and BIP-GMAC-256, not AKM 5 with CCMP-128. A common misread, and the difference decides whether a client without SHA-384 support can join.

Frame 6, the Reassociation Response. Open its decode and you will see GTK and IGTK subelements inside the FTE, wrapped with the KEK derived during the FT Authentication exchange. FT has no post-roam 4-way handshake at all, which is exactly why there is no EAPOL anywhere in this trace.

Over-the-air. Frames 3 and 4 are FT Authentication frames sent directly between the client and the target AP, captured on the target channel. Over-the-DS would use FT Action frames relayed through the current AP over the wired network, so a capture on the target channel would show only the Reassociation exchange. The Probe Response decode confirms it: FT Capability and Policy has Fast BSS Transition over DS set to 0.

Frame 5 at 0.049330 to frame 6 at 0.070118 is 20.79 ms. The FT Authentication exchange happens before the client leaves the old AP, so it is not part of the interruption. Under 50 ms is voice grade. Measure this from capture timestamps: a controller dashboard reports association completion, not medium interruption, and the two are not the same number.

ADDBA Request and ADDBA Response, establishing a Block Ack agreement for TID 0 so the client can use A-MPDU aggregation. Note the ordering: they land after reassociation completes and before the first QoS Data frame at 9. If you see data frames with no preceding ADDBA, aggregation is not in use and throughput will be well below expectation.

FT eliminates the post-roam 4-way handshake. The PTK is derived during the FT Authentication exchange from the PMK-R1, and the GTK and IGTK arrive inside the Reassociation Response FTE. That is the entire performance argument for 802.11r. If you capture a roam on an FT-enabled SSID and still see four EAPOL frames, FT is advertised but not actually being used, usually because the client did not include the MDE.

Two. The Association Request was transmitted on the 6 GHz link, and the Basic Multi-Link element reports one additional STA Profile for Link ID 2 on 5 GHz channel 100. The transmitting link always counts, plus each reported profile. This is the single most common miscount in MLO analysis: people read the profile count and forget the link they are looking at.

Yes. The Association Response Basic Multi-Link element echoes STA Profile 1 for Link ID 2 with Status: Successful, so both the 6 GHz transmitting link and the 5 GHz link are set up. Always diff request against response. An AP MLD is free to accept fewer links than requested, and when it does the client silently runs with less aggregate capacity than anyone expects.

AKM 00-0f-ac:24, SAE-EXT-KEY, with GCMP-256 and BIP-GMAC-256 for group management. This is the Wi-Fi 7 WPA3-Personal requirement: a STA enabling EHT or MLO shall allow AKM 24 and shall allow GCMP-256. One PTK is derived for the MLD and applied to every setup link, so any radio bound into the MLD that cannot do GCMP-256 simply does not join.

320 MHz is a 6 GHz-only capability signalled in the EHT Capabilities element. The 5 GHz ceiling comes from the HE and VHT elements and reads 160 MHz here. Reading only one element gives you the wrong answer. The negotiated width is then the minimum of client capability and AP operating width, so check the EHT Operation element in the beacon before blaming the client for a narrow link.

SAE Commit (SEQ=1, both directions) then SAE Confirm (SEQ=2, both directions), using Authentication Algorithm 3. SAE runs inside Authentication frames before association. The 4-way handshake still follows at frames 8 to 11 to derive the PTK, so a full WPA3-Personal MLO association is four Auth frames, an Assoc exchange, and four EAPOL frames. If an Auth Response returns status 77, the AP rejected the offered finite cyclic group.

Frame 5, a BSS Transition Management Request. Its decode reads Category 10 (WNM), Action 7, with Preferred Candidate List Included, Abridged and Disassociation Imminent all set, plus a single candidate at preference 255. Frame 2 is different: that is an 802.11k Neighbor Report Response, which only tells the client where the neighbours are. 11k informs, 11v nudges, and neither can force anything.

Frame 6 is a BTM Response carrying status code 1, Reject with unspecified reason, and no Target BSSID. The client acknowledged the request and refused. Status 0 would mean it accepted and will transition. Other rejects you will meet are 2 (insufficient beacon information), 3 (insufficient capacity) and 5 (no suitable candidates). Status 1 is the one that tells you nothing useful, and it is by far the most common.

Category 10 (WNM), Action 8. The Request is Category 10 Action 7 and the Response is Action 8, so one filter on Category 10 catches both halves of the exchange. Category 5 is Radio Measurement, which is where the 802.11k Neighbor Report frames live at frames 1 and 2. Mixing up the 11k and 11v action categories is a common analysis error.

The BTM Request at frame 5 set Disassociation Imminent with a 200 TBTT timer. At a 102.4 ms beacon interval that is about 20.5 seconds, and frame 10 lands 20.49 seconds after frame 5. The client refused to move, so the AP forced it off. Note the reason code is 1, unspecified: the standard defines no BTM-specific reason code, so vendors pick their own. Forced roaming is not a defined BTM outcome, it is the AP running out of options.

Track the client RSSI column down the trace: -62, -71, -76, -77, -78, -79, with the rate collapsing from MCS 4 to MCS 0 and retries appearing by frame 8. Throughout, the destination address never changes. A client that degrades this far without roaming has made a local decision to stay, and no amount of 11k data or 11v nudging overrides a client-side roaming algorithm. The roam decision always belongs to the client.

Frame 3 is the first beacon carrying a Channel Switch Announcement element, with Channel Switch Count at 5. Frames 1 and 2 are ordinary beacons on channel 100. The CSA element rides in beacons and probe responses specifically because those are the frames every station is already listening for, including stations in power save.

Mode 1 means transmission stops until the switch happens. Mode 0 would permit continued transmission right up to the switch. This is why nothing between frames 3 and 7 comes from a client: the medium is deliberately silent. A capture that looks dead for half a second right after a CSA is not a broken sniffer, it is the protocol working as designed.

Channel Switch Count is measured in TBTTs, and the count is 5 at frame 3. At a 102.4 ms beacon interval that is 512 ms. The arithmetic checks out in the capture: frame 3 at 0.204800 and the first channel 36 beacon at frame 8 at 0.716800, a difference of exactly 512.0 ms. Counting down across several beacons rather than switching instantly is what gives power-save clients a chance to hear the announcement.

Channel 36 is U-NII-1, which is not DFS in the US, so the AP can beacon immediately. Had it selected another DFS channel it would first have to run a 60 second Channel Availability Check listening for radar, and no client could associate during that window. That is the difference between a half second outage and a minute of downtime, decided entirely by which fallback channel the RRM plan picked.

Frames 1 to 7 only. A monitor-mode radio hears one channel at a time and does not follow a CSA. The trace would simply stop at frame 7 and the analyst would report that the AP disappeared. This capture used a second radio on channel 36 to catch frames 8 onward. Any time a capture ends abruptly mid-incident, ask what channel the sniffer was on before concluding anything about the AP.

M3 never appears. The trace shows four complete M1 and M2 pairs at frames 5-6, 7-8, 9-10 and 11-12, and the sequence stops there every time. M3 is the AP saying "your M2 checked out, here is the GTK". Its absence means the AP is refusing to proceed after receiving M2, not that the client stopped responding.

M1 is retransmitted at 0.019, 1.024, 2.028 and 3.031, roughly one second apart. The AP derives a PTK from its PMK and validates the MIC on M2. When that check fails, it discards M2 and retries M1 on the standard timeout. Four attempts, then it gives up. The regular one second spacing is the signature of a timeout loop rather than an RF problem.

Reason 15, 4-way handshake timeout. It is the correct code for what happened, but on its own it is ambiguous: reason 15 appears for a wrong passphrase, a stale cached PMKSA, and a genuine client driver stall alike. The reason code tells you where it broke, not why. That distinction is the whole point of opening the capture.

A cipher or AKM mismatch would be rejected at association with a non-zero status code, typically 40, 41 or 42, before any EAPOL frame is sent. Status=0 at frame 4 means the AP accepted the client RSNE, so the negotiated cipher suite is agreed. The failure is in key material, not capability. That single observation eliminates half the plausible causes in one glance.

PMF is off on this BSS. With PMF active the deauth would carry Protected=1 and be cryptographically verifiable as coming from the AP. Unprotected, it is trustworthy only because everything around it is consistent. On a live network this is also the gap that makes deauth floods possible. Two findings from one frame: the handshake failed, and the BSS has no management frame protection.