Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

deauth reason codes 8 and 62

This thread has been viewed 11 times
  • 1.  deauth reason codes 8 and 62

    Posted Apr 29, 2016 03:02 PM

    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?



  • 2.  RE: deauth reason codes 8 and 62

    EMPLOYEE
    Posted Apr 29, 2016 11:40 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.



  • 3.  RE: deauth reason codes 8 and 62
    Best Answer

    Posted May 19, 2016 01:54 PM

    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.