Mobility Express Wifi Login Issues

[davem1]

I've got 7 AIR-AP1852I-B-K9 access-points with one acting as the WLC and the others as CAPWAPS.  They are running Mobility Express version 8.5.105.0.

There are three WLANs and on occasion users will get booted from any one of them and are unable to log back in. They get an error saying that the password is invalid.  It usually takes multiple attempts to successfully log back in and sometimes they have to forget the WLAN and then re-enter the password information. 

My first suspicion was proximity to the APs, but it does occur when users are directly under them. I'm trying to figure out what other possibilities there are; proximity, interference from other wireless L3 devices, transitioning between APs and hitting dead zones. Could also be the version but I haven't a done an in-depth look into that yet.

Any other possibilities or suggestions to look at?

[marce1000]

 - On the authentication server or services look at the auth-logs when this happens, check if you can find more info there.

 M.

[davem1]

It doesn't happen all of the time, but I'll try and grab the logs the next time it happens.  Here is what is in the logging buffer right now.

*CAPWAP DATA: Apr 11 21:34:36.150: %RRM-3-RRM_LOGMSG: rrmClient.c:1531 RRM LOG: iapp chd client stat , Unable to find AP 4c:bc:48:37:38:00
*spamApTask0: Apr 11 21:33:29.887: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7749 Did not receive heartbeat reply; AP: 4c:bc:48:37:3b:80
*spamApTask0: Apr 11 21:33:23.930: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7749 Did not receive heartbeat reply; AP: 4c:bc:48:37:38:00
*spamApTask0: Apr 11 21:28:23.603: %CAPWAP-3-MDNS_INIT_NOT_DONE: capwap_ac_sm.c:8359 mDNS module is not initialized yet, but a mDNS AP : 4c:bc:48:37:36:60 has joined.Aggregated query is not sent until mDNS init.

*Dot1x_NW_MsgTask_0: Apr 11 20:23:06.920: %DOT1X-3-INVALID_REPLAY_CTR: 1x_eapkey.c:452 Invalid replay counter from client 60:83:73:74:8f:d7 - got 00 00 00 00 00 00 00 03, expected 00 00 00 00 00 00 00 04
*Dot1x_NW_MsgTask_0: Apr 11 20:23:06.919: %DOT1X-3-INVALID_REPLAY_CTR: 1x_eapkey.c:452 Invalid replay counter from client 60:83:73:74:8f:d7 - got 00 00 00 00 00 00 00 02, expected 00 00 00 00 00 00 00 03

*apfMsConnTask_0: Apr 11 21:03:48.548: %APF-3-PREAUTH_FAILURE: apf_80211.c:14379 There is no PMK cache entry for clientb8:63:4d:a3:b9:a0. Can't do preauth

*apfMsConnTask_0: Apr 11 19:22:53.357: %LWAPP-3-INVALID_AID2: spam_api.c:2076 Association identifier 3 for client f0:8a:76:73:34:88 is already in use by 70:f0:87:64:23:bb for AP 4c:bc:48:37:3b:60 slot 0 vap 3
*apfMsConnTask_0: Apr 11 19:22:49.242: %APF-3-AID_UPDATE_FAILED: apf_80211.c:9079 Error updating Association ID for REAP AP Client4c:bc:48:37:3b:60 - AID 3

[marce1000]

                       CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7749 Did not receive heartbeat reply

 - For starters , those messages should not appear and indicate network-connectivity problems between the AP's and the controller. Try to resolve that first.

 M.

[patoberli]

First of all, upgrade. 8.5.105.0 is a horrible release with a lot of bugs.
I suggest going to 8.8.130.0 or even the brand new, but TAC recommended 8.10.121.0. Check the release notes for valid upgrade paths.

[davem1]

Based on what was in the logs, and more Google searching, part of the problem could be the CAPWAPs having their IPs assigned via DHCP instead of being static. I had noticed that the uptime kept resetting, yet the switch logs showed that they never lost power.

Once they were given static IP addresses, everything seems to have settled, but we're waiting until the end of the week to determine if the issue is indeed fixed.

We have other customers that are using the same version with no issues, but we definitely do plan on upgrading to the Cisco's suggestion version. The lack of some features is a major pain.

[marce1000]

 - Ok, but in general using static IP's for AP's is not considered good practice. Most common is DHCP using option 43 to denote the controller IP-addres for the AP. I suggest you revert to DHCP after the upgrade.

 M.