Security

Reply
Contributor II
Posts: 55
Registered: ‎03-17-2016

deauth reason codes 8 and 62

Hello,


I've recently made an improvement to my captive portal SSID that allows users to roam.  I am now trying to tackle a frequent disconnect issue that forces users to re-login to the CP SSID and sign in again.  This occurs anywhere between 5 minutes and 60 minutes on average, and based on the debug output I have, this syslog message always prompts the disconnect:

 

sea-aruba-01 authmgr[2034]: <DBUG> <sea-aruba-01 10.10.4.20> Auth GSM : USER_STA delete event for user 78:4b:87:db:f0:67 age 0 deauth_reason 62

The MAC is my phone, which has been disconnected from the SSID numerous times today.  It appears to me that reason code 8 is due to being outside a BSS and actually just needing to come back in range.  Reason code 62 is an unknown for me, because other vendors imply it means:

 

MESH-PATH-ERROR-NO-FORWARDING-INFORMATION: The mesh STA does not have forwarding information for this destination.

 

The weird thing about this is, my phone sits idle on the desk most of the times it gets disconnected, so why would I bet getting this error code?

Wireless newb
Guru Elite
Posts: 20,011
Registered: ‎03-29-2007

Re: deauth reason codes 8 and 62

[ Edited ]

I think you should consider rebuilding your whole configuration from scratch and see if you have the same issues.  You might have made too many changes and now you are unfortunately exposed to unintended behavior.  Start from scratch and see if you have the same issue, because there is not enough information in your post to determine what is wrong.  The defaults typically work well in many circumstances.

Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Validated Reference Design Guides : http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs
Contributor II
Posts: 55
Registered: ‎03-17-2016

Re: deauth reason codes 8 and 62

The issues we saw were related to Client Match, specifically 802.11v.  ArubaTAC was able to identify the issue when timestamps matched up with client match activity and our deauth messages.

 

We added several devices to an unsupported client match list, and none of them disconnect anymore.  We believe this is a bug in the code, or perhaps software issues between the mobile devices and the controller.  Upgrading to 6.4.3.x or higher seems to have fixed the issue.

Wireless newb
Search Airheads
Showing results for 
Search instead for 
Did you mean: