Reason codes¶
A deauthentication or disassociation carries a reason code from a table of the standard (IEEE 802.11-2020, 9.4.1.7). Think of it as the cause field of a syslog message: the meaning of each value is fixed, the choice of which value to log is the software's, and it differs per vendor and per firmware. Who ended a connection comes first from the order of the frames, which PMF and the 4-way fix whatever the vendor; a code decides by itself only where the standard ties it to one event, and a vendor's use of any other code only where that use was measured. With a vendor whose codes were not measured, a reason alone never gives a side: the disconnect stays undecided, with the order of the frames shown. The rules apply this under Disconnects; the engine keeps the table below in ReasonCode (Engine/Reasons.swift) and the measured uses in ReasonUse, and a test holds this page to both.
The order of the frames¶
In this order, the first that holds decides (HintFacts.Disconnect.Order):
- The client's own frame. A deauthentication or disassociation the client sent: the client began it.
- The client's EAPOL-Logoff before the AP's. The AP's disconnect within 1 s (
orderWindow) after the client's EAPOL-Logoff: the client began it. Before the keys the logoff is in the clear; after them it is encrypted, and the engine knows it by its size, an encrypted data frame of 16 bytes of payload, and by the AP's answer (encryptedLogoff). It came at ten disconnects of the iPhone, the AP45's deauthentication or the iPhone's own disassociation 4 to 31 ms after it (mist-events.md). - The client's own disconnect before the AP's. The AP's disconnect within 1 s after the client's: the client began it, and the AP answered.
- Protected, with the link heard. The AP's disconnect protected by PMF, with a radio listening on the AP's link through the second before and nothing of the client leaving in it: the AP's own decision.
- In the clear on a connection with its keys and PMF. The AP dropped the keys before it sent the frame, after something the capture does not show; on a Mist AP each time the client's logoff. It names no side by itself.
Then the code: one the standard ties to one event decides where its class gives a side (the sender leaving is the sender's, the AP without the client's state or full is the AP's); the others go to the measured uses, and without one the disconnect is undecided.
The classes¶
The rules read the class of a code, not its number.
| Class | Codes | Read by |
|---|---|---|
| leaving | 3, 8 (the sender leaves), 36 (the peer leaves) | client-disconnect for the client's own 3 and 8, and for the AP's disconnect the client began; ap-disconnect for the AP's 3 and 8 (it leaves) and for an AP's 36 the client did not begin |
| a failed login or key handshake | 13 to 24, 48 to 51 | the login rules (credentials, m3-missed, sae-config), not the disconnect rules |
| the authentication ended | 2 | while the client logs in the login rules; after a completed login ap-disconnect, the AP ending a working connection |
| no authentication or association | 6, 7, 9 | ap-disconnect |
| a BSS transition | 12 | the roam rules (ping-pong, weaker-roam) |
| the channel | 34; 65 to 68 | poor-channel for 34; ap-disconnect for the others |
| inactivity | 4; 39 | ap-disconnect by the client's frames before it for 4; ap-disconnect for 39 |
| the AP's policy or capacity | 5, 10, 11, 27 to 33, 35, 46, 47, 71 | ap-disconnect |
| unspecified | 1, 25, 26, 37, 38, 52 to 64, and any code the table does not hold | ap-disconnect |
Every code¶
Decides: the standard ties the code to one event, whoever sends it. The names are short forms of the standard's text.
| Code | Name | Class | Decides |
|---|---|---|---|
| 1 | unspecified | unspecified | – |
| 2 | previous authentication no longer valid | the authentication ended | – |
| 3 | leaving by deauthentication | leaving | yes |
| 4 | inactivity | inactivity | yes |
| 5 | AP cannot handle more stations | the AP's policy or capacity | yes |
| 6 | class 2 frame from a non-authenticated station | no authentication or association | yes |
| 7 | class 3 frame from a non-associated station | no authentication or association | yes |
| 8 | leaving by disassociation | leaving | yes |
| 9 | not authenticated | no authentication or association | – |
| 10 | Power Capability unacceptable | the AP's policy or capacity | – |
| 11 | Supported Channels unacceptable | the AP's policy or capacity | – |
| 12 | disassociated by BSS Transition | a BSS transition | yes |
| 13 | invalid element | a failed login or key handshake | yes |
| 14 | MIC failure | a failed login or key handshake | yes |
| 15 | 4-way handshake timeout | a failed login or key handshake | yes |
| 16 | group key handshake timeout | a failed login or key handshake | yes |
| 17 | RSN element differs in the 4-way | a failed login or key handshake | yes |
| 18 | invalid group cipher | a failed login or key handshake | yes |
| 19 | invalid pairwise cipher | a failed login or key handshake | yes |
| 20 | invalid AKMP | a failed login or key handshake | yes |
| 21 | unsupported RSNE version | a failed login or key handshake | yes |
| 22 | invalid RSNE capabilities | a failed login or key handshake | yes |
| 23 | 802.1X authentication failed | a failed login or key handshake | – |
| 24 | cipher suite rejected | a failed login or key handshake | yes |
| 25 | TDLS peer unreachable | unspecified | – |
| 26 | TDLS teardown, unspecified | unspecified | – |
| 27 | session ended by the SSP | the AP's policy or capacity | – |
| 28 | no SSP roaming agreement | the AP's policy or capacity | – |
| 29 | SSP cipher or AKM requirement | the AP's policy or capacity | – |
| 30 | not authorized in this location | the AP's policy or capacity | – |
| 31 | traffic stream deleted after a change of the BSS | the AP's policy or capacity | – |
| 32 | unspecified, QoS-related | the AP's policy or capacity | – |
| 33 | AP lacks bandwidth for the station | the AP's policy or capacity | – |
| 34 | too many unacknowledged frames due to poor channel conditions | the channel | yes |
| 35 | transmitting outside its TXOP limits | the AP's policy or capacity | – |
| 36 | requested from peer STA as the STA is leaving the BSS | leaving | – |
| 37 | stream or session no longer used | unspecified | – |
| 38 | frames of a mechanism not set up | unspecified | – |
| 39 | timeout | inactivity | – |
| 46 | authorized access limit reached | the AP's policy or capacity | – |
| 47 | external service requirements | the AP's policy or capacity | – |
| 48 | invalid FT Action frame count | a failed login or key handshake | yes |
| 49 | invalid PMKID | a failed login or key handshake | yes |
| 50 | invalid MDE | a failed login or key handshake | yes |
| 51 | invalid FTE | a failed login or key handshake | yes |
| 52 | mesh peering canceled | unspecified | – |
| 53 | mesh peers at their maximum | unspecified | – |
| 54 | mesh configuration policy violated | unspecified | – |
| 55 | mesh peering close received | unspecified | – |
| 56 | mesh peering open unanswered | unspecified | – |
| 57 | mesh confirm timeout | unspecified | – |
| 58 | mesh GTK invalid | unspecified | – |
| 59 | mesh parameters inconsistent | unspecified | – |
| 60 | mesh security capability invalid | unspecified | – |
| 61 | mesh path without proxy information | unspecified | – |
| 62 | mesh path without forwarding information | unspecified | – |
| 63 | mesh path destination unreachable | unspecified | – |
| 64 | MAC address already in the mesh BSS | unspecified | – |
| 65 | mesh channel switch, regulatory | the channel | – |
| 66 | mesh channel switch, unspecified | the channel | – |
| 67 | link on the alternative channel failed | the channel | – |
| 68 | alternative channel occupied | the channel | – |
| 71 | poor RSSI | the AP's policy or capacity | – |
Measured uses¶
A use counts as measured: the vendor, the code, a connection with its keys or a login, the frame protected or in the clear, as in the measurement. Another situation, another protection or another firmware is not covered.
| Vendor | Code | Connection | Frame | Who began | Situation | Measurement |
|---|---|---|---|---|---|---|
| Mist | 2 | with its keys | protected | the AP | the portal's Reconnect, and the AP giving up on a RADIUS server in a reauthentication | mist-events.md |
| Mist | 2 | with its keys | in the clear, without PMF | the AP | the portal's Reconnect on a WLAN without PMF | mist-events.md |
| Mist | 23 | with its keys | in the clear | the client | the AP ending the 802.1X session after the client's EAPOL-Logoff, its Wi-Fi off | mist-events.md |
| Mist | 23 | with its keys | protected | the client | the AP ending the 802.1X session after the client's EAPOL-Logoff, a reconnect with the keys kept | mist-events.md |
| Mist | 36 | with its keys | in the clear | the client | the AP ending the 802.1X session after the client's EAPOL-Logoff, a disconnect with Wi-Fi left on | mist-events.md |
| UniFi | 1 | with its keys | in the clear | the AP | the controller's Reconnect (kick) | testlab-aps.md |
Which action of the iPhone and the Mac gave which reason, and which gave the client's own disassociation instead: mist-events.md. The reason names the action, not whether the user left or reconnected.
The vendor¶
The vendor of the client's AP, for the measured uses (APVendor):
- Mist: a BSS that Mist's events name (
bssid). The AP45's beacons carry no vendor-specific element of Mist's, only those of the Wi-Fi Alliance and Microsoft, so a session without Mist does not know a Mist AP. - UniFi: Ubiquiti's OUI 00:15:6D in a vendor-specific element of the beacons, as every beacon of the U7 Pro Max has.
No Cisco or Aruba AP was measured. Their disconnects decide by the frames and by the codes the standard ties to one event; any other code leaves them undecided, with "reason codes not measured for this vendor".