802.11 Connection Failure: What Your PCAP Actually Shows

Client probes 2.4 GHz channels 1–11. AP beacons only appear on 5/6 GHz. No Probe Response ever received. Check the client's Probe Request → HE Capabilities IE - absent means the client cannot join a 6 GHz-only SSID.

IO graph the beacon inter-arrival time. Normal = 100 TUs (~102.4 ms). Gaps of 500 ms+ or irregular spacing = AP radio struggling. Missing 3–7 consecutive beacons → client stops scanning and reports "network not found."

Beacons present but SSID field is empty. Client sends directed Probe Requests with saved SSID string - if no Probe Response comes back, the saved name doesn't match exactly. Hidden SSIDs are case-sensitive. Check: wlan_mgt.ssid in the Beacon.

Filter: wlan_mgt.tag.number == 201 on 5 GHz Beacons. Tag 201 = Reduced Neighbor Report. If absent - clients relying on out-of-band discovery never know the 6 GHz radio exists. If present, verify the Operating Class and Channel Number match your actual 6 GHz channel.

PSC channels: 5, 21, 37, 53, 69, 85, 101, 117, 133, 149, 165, 181, 197, 213, 229. If the AP is on a non-PSC channel (e.g., channel 49) and RNR is disabled - clients that only scan PSC channels will never find the AP. Completely silent in the capture.

6 GHz mandates WPA3 (SAE or OWE). A WPA2-only client either never sends an Auth Request after reading the Beacon's RSN IE, or gets Status Code 23/24. Filter: wlan_mgt.rsn.akms.type == 8 confirms the AP is advertising SAE-only.

Valid Assoc Request → Response with Status Code 17. RSN IE negotiation never happens. AP hit its max-association limit - a capacity planning failure, not a client issue.

Client proposed a cipher the AP won't accept. Open Assoc Request → RSN Information → Pairwise Cipher Suite List. Compare to AP Beacon RSN IE. OUIs must overlap. Classic WPA3 migration failure.

AP has PMF Required (MFPR bit set). Client Assoc Request has MFPC=0, MFPR=0. AP rejects silently or with Status Code 31. Filter: wlan_mgt.rsn.capabilities.mfpr == 1 on Beacons to confirm. Most common WPA3 migration failure for legacy IoT devices.

AP sends BSS Transition Management Request (WNM Action frame) immediately after a successful association to redirect the client to 5 GHz. Filter: wlan.fc.type_subtype == 13 - look for Category 10, Action 7. If client ignores it, the AP may deauth to force the move.

Controller log: "roam successful." PCAP: Reassoc Response with Status Code 53, followed by full re-auth from scratch. The controller counts the eventual re-auth. The user lost 500–2000 ms of connectivity in between. These are not the same roam.

802.11r enabled on AP but client Assoc Request doesn't include MDIE (Tag 54) - client doesn't support FT. Filter: wlan_mgt.tag.number == 54. Absent = not attempting FT regardless of AP config.

Known issue with Intel AX200/AX210 on Windows: client sends two PMKIDs in Reassoc Request RSN IE during PMK cache operations. Some AP firmware deauths with EAPOL Invalid MIC. Filter: wlan_mgt.rsn.pmkid.count > 1

Assoc success → EAPOL M1 → M2 → M3 → no M4 → Deauth Reason 15. The wrong passphrase is invisible in the frames. Count EAPOL messages between association and deauth: 3 = wrong PSK. 4 = success.

RSN IE in Beacon must match RSN IE in EAPOL M3. A mismatch causes wpa_supplicant to abort the handshake. This is what an evil twin attack looks like in a PCAP - a rogue AP can't reliably reproduce the RSN IE across Probe Responses and handshake frames. WiFi Analyser checks this automatically.

3–4 Discover retransmissions with exponential backoff (2s, 4s, 8s, 16s), then a 169.254 ARP probe. DHCP Discover never reached the server. Check VLAN trunking and ip helper-address.

Discover → Offer → Request → silence. Pool ran out between Offer and ACK. Cross-reference DHCP server logs with PCAP timestamps.

IoT devices kicked with Reason Code 4 (inactivity timeout) must restart the full connection including DHCP when they wake. Appears as a "failure" in monitoring but is actually an idle-timeout configuration decision. Check AP idle-timeout vs device sleep interval.

AP client isolation (peer-to-peer blocking) can block client-to-gateway traffic if both are on the same VLAN. Gateway reachable from wired side, blocked by AP policy. Check AP peer-blocking setting.

Open DHCP Acknowledge → Option 6 (DNS Server). Wrong IP = every query times out. 3 retransmissions per query with no responses confirms server is unreachable. Fix is on the DHCP server, not the client.

HTTP requests return 302 Redirect to portal IP. HTTPS destinations fail silently - TLS can't be intercepted. Force http://neverssl.com to trigger the portal page and confirm.

Device woke from deep sleep, still has old session state in memory, sends data frames before re-associating. AP deauths immediately. In the capture: data frames from IoT transmitter address appear before any Association Request.

AP tries to rotate the Group Temporal Key while device is in deep sleep. No response → Reason 16 Deauth. When device wakes, all broadcast traffic (including DHCP) is broken until full re-association. In the capture: EAPOL Group Key frame (AP → client), no response, Reason 16 follows.

IoT device that lost its AP floods Probe Requests - can be hundreds per second. Creates measurable interference and may trigger AP rate-limiting.

More than 10 Probe Requests per second = scan storm.