04-29-2016 12:02 PM
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: <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?
Solved! Go to Solution.
04-29-2016 08:40 PM - edited 04-29-2016 08:44 PM
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.
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
05-19-2016 10:54 AM
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.