Win10 clients can not connect/roam to 2802i-e but roams fine with 2702i-2 in the same area

[hamid.nabil1]

Client can not connect to 2802 AP while roaming from 2702. I see the following msgs in AP logs. As soon as client is in 2702 radius then it connects again. Let me know if you need more info. Any help is appreciated.

Feb 26 12:26:46 kernel: [*02/26/2019 12:26:46.8048] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (72 64)
Feb 26 12:26:56 kernel: [*02/26/2019 12:26:56.7994] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (88 64)
Feb 26 12:27:06 kernel: [*02/26/2019 12:27:06.8232] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (104 64)
Feb 26 12:27:16 kernel: [*02/26/2019 12:27:16.8400] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 12:27:26 kernel: [*02/26/2019 12:27:26.8202] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 12:27:36 kernel: [*02/26/2019 12:27:36.8315] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 12:27:46 kernel: [*02/26/2019 12:27:46.4437] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 12:27:56 kernel: [*02/26/2019 12:27:56.4335] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 13:03:48 kernel: [*02/26/2019 13:03:48.1204] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (72 64)
Feb 26 13:03:58 kernel: [*02/26/2019 13:03:58.1152] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (88 64)
Feb 26 13:04:08 kernel: [*02/26/2019 13:04:08.0921] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (104 64)
Feb 26 13:04:18 kernel: [*02/26/2019 13:04:18.0919] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (120 64)
Feb 26 13:04:28 kernel: [*02/26/2019 13:04:28.0926] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (136 64)
Feb 26 13:04:38 kernel: [*02/26/2019 13:04:38.1088] macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (136 64)
Feb 26 13:15:37 kernel: [*02/26/2019 13:15:37.8342] Sending GTK KEY message failed hostapd CISCO GTK_KEY bbc7xxxxxxxxxxxxxxx
Feb 26 14:17:04 kernel: [*02/26/2019 14:17:04.2767] Sending GTK KEY message failed hostapd CISCO GTK_KEY 3567cxxxxxxxxxxxxxx
Feb 26 15:18:55 kernel: [*02/26/2019 15:18:55.9041] Sending GTK KEY message failed hostapd CISCO GTK_KEY 16373xxxxxxxxxxxxxx
Feb 26 16:20:48 kernel: [*02/26/2019 16:20:48.3322] Sending GTK KEY message failed hostapd CISCO GTK_KEY 8bb13xxxxxxxxxxxxxx
Feb 26 17:21:54 kernel: [*02/26/2019 17:21:54.0340] Sending GTK KEY message failed hostapd CISCO GTK_KEY 12945xxxxxxxxxxxxxx
Feb 26 18:22:57 kernel: [*02/26/2019 18:22:57.2691] Sending GTK KEY message failed hostapd CISCO GTK_KEY 45d8bxxxxxxxxxxxxxx
Feb 26 19:24:34 kernel: [*02/26/2019 19:24:34.6204] Sending GTK KEY message failed hostapd CISCO GTK_KEY c3d22xxxxxxxxxxxxxx
Feb 26 20:26:10 kernel: [*02/26/2019 20:26:10.3756] Sending GTK KEY message failed hostapd CISCO GTK_KEY 8a5c2xxxxxxxxxxxxxx
Feb 26 21:27:15 kernel: [*02/26/2019 21:27:15.4937] Sending GTK KEY message failed hostapd CISCO GTK_KEY 1ee2dxxxxxxxxxxxxxx

[ajc]

Hi everyone, similar problem here unfortunately I cannot go to 8.5 or above version because we still have a significant number of 1040,1140 old AP's that we have not decomissioned or replaced yet. Question, what is the best version you suggest because I see 2 of them as indicated by TAC:

8.3.150.6 or

8.3.143.15

Unfortunately, we move from the STABLE CAPWAP CentralSW/CentralAuth to the "nightmare" Flexconnect and now every single user is complaining about unable to connect, disconnections, etc etc.

I have WPA gtk-randomize DISABLED

I am proceeding to disable ALL the 802.11k/v/r if it is there

running 8.3.143.0 which has been stable for over 2 years

I would like to know your comments is about LOAD BALANCING ON FLEXCONNECT, the behavior is totally different to CAPWAP CentralSW/Authc. I have seen on the AP's logs multiple error messages that points to the Association code = 0 (success) and immediately the disassociation code 5 (instead of JUST having the code 17 that works perfectly on CAPWAP). In addition to that I notice something that pointed to the wrong radius aggressive failover config that I had and it was removed.

thanks

What else would you suggest?

thanks

[Scott Fella]

You should start a new thread and provide more information. Maybe the wlan config, what you are seeing not what user are saying. Can you replicate the issue? FlexConnect is stable if it’s setup right as the same for local mode.

[ajc]

Hi Scott,

Thanks for replying. Quick question, If I have an stable CAPWAP Central SW/ Central Authc (local mode) and the only change to implement flexconnect is the advanced tab on each SSID + Flexc ACL + FlexcGroups + Flexc WLAN/VLAN mapping, 1 AP group for all Flexc sites, 4 default interfaces for all Flexc Sites, etc; I mean minor changes, why all of the sudden so many problems with WIFI connectivity?. I followed the Flexc implementation documentation using as baseline my Local Mode WLC configuration.

In any case, I am opening another thread as suggested and posting my findings.

[Scott Fella]

Those are not little changes. Anyways, what are you seeing and can and how are you replicating the issue. All devices or certain one. I will look out for a new thread.

[ajc]

FINAL NOTE:

A TAC case was opened, I am also getting this error message on AP's 2800, hoping I am not hitting the following bug (the AP is already in connected mode) that could explain why authentication is failing even though everything looks normal.

hostapd: apr1v2:RADIUS: No authentication server configured

BUG = https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs45806/?rfs=iqvred

[HaifengLi]

Do you have debug client log when things happen?

[Paccers]

Bumping this thread as I am running in to the exact same issue in our environment and it's driving me nuts!

We have 2802i model APs on 8.3.143.0 code running Flex mode with local switching and we are having multiple units all at once stop allowing auth from clients. The following two types of logs are seen on the APs:

1. macMgmtMlme_AssocReAssocReqHandler[line 2339] out of boundary (<two numbers listed>)

2. Sending GTK KEY message failed hostapd CISCO GTK_KEY <key>

The only thing that resolves this in the short term is restarting the affected units.

I'm going to assume at this point it's fixed in a higher code version but I'd really like to get a bug ID at least that I can reference when trying to explain it to management! 

[HaifengLi]

I am suspecting that this symptom is hitting CSCvk17370.

You can upgrade to 8.8.151/8.8.100/8.9.100 and later, and then observe for a while.

[a.stephan]

We have updated our 5508s to Hotfix-version 8.3.143.15. That fixed the issue for us. Would be less impact than updating from 8.3 to 8.8 ...

[Paccers]

Ye 8.8 is not on the cards for me unfortunately, can't even go to 8.5.x as I still have 1142s going strong! (yes I know.. trying to get rid of them).

I was already on planning to bump up to 8.3.150.0 to fix some other bugs so I'll shift up to that and see how it goes :)

[a.stephan]

Yeah same for me, also got some 20 pcs of 1142 still online.

Please also make sure to check the patch release dates. iirc the 8.3.150.0
is older than the 8.3.143.15 and thus may not contain the relevant bug
fixes!

[patoberli]

Please check with TAC, there is an Escalation image available, but only upon request. Your bug is sadly not listed, but some other interesting bugs.
See here for more details:
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-tac-recommended-aireos.html#anc13