// reference · 802.11 status & reason codes

When your PCAP says something went wrong — here's what it actually means

Status codes live in association and authentication responses. Reason codes live in deauth and disassoc frames. Every non-zero code is telling you exactly why the client was rejected or disconnected — but only if you know what to look for.

— Shankar K. · Source: IEEE 802.11-2020 + field notes

⌕

// how to find these in wireshark

wlan_mgt.fixed.status_code

Status code field in assoc/auth response frames

wlan_mgt.fixed.reason_code

Reason code field in deauth/disassoc frames

Status codes appear in Association Response, Reassociation Response, and Authentication Response frames. Code 0 = success. Anything else = rejected, and the code tells you exactly why.

Code

Name

What it means in your PCAP

Success

Association or authentication accepted. You should see EAPOL frames next if it's an enterprise network.

Unspecified failure

AP rejected the request but didn't say why. Usually a policy decision — RADIUS rejected the user, or AP-side ACL. Check RADIUS logs, not the PCAP.

Cannot support all capabilities

Client's Capabilities field in AssocReq contains a bit the AP doesn't support (or vice versa). Compare the Capability Information fields frame by frame.

Association denied (unspecified reason)

AP denied association without a specific code. Common when the AP is rate-limiting associations or a vendor-specific policy blocked the client.

Association denied — timeout

AP sent a challenge text that the client didn't respond to in time. Less common with modern WPA2/WPA3 — more of a legacy open auth issue.

AP full (too many associations)

AP has hit its maximum client count. Check the AP's max-association config. If this happens at a venue, it's a capacity planning failure.

Cipher suite rejected

Client proposed a cipher in its RSN IE that the AP doesn't accept. Compare RSN IE in the beacon vs RSN IE in the AssocReq — the mismatch will be visible. Classic WPA3 migration failure.

AKM suite rejected

The authentication method (SAE, PSK, 802.1X, FT variant) in the client's RSN IE doesn't match what the AP accepts. Check the AKM OUI: 00-0F-AC:2 = PSK, :8 = SAE, :3/:4 = FT variants.

Authentication rejected (outside policy)

AP policy explicitly rejected this client — MAC filter, time-of-day restriction, or guest portal timeout. Not a protocol issue.

53 KEY

Invalid PMKID

The most misdiagnosed roaming failure. Client attempted 802.11r Fast Transition but the AP rejected the PMKID. This means the PMK-R1 key hierarchy is broken — the key the client thinks it has doesn't match what the AP expects. Logs say "roaming success." The PCAP says status 53. They're not the same roam. Read the full post →

FILS authentication failure

Fast Initial Link Setup (802.11ai) authentication failed. FILS is used for sub-100ms roaming in stadium/venue deployments. Failure usually means expired FILS keys or misconfigured FILS domain.

Reason codes appear in Deauthentication and Disassociation frames. They tell you who initiated the disconnect and why. A burst of deauths with the same reason code is almost always a pattern worth investigating.

Code

Name

What it means in your PCAP

Unspecified reason

Catch-all. Could be AP restart, firmware issue, or vendor-specific policy. Check what initiated the deauth — AP or client — using the transmitter address.

Previous auth no longer valid

AP is telling the client its authentication has expired. Common after AP reboots when clients still think they're authenticated. Client should immediately re-authenticate.

Deauth — STA leaving BSS

Client-initiated disconnect. Normal when a client shuts down or roams away. If you see this followed immediately by a reassoc to another AP — that's a healthy roam. If followed by nothing — device powered off.

Disassoc — inactivity timeout

AP kicked the client for being idle too long. Check the AP's idle-timeout setting. IoT devices that sleep aggressively (smart plugs, sensors) trigger this frequently. Not a protocol failure — a configuration decision.

Disassoc — AP can no longer handle

AP is overloaded and dropping clients. If you see this at scale, it's a capacity planning issue — too many clients on one AP, not enough APs deployed.

Class 2 frame from non-auth STA

Client sent a data frame before completing authentication. Usually a driver bug or a client that didn't properly complete the auth handshake before sending data.

Class 3 frame from non-assoc STA

Client sent a data frame before completing association. Similar to code 6 but at the association stage. Often seen during botched roaming where the client sends data before the new AP has fully accepted the reassociation.

Disassoc — STA leaving BSS

Client-initiated disassociation (softer than deauth reason 3). Normal roaming or planned disconnect. If a client alternates between reason 3 and 8, it may be confused about whether to deauth or disassoc during roaming.

15 KEY

4-way handshake timeout

Most common enterprise Wi-Fi failure code. The EAPOL 4-way handshake didn't complete in time. Check EAPOL frames — are all 4 present? If message 2 is missing, the client didn't respond (driver issue or wrong PSK). If message 4 is missing, the AP timed out waiting for the final ACK.

Group key handshake timeout

GTK (Group Temporal Key) renewal failed. The AP tried to rotate the broadcast key but the client didn't respond. Can cause all broadcast/multicast traffic to fail for that client even when unicast is fine.

IE mismatch between probe resp and auth

The RSN IE or capabilities the client saw in the probe response don't match what it got in the authentication response. Can indicate a rogue AP mimicking your SSID but with different capabilities. Check this with WiFi Analyser's evil twin detector.

23 KEY

802.1X authentication failed

EAP authentication was rejected. RADIUS sent an Access-Reject. Usually: expired certificate (EAP-TLS), wrong password (PEAP), or RADIUS server unreachable. Look for an EAP-Failure frame immediately before this deauth — the EAP exchange will show you exactly where it failed.

Disassoc — unspecified QoS reason

QoS-related disconnect that doesn't fit a specific code. Can happen when a client and AP can't agree on QoS parameters for a TSPEC (traffic specification). More common in Voice over Wi-Fi deployments.

Requested from peer STA (FT roam)

Client is leaving as part of a 802.11r Fast Transition roam to another AP. This is the normal deauth that precedes a clean FT roam. If you see this without a subsequent reassoc — the FT to the target AP failed.

WiFi Analyser decodes these automatically

Upload a PCAP and every deauth/disassoc reason code and status code is flagged, explained, and linked to the relevant client session.

try it free ↗

SK

— Shankar K., Wi-Fi engineer, Irving TX
 Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks 

// share this page

// also on this site

← previous

reference

Wireshark Filter Reference

next →

downloads

Frame Lab — free PCAPs

SK

— Shankar K., Wi-Fi engineer, Irving TX
 Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks 