// 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.

Power capability unacceptable

The Power Capability element in the client's AssocReq carries min/max TX power values the AP will not accept, outside what its spectrum-management (802.11h TPC) policy allows. Seen on APs enforcing TPC in DFS or regulatory-controlled 5 GHz channels. Not a cipher problem - for cipher rejection see status 42.

Supported channels unacceptable

The Supported Channels element in the client's AssocReq lists channels the AP finds unacceptable, usually a regulatory-domain mismatch: client and AP on different country codes on a spectrum-managed band. Not an AKM problem - for AKM rejection see status 43.

Authentication rejected (outside policy)

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

Invalid pairwise cipher

The pairwise cipher in the client's RSN IE is one the AP rejects. This is the real "cipher mismatch" code (not 23). Compare the Pairwise Cipher Suite list in the beacon RSN IE vs the AssocReq. Classic WPA2/WPA3 migration failure. See also 41 (group cipher) and 46 (policy).

Invalid AKMP

The AKM suite in the client's RSN IE does not match what the AP accepts. This is the real "AKM rejected" code (not 24). Check the AKM OUI: 00-0F-AC:2 = PSK, :8 = SAE, :3/:4 = FT variants, :24 = SAE-EXT-KEY (Wi-Fi 7).

Cipher suite rejected (security policy)

The AP rejected an otherwise-valid cipher because its security policy forbids it - e.g. a legacy device offering TKIP to a WPA3-only BSS. Distinct from 42: here the cipher is understood but disallowed.

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.

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 