Client devices reporting 'Incorrect Wi-Fi password' on PEAP network

[t3rebello]

Hi folks,

Running a Catalyst 9800-40 WLC. 1463 WAP's connected, predominantly C9136I WAP's. 8,817 active clients with 4,796 clients on our SSID using PEAP authentication via ISE on the back end.  

We are observing clients will frequently disconnect from the network despite having strong RSSI and SNR levels. The behavior manifests as 'Incorrect Wi-Fi Password', even though the user has been previously connected with no issues and their wireless profile is saved on their phone. I have seen this exclusively on iPhone devices at this time. The DNAC log timestamps seem to lineup with the log 'Client has requested it be deleted' 

To remediate, users can simply hit cancel and wait, and they will reconnect to the network. I am working a TAC case parallel to this community post. Just wanted to throw this out there in case other people were seeing this in their environment. 

[t3rebello]

Thank you for the update List, that is very helpful to know. 

Turning off the 2.4 GHz on our production SSID was coincidentally a topic of discussion for other purposes. I think it's high time we start splitting off our dual band SSID's and move towards 5 GHz only, and this is another reason to do so. 

I appreciate you taking the time to come back here and post this, as I never got any traction anywhere else. 

[Rich R]

What WLC version and APSP are you seeing that on?

[listcsbgnetsecurity]

WLC: C9800-CL - 17.12.1 / APs: C9136I-ROW

[Rich R]

Maybe think about upgrading to 17.12.3 - there are quite a lot of bug fixes in 17.12.2 and 17.12.3:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/release-notes/rn-17-12-9800.html#resolved-caveats-for-cisco-ios-xe-dublin-17.12.3
And that's only the more serious bugs which Cisco decided to list in the release notes.  In fact there are a whole lot more which are not listed there.

[listcsbgnetsecurity]

We are considering upgrading to 17.12.3. We are just waiting Cisco become it recommended version that I think it will be soon.

[Leo Laohoo]

---

@listcsbgnetsecurity wrote:
We are just waiting Cisco become it recommended version that I think it will be soon.

---

Don't wait for Cisco.  We are dumping 17.9.X and are about to start going to 17.12.3 -- And I am talking about routers, switches and WLC.  17.9.X is a flaming train wreck.  We've got so many TAC cases around this train and a lot of the workarounds have been "reboot AP, switches, routers" that it is no longer funny.

[t3rebello]

17.12.1 for the controller version. Unfamiliar with the APSP terminology. Is that a separate number than the WLC code train? 

[Leo Laohoo]

APSP means AP Service Pack.  This is a patch for the AP. 

SMU means Software Maintenance Update and this is a patch for the WLC.

[t3rebello]

We haven't applied any service packs or anything other than just upgrading the controller (then subsequently the AP's) to whatever the default service pack would be for controller code 17.12.1.

[Leo Laohoo]

Not all SMU/APSP is good. 

Take, for example, 17.9.4a APSP8.  Installing APSP8 will cause more damage because it was not tested at all.  Instead of fixing, the APSP8 introduced more catastrophic bug like CSCwj45141 & CSCwi96176 (and a lot more).

It is a balancing act to follow recommendations from TAC blindly or to think smart.  

[listcsbgnetsecurity]

Justo to inform and keep you apprised, we started facing the issue again last week and we decided to upgrade our WLC / APs to 17.12.3 IOS-XE version. I will let you know about results. 

[t3rebello]

I have received numerous reports as of recently that the issue was gone all summer when the campus was quiet and only 5% of our user base was on site.

However, now that our user base has returned, reports of this issue have increased exponentially. 

I am currently on WLC version 17.12.2 at the moment. 

[Scott Fella]

Out of curiosity, have your looked at your radius server logs at all? Maybe your AAA server can handle the load.

[t3rebello]

Yes I have, the ISE nodes have absolutely zero indication of a failure. As far as ISE is concerned, the client only has its previous successful authentication. Nothing about a new, failed one when the client experiences an issue. This is what lead me to believe it was iPhone keychain related somehow, but I have no proof. All I have is a wide-scale problem that 'doesn't happen at home' for these users.

[Rich R]

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwe81775
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwk36229
I would upgrade to 17.12.4 and then see if the problem goes away.