Deauth Reason Codes: Debug WiFi Disconnect Issues Fast
When troubleshooting WiFi networks, one of the most confusing things administrators encounter are deauth reason codes. These codes are generated when a client device disconnects from an access point (AP) and are part of the IEEE 802.11 wireless standard.
Unfortunately, the official documentation can be difficult to track down, and much of the information online is outdated or incomplete. This guide provides a complete list of deauth reason codes with explanations to help you quickly understand what's happening on your network.
TL;DR: A deauthentication reason code is the number an access point reports when it disconnects a client. Code 4 means the client went idle. Code 5 means the AP is full. Codes 15 to 17 mean the WPA handshake failed. Codes 3 and 8 mean the client left on its own and nothing is wrong. The full table of every code is below.
Deauth reason codes are part of the IEEE 802.11 standard, but the official documentation is hard to find and most of what circulates online is incomplete or wrong. This page is the complete list, with what each code means in practice rather than what the specification calls it.
What Are Deauth Reason Codes?
Deauth reason codes (also called WiFi deauthentication reason codes) are numeric values returned by an AP when a client is disconnected. Each code corresponds to a specific cause, such as inactivity, failed authentication, or insufficient resources.
Common codes include 802.11 deauth reason code 7 (class 3 frame received from nonassociated station) and reason code 17 (disassociated due to inactivity).
These codes are critical for network engineers, IT admins, and support teams who need to debug connectivity issues. For example, knowing whether a disconnect happened due to inactivity or because the access point was overloaded can drastically change the troubleshooting approach.
The Five You Will Actually See
Code 4, disassociated due to inactivity. The client went quiet and the AP reclaimed the slot. Normal behaviour, and the most common code on any guest network. Only a problem if guests are being forced to log in again each time.
Code 5, AP cannot handle more clients. The access point is at capacity or load balancing is moving the client. This is a density problem, not a configuration one, and it appears at predictable times of day.
Code 15, 4-Way Handshake timeout. The WPA2 or WPA3 handshake did not complete. Usually a wrong passphrase, or a RADIUS server that did not answer in time.
Code 3 and Code 8, the client is leaving. These are sent by the device, not the AP. Code 3 is a manual disconnect or shutdown. Code 8 is roaming to a stronger signal. Neither indicates a fault, and both are frequently misread as errors.
Code 1, unspecified reason. The AP dropped the client and reported nothing useful. Correlate with timestamps from other clients: if several disconnect together, look at the AP rather than the devices.
Complete List of Deauth Reason Codes
802.11 deauthentication and disassociation reason codes
Complete reference
Authentication or encryption
Capacity or QoS
Normal behaviour
Reserved
| Code | Reason | What it means in practice |
|---|
| 0 | Reserved | Not used. Normal operation, no disconnect reported. |
| 1 | Unspecified reason | A catch-all. The AP dropped the client without reporting a specific cause. |
| 2 | Previous authentication no longer valid | The client is associated but its authentication has expired or been revoked. |
| 3 | Deauthenticated because sending STA is leaving | The client is leaving the network. Usually a manual disconnect, WiFi toggled off, or device shutdown. |
| 4 | Disassociated due to inactivity | The client went idle for longer than the AP's timeout. The most common code on guest networks. |
| 5 | Disassociated because AP is unable to handle all associated STAs | The access point is at capacity, or load balancing is pushing the client elsewhere. |
| 6 | Class 2 frame received from nonauthenticated STA | The client sent data before completing authentication. |
| 7 | Class 3 frame received from nonassociated STA | The client sent data before completing association. Often seen after an AP reboot. |
| 8 | Disassociated because sending STA is leaving BSS | The client left this access point, usually roaming to a stronger signal. |
| 9 | STA requesting association is not authenticated | The client tried to associate before authenticating. |
| 10 | Disassociated because of unacceptable power capability | The client's transmit power element does not meet the AP's requirement. |
| 11 | Disassociated because of unacceptable supported channels | The client does not support the channels the AP requires, often a regulatory domain mismatch. |
| 12 | Reserved | Not used. |
| 13 | Invalid information element | A malformed or unexpected element was received in a management frame. |
| 14 | Message integrity code (MIC) failure | An encrypted frame failed its integrity check. Can indicate interference or a key mismatch. |
| 15 | 4-Way Handshake timeout | The WPA2 or WPA3 handshake did not complete. Usually a wrong passphrase or a RADIUS timeout. |
| 16 | Group Key Handshake timeout | Group key negotiation failed after the initial handshake succeeded. |
| 17 | Information element in 4-Way Handshake differs | Key information was inconsistent between frames. A configuration mismatch rather than a client fault. |
| 18 | Invalid group cipher | The group cipher requested is not valid or not supported by both sides. |
| 19 | Invalid pairwise cipher | The unicast cipher does not match between client and AP. |
| 20 | Invalid AKMP | The authentication and key management protocol is not supported. |
| 21 | Unsupported RSN information element version | The client and AP are using incompatible security protocol versions. |
| 22 | Invalid RSN information element capabilities | The security capabilities advertised are not compatible. |
| 23 | IEEE 802.1X authentication failed | The RADIUS or 802.1X exchange was rejected. Check the server, the shared secret, and the certificate. |
| 24 | Cipher suite rejected because of the security policy | The AP's policy blocked the requested cipher. |
| 25 – 31 | Reserved or vendor-specific | Not defined for general use. Some vendors and later amendments use this range. |
| 32 | Disassociated for unspecified QoS-related reason | Quality of Service policy rejected the client without a specific cause. |
| 33 | Disassociated because AP lacks sufficient bandwidth | Not enough bandwidth remains for this QoS client. |
| 34 | Disassociated because of excessive unacknowledged frames | Frames were lost repeatedly. Points at interference, distance, or a weak signal. |
| 35 | Disassociated because STA transmitted outside the TXOP limit | The client transmitted outside its permitted airtime slot. |
| 36 | Requested from peer STA as the STA is leaving the BSS | The peer station is leaving, typically a reset or clean disconnect. |
| 37 | Requested from peer STA as it does not want to use the mechanism | The peer declined a requested mechanism such as block ack. |
| 38 | Requested from peer STA as it received frames using the mechanism for which a setup is required | Frames arrived before the required setup exchange completed. |
| 39 | Requested from peer STA due to timeout | The peer timed out waiting for a response. |
| 45 | Peer STA does not support the requested cipher suite | The peer cannot use the cipher that was proposed. |
| 46 – 65 | Reserved or vendor-specific | Not defined for general use. |
| 99 | No reason code reported | Not part of the standard. Some controllers log this when the disconnect cause is unknown. |
Reason codes are a 16-bit field, so values from 0 to 65535 are possible. Anything outside the ranges above is either vendor-specific or a logging artefact rather than a standard code. Values also differ slightly between deauthentication and disassociation frames, and some vendors relabel them in their own dashboards.
Why These Codes Matter
Knowing the specific reason code behind a WiFi disconnect allows you to:
- Troubleshoot faster - immediately identify whether the issue is authentication, load, or security related.
- Improve user experience - by diagnosing recurring disconnects and fixing root causes.
- Optimize networks - especially in enterprise or hospitality environments where guest WiFi stability is critical.
For example:
- If you see many Code 4 (inactivity) disconnects, you may need to adjust session timeouts.
- If Code 5 (AP overloaded) occurs often, you may need load balancing or more access points.
- Handshake failures (Codes 15–17) usually point to WPA2/WPA3 configuration issues.
For a complete setup walkthrough, check out our BIG GUIDE to setting up Spotipo hotspots with UniFi devices (NEW UI).
