Wireless Access

we have users that are getting disconnected from the network and I turned on user-debug.   what I am seeing in the log is the following message:

Mar 16 14:26:00 :501080:  <NOTI> |AP hrf2b0112w@172.18.166.90 stm|  Deauth to sta: 34:02:86:4c:54:14: Ageout AP 172.18.166.90-ac:a3:1e:f4:b6:30-hrf2b0112w Client Match
Mar 16 14:26:00 :501000:  <DBUG> |AP hrf2b0112w@172.18.166.90 stm|  Station 34:02:86:4c:54:14: Clearing state
Mar 16 14:26:00 :522296:  <DBUG> |authmgr|  Auth GSM : USER_STA delete event for user 34:02:86:4c:54:14 age 0 deauth_reason 22

 

I am running a 7200 controller with 6.4.2.15 code on it.   it is connected to an ap 215.

 

how do I know what the incompatible RSNE capability is?

 

You should use the following command:

 

show ap client trail-info <client mac>

 

..to get to the bottom if it.

 

 

So here is what I get with this command and now I have even more wonder as to what an "unspecified failure" is, but the one I think the client mentioned was around the
14:26 time frame so is this saying that client match deauthed him and his machine could not handle it?


Client Trail Info
-----------------
MAC BSSID ESSID AP-name VLAN Deauth Reason Alert
--- ----- ----- ------- ---- ------------- -----
34:02:86:4c:54:14 ac:a3:1e:f5:48:e0 halekoa75 hrf2b0107w 851 Unspecified Failure Unspecified Failure

Deauth Reason
-------------
Reason Timestamp
------ ---------
Unspecified Failure Mar 16 15:01:48
Client Match Mar 16 14:26:00
Unspecified Failure Mar 16 13:47:45
Unspecified Failure Mar 16 13:25:39
Ptk Challenge Failed Mar 16 13:22:11
Internal deauth Mar 16 13:22:08
STA has roamed to another AP Mar 16 13:22:08
Internal deauth Mar 16 13:21:57
STA has roamed to another AP Mar 16 13:21:57
Internal deauth Mar 16 13:21:16
Num Deauths:10

Alerts
------
Reason Timestamp
------ ---------
Unspecified Failure Mar 16 15:01:48
Client Match Mar 16 14:26:00
Unspecified Failure Mar 16 13:47:45
Unspecified Failure Mar 16 13:25:39
Ptk Challenge Failed Mar 16 13:22:11
Internal deauth Mar 16 13:22:08
STA has roamed to another AP Mar 16 13:22:08
Internal deauth Mar 16 13:21:57
STA has roamed to another AP Mar 16 13:21:57
Internal deauth Mar 16 13:21:16
Num Alerts:10

Mobility Trail
--------------
BSSID ESSID AP-name Timestamp
----- ----- ------- ---------
ac:a3:1e:f5:48:e0 halekoa75 hrf2b0107w Mar 16 15:01:48
ac:a3:1e:f5:48:e0 halekoa75 hrf2b0107w Mar 16 14:49:50
ac:a3:1e:f4:b6:30 halekoa75 hrf2b0112w Mar 16 14:26:00
ac:a3:1e:f4:b6:30 halekoa75 hrf2b0112w Mar 16 13:47:45
ac:a3:1e:f4:b6:20 halekoa75 hrf2b0112w Mar 16 13:47:45
ac:a3:1e:f4:b6:20 halekoa75 hrf2b0112w Mar 16 13:26:38
ac:a3:1e:f4:b6:20 halekoa75 hrf2b0112w Mar 16 13:25:39
ac:a3:1e:f4:b6:20 halekoa75 hrf2b0112w Mar 16 13:22:11
ac:a3:1e:f5:50:f0 halekoa75 hrf2b0104w Mar 16 13:22:11
ac:a3:1e:f5:50:f0 halekoa75 hrf2b0104w Mar 16 13:22:08
Num Mobility Trails:10

(ORFAMC01W) #

Regards,
Dave

MGTS, CCIE #3272
Enterprise Network Technical Support
Texas Instruments Inc.
Off. 214-567-1212
Cell. 214-478-6258

Please PM me your email address so I can send you a link so I can look at your logs.tar.  "Unspecified failure, is just that...unspecified".  It requires more looking at...

 

Deauth reason 22 is client match.  The controller uses deauths to "move" clients to better access points.  Client match is typically a good thing, (load balancing, band steering, preventing sticky clients), but it can be disruptive.  The best thing you want to do is manage your channels and power to make sure that client match makes fewer "interventions" and clients have to environment to better choose an access point.  Client Match can then be free to move the outlier clients that somehow do not perform well.

 

 

I have sent recommendations about the minimum changes that you should make to make things better.  All of the changes recommended will not cause outages or reboots.  If you do all the recommended changes, you should see an improvement.

 

This issue seems to be a congestion issue.   After discussions with Colin, we made his recomended changes; turn off broadcast and unknown multicasts for all ssids, to turn off 40 mhz channel usage for the 5 ghz radio, change the power levels for the 2.4 ghz radios to min 9 max 12 and for the 5ghz to min 12 max 18).    I believe Colin made these recomendations after looking at the density of our wireless deployment.    After these changes the channel busy times whent down.   before the change we had at least 10 AP's continually in the 60-70 range and at least a couple in the 90 % utilized range,   after I see usually 2 or 3 that are in the 50-60 range and most are below 30%.

The customers that were complaining about not staying connected have stopped complaining