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. 

[Rich R]

Certainly sounds like buggy client so contact Apple.
The bug Marce mentioned suggests a workaround "Enable PMF for WLAN to accept client initial disassociation request" - you could try that?

[t3rebello]

I am enabling PMF as optional (was previously disabled) so we will see if that helps. 

[t3rebello]

Long update since the last but we are still facing this issue. PMF as optional did not resolve the problem.

Cisco's next recommendation is to enable FT, but I do not have much faith in this as the answer, as the clients experiencing the problem are often already authenticated. More to follow.

[listcsbgnetsecurity]

Hello,

We have been experiencing the same issue and the devices that we have in our environment are exactly the same. 9800-CL and 9800-L WLCs and 9136 APs using PEAP with ISE for authentication. Here we have an anchor between two WLCs to make the traffic exit in DMZ. 

I have raised a ticket to TAC and they have recommended us the same, to enable FT and BSS on the SSID. I have enabled on a test SSID a week ago and by now I haven't received any complaint regarding that, but this SSID have only 6 users.

Havey oy had any evolution regarding this case? Have you enabled FT and it has resolved your issue?

[t3rebello]

We did not end up enabling FT yet, but we do still intend on doing that in a maintenance window. The latest development with TAC was a suggestion to disable PMF, as we previously had it set to optional.

I am still collecting debugs to see if we can discover root cause. Are you also only observing this on iOS devices?

[listcsbgnetsecurity]

I wrote earlier here that we haven't faced the issue since we have enabled FT and BSS but a few hours ago we have faced the issue twice. During one occurrence I could got debug logs on the access point, and I sent to TAC to analyze. 

We also observing this issue only in iOS devices.

I will keep you posted regarding any news in this case.

[MHM Cisco World]

The funny thing that in my rest time I see cisco troubleshooting video (no tiktoc) and I see YouTube about this case

This issue for MAC iOS is common in FT enable  WLAN.

What the FT mode ypu use enable or adaptive?

MHM

[listcsbgnetsecurity]

In the initial setup I have configured FT in adaptative mode, and the issue started occurring.

After that I have raised TAC and they advised me to set FT to enabled and put BSS in enabled state as well. 

Just for information other buildings of my company is running FT in adaptative mode end they haven't faced any issue. The difference is regarding the access point model.

[t3rebello]

We still have not found a solution to this issue as of 2/22/2024, even after two separate TAC cases.

Listcsbgnetsecurity----is your WAP model you are having issues with a Catalyst 9136 AP specifically?

We are still working with Cisco to see if we can bridge a Cisco/Apple contact to help find root cause. 

[Rich R]

FYI: in one of the Cisco Live Amsterdam 2024 sessions a few weeks ago they said that although Cisco and Apple are partners it's really difficult (if not impossible) for them to raise customer issues in to Apple.  They said it's always best to open your case with Apple directly and then they can co-op with the Apple engineers on the case.  Without Apple engineers specifically assigned to your problem you're unlikely to make much progress.

[listcsbgnetsecurity]

We are in the same status. We have a TAC opened and I have been requested to perform a packet capture on the air to assure that some packets are being answered to Apple device. To perform that task, I have to convert ona AP in Sniffer mode and wait the issue happens again.

Our access point is exactly that. C9136I-ROW. It seems something related to that combination C9800 with C9136, because in other regions we have C9800 with another WAP model ant this issue has never happened. I have talked to other colleagues in other companies, and they haven't faced such problem.

[listcsbgnetsecurity]

Did you have any progress regarding this issue?

One quick question. In your environment are you using an Anchor scenario?

From my side no news Cisco got an EAP Logoff message from Apple to WLC and insists the I am the responsible to raise a ticket to Apple check that.

[t3rebello]

No progress on the ticket. I ended up in the same place and have also left off with the idea to report the issue to Apple.

So naturally we're stuck at this point. Reporting the issue to Apple feels like a printer's tray directly sending the print job to the paper shredder. 

[listcsbgnetsecurity]

We are exactly in the same status. A completely new Cisco Wifi network with users facing this issue since it has been implemented.

Quick question... Are you using an anchor scenario between controllers?

[listcsbgnetsecurity]

Just one update from my side.

We realized that almost 100% of the cases were facing "Incorrect password" pop-up, had performed roaming in a stand position not just for a different access point but to a different access point in a different frequency. For example, my mobile device was connected into AP-01 in 5Ghz and suddenly it has roamed to AP-02 in 2.4 GHz. Checking on DNA Center we realized that users that complained about the issue, have roamed to a new access point and new frequency.

We have decided to disable 2.4 GHz frequency on that SSID and since of that we no longer noticed the issue. We keep monitoring and talking to service desk user's support. This is just to update you, as Cisco has completely abandoned the case.