These codes can be extremely useful in troubleshooting wireless issues.
Value | 802.11 or Symbol/WPA Reason Code | Description |
0 | REASON_CODE_80211_SUCCESS | Reserved internally to indicate success |
1. | REASON_CODE_80211_UNSPECIFIED_ERROR | Unspecified Reason |
3. | DISASSOCIATION_REASON_CODE_STATION_LEAVING_ESS | Deauthenticated because sending station has left or is leaving IBSS or ESS |
4. | DISASSOCIATION_REASON_CODE_INACTIVITY | Disassociated due to inactivity |
5. | DISASSOCIATION_REASON_CODE_STATION_LIMIT_EXCEEDED | Disassociated because AP is unable to handle all currently associated stations |
6. | DISASSOCIATION_REASON_CODE_CLASS_2_PKT_FROM_NON_AUTH | Class 2 frame received from non-authenticated station |
7. | DISASSOCIATION_REASON_CODE_CLASS_3_PKT_FROM_NON_ASSOC | Class 3 frame received from non-associated station |
8. | DISASSOCIATION_REASON_CODE_STATION_LEAVING_BSS | Disassociated because sending station has left or is leaving BSS |
9. | DISASSOCIATION_REASON_CODE_STATION_NOT_AUTHENTICATED | Station requesting re-association is not authenticated with responding station |
13. | DISASSOCIATION_REASON_CODE_INVALID_INFORMATION_ELEMENT | Invalid Information Element |
14. | DISASSOCIATION_REASON_CODE_MIC_FAILURE | Michael MIC failure |
15. | DISASSOCIATION_REASON_CODE_4WAY_HANDSHAKE_TIMEOUT | 4-Way Handshake timeout |
16. | DISASSOCIATION_REASON_CODE_GROUP_KEY_UPDATE_TIMEOUT | Group key update timeout |
17. | DISASSOCIATION_REASON_CODE_4WAY_IE_DIFFERENCE | Information element in 4-Way Handshake different from Re-associated request/Proberesponse/Beacon |
18. | DISASSOCIATION_REASON_CODE_MULTICAST_CIPHER_INVALID | Multicast Cipher is not valid |
19. | DISASSOCIATION_REASON_CODE_UNICAST_CIPHER_INVALID | Unicast Cipher is not valid |
20. | DISASSOCIATION_REASON_CODE_AKMP_NOT_VALID | AKMP is not valid |
21. | DISASSOCIATION_REASON_CODE_UNSUPPORTED_RSNE_VERSION | Unsupported RSN IE version |
22. | DISASSOCIATION_REASON_CODE_INVALID_RSNE_CAPABILITIES | Invalid RSN IE Capabilities |
23. | DISASSOCIATION_REASON_CODE_8021X_AUTHENTICATION_FAILED | IEEE 802.1X Authentication failed |
44. | DISASSOCIATION_REASON_CODE_PSP_TX_PKT_BUFFER_EXCEEDED | Symbol defined (non 802.11 standard) code. The Wireless Switch has exceeded it’s time limit in attempting to deliver buffered PSP frames to the Mobile Unit without receiving a single 802.11 PS Poll or NULL data frame. The Wireless Switch begins the timer when it sets the Mobile Unit’s bit in the TIM section of the 802.11 beacon frame for the BSS. The time limit is at least 15 seconds. The Mobile Unit is probably gone (or may be faulty). |
77. | DISASSOCIATION_REASON_CODE_TRANSMIT_RETRIES_EXCEEDED | Symbol defined (non 802.11 standard) codes. The Wireless Switch has exceeded it’s retry limit in attempting to deliver a 802.1x EAP message to the Mobile Unit without receiving a single 802.11 ACK. The retry limit varies according to traffic type but is at least 64 times. The Mobile Unit is either gone or has incorrect 802.1x EAP authentication settings. |
Flavio Donadio says
This is the only 802.11 disassociation code list I’ve found thorugh Google. Nice work and thanks for publishing it.
I am experiencing sudden disconnections on a network with a RFS4000 and AP300s. There’s only one WLAN and about 15 mobile units. I am using WPA/TKIP.
I’m trying to get information through the messages.log file. I am seeing some “reason code 2” messages . I have no idea what it means… The description on the log is not very clear: “datapath requested deauthentication”.
The bulk of disassociation entries on the log have reason code 15 (dot11i 4way handshake timeout). I get some 4s and 8s too.
I can’t find this answer on the net. Please, tell me: who sets this “inactivity timer” mentioned in reason code 4? The MU or the switch?
Thanks again for providing this hard-to-find information!
Michael McNamara says
Hi Flavio,
Thanks for the kind words.
It’s the switch that controls the authentication timer, the time switch switch will wait for set of credentials to use in the 802.1x authentication.
This issue can be especially visible if you have users with tablets, smartphones or PDAs trying to authenticate manually by typing in their username and password in the default 10 second window.
In the example above I set the timeout to 30 seconds with 5 retries allowed.
Good Luck!
Stefan Muehleck says
It seems that Motorola has a massvie Problem with the “reason code 15”.
It’s now my third installation using Wing 4 and WPA/TKip and the second with these problems! Motorola has a workaround for that:
Reduce the basic rates of the AP (default adoption list) of your wlan to the lowest two ones (802.11a 6+9MBits). Motorola says (not official) it’s a design problem with Wing 4 and Wing 5! The speed the AP sends the keys is to high. If this won’t help then try the following (only via Terminal, Enable telnet on the RFS):
1. enable
2. configure terminal
3. wireless
4. wlan 1 dot11i handshake timeout 300 retransmit 5
5. write mem
I’ve done all of these but my customer is very disapponited about the RFS6000!
The WT4090 are much slower and they get often disconnected 30-40 times a day (30 APs, 70 MUs)
The old WS5100 (2.1) was much better, the speed was higher and the whole WLAN was much more stable, maybe 1 or 2 disconnections a day, more speed!
Motorola Germany don’t know how to fix it, im about to pull the RFS6000 out and reinstall th WS5100 . . . .
So long
Stefan
Michael McNamara says
Hi Stefan,
I have one site with 2 RFS7000s, 220 AP300s and 859 MUs and while we have some issues it works pretty well.
I’ve heard of some issues with the handhelds and terminals, are your devices roaming? What model of AP are you using?
It’s my experience that people generally feel the wireless is “getting slower” because your usually adding equipment to it. Wireless is a finite resource with only so much bandwidth so the more you add the slower it will be for everyone.
If you want to discuss further please post in the forums, http://forums.networkinfrastructure.info/motorola-wireless-lan-switches/
Cheers!
Ali says
Wow these 4090’s are a pain. I’m having issues with them especially at one of our facility where they take forever to roam to the closest AP. If I walk with a device and it is connected to AP-X and I start to walk away from it towards AP-Y. It will not roam to AP-Y but will stay connected to AP-X until it hits a dead spot, then disconnect and re connects to AP-Y.