Why do I have so many errors about "Client entered wrong password."?
My computer was connected automatically and I made sure my password was correct.
Solved! Go to Solution.
Meraki PM Team
Since the client entered the correct password and set it to automatically connect to the network, I don't think it was the password of the password that caused the problem.
Hi @Puyi @that’s not what’s being reported in the dashboard. I would never take what the end users saying as being correct until you can prove otherwise
I have the same problem on my network (raised here).
A little frustrating, I've had to reset the network settings on my iPhone to fix it short term.
Which firmware are you on?
I also suspected at first that the user had entered the wrong password.But when I checked my backup device in the log, I made sure it wasn't a mistyped password
I think the best is to come out with a new SSID and set with a new password.
A lot of time is the autosave passwords that cause the problems. You will never know how many users are still using the old password.
I am having the same issue with users that have been connected for a long time then one day they need to delete the network and re enter the key. it happens on windows IOS and Android so i am assuming it is not the end device having the issue.
BTW this comment does not in any way solve the problem
I'm facing the same issue.
Macbook and PC get this "wrong password" log whereas they can usually be associated and authenticated. It seems to happen the most of the time when roaming.
AP : MR55
Version : MR 26.7
If Meraki is listening,
I too have this same issue ["client entered wrong password"] when associating with either radio [2.4 & 5] and often failing multiple times. I had originally thought it was related to client roaming between weaker APs or stationary between two similarly transmit powered APs. HOWEVER, I have one of these clients sitting in my office under only one AP and the log still reports the same error from time to time and I'm not even using it! No power saving and no interference of any kind.
Any client settings to change or set would be helpful. Any AP settings to change or set would be helpful.
UPDATE: I turned off the 5 GHz radios on the involved APs. This fixed the problem: no more failed passwords or difficult associations.
I observe the same issue with iOS clients only. Have not seen it with the Mac devices. On the iOS devices I selected "Forget Network" and added the network again, entering THE CORRECT PASSWORD, and the devices joined the wireless network. Errors resumed within one hour.
Errors occur on only one SSID out of three and only on one of the APs where that SSID is enabled.
I think we have another thread about the same issue.
In my case those are not PSK but 802.1x Meraki Auth errors, but behavior is the same.
It seems that its connected with roaming between APs.
I've tried to open case about that but they wanted live packet captures, which was difficult as I can't say what are the exact conditions for it to happen.
But there is certainly an unresolved bug in several firmwares.
I have also "Client entered wrong password" in more than 30 networks we have. not only iOS but also android and Windows 10 computers also having the same issue. We know for sure that the password is 100% correct.
I opened a case with Meraki support and they asked me to capture a live packet via wireshark and sent it to Meraki support. Still waiting for the reply.
As I wrote in the other thread about this problem - try disabling 802.11r. In my case it solved the problem completely . Of course it affects roaming performance - but in my case it's better as those auth errors caused delays in roaming.
The 802.11r has been never enabled in our network and also 802.11r is only for iOS while this problem happens in all types of clients.
To be clear, Adaptive 802.11r is only for iOS devices, pure 802.11r is not restricted, but there is not much devices supporting it.
In my case problem was only with iOS devices and disabling 802.11r solved it.
Seems not to be that simple as I thought.
Same here. 802.11r is disabled and I have one single AP in my network (so there is no roaming or anything)
All types of clients experience this issue.
Firmware: MR 26.7
Unfortunately I must agree with you both.
I have those errors again. Disabling 802.1r just reduced them significantly, but they are still there. It is 802.11x not PSK in my case, which might be also a contributing factor.
It is not just the errors on the dashboard but the clients having regular disconnections while roaming. We have mostly problem in our warehouse where clients moving around.
I've just looked at dashboard of another big network (I was not looking at it since I've encountered errors in my network) consisting of MR52's and using WPA2-PSK for its main SSID.
802.11r disabled and there is a LOT of authentication errors ("bad password"). So You are absolutely right 802.11r does not improve anything when using PSK.
Called them and they say they have problems with their devices saying frequently there is bad password or they just disconnect when roaming.
TAC still not seeing this problem.
I originally thought it was user error but I see it on so many devices and even my own devices just stop working and seeing bad password for themn in the log. I am not sure how a saved password in many devices start sending the wrong password.
not sure why TAC is so reluctant to look deeper into this issue
I realize it has been a couple of weeks since the last reply, but I am not finidng much else out there in terms of a possible resolution.
I have an MX64, a MS220, and a MR33. Obviously as most people have pointed out through any number of threads this is an issue at the MR33 side of the house.
In my case, all end devices, at one point or another, has had the Client entered wrong password.
type='WPA-PSK auth fail' associated='false' radio='1' vap='1' error.
I cannot find any single reason why after 6 weeks shy of 3 years every single device would start erroring. I have 47 days on my license and at this point I do not think I will be renewing. Sad as I have been a Meraki customer since prior to the Cisco purchase.
Other than changing from WPA 2 to WPA 1 and 2, turning off meshing, allowing rogue, etc. has anyone managed to find a solution?
Had a long discussion and debug session with TAC about this without any clear output.
They state that those are not auth errors but interpretation of events by Wireless health - which are not related to authentication.
I'm not convinced as sometimes my devices really pop-up a window saying that password is incorrect and requiring to type it again.
I have watched in real time, on a Win10 device, pings drop, then while still connected to the wireless network Windows will state that the connection has no internet. So while the statement from Cisco may be true in that the auth doesn't actually drop from the device to the WAP, something is truly amiss.
I'm having the same error and ping drops on Windows 10 clients. I just updated to 27.1 and observing to see if it still happens.
MS120 > MR33 ----- MR33 > MS120 > MX65
We are having the same issue and I'm seeing it with multiple customers, including our own APs. We have made Cisco recommended changes but it's only reduced the problem and not fixed it. It's obviously some kind of bug in the firmware that was introduced in more recent firmware revisions. Very disappointing.
On my test kit have today reverted from firmware 26.6.1 to previous 25.14 and the problem (repeated occurrences of "Client entered wrong password") has gone away.
So, dear Cisco, whatever is up with your firmware? And when can we expect a resolution? Because staying on old firmware, or living with this problem is not the answer 🙂
The problem still exists with MR 26.8 firmware.
I was running MR33 with MR 26.7 and upgraded to 26.8 hoping that it will fix the problem but no. It still exists.
Support is not helpful. I don't know what to do.
Spoke with Cisco support on Friday. There is a bug that in the v26 firmware that is being worked. We had Cisco revert our APs back to firmware 25.14, which is the latest 25x firmware. That has fixed the problem. You will need to contact support to have them revert back and then peg each AP to that version until Cisco has a fix.
I asked support to downgrade my MR33 access points to 25.14. They work reliably now! No more authentication issue.
Thanks to @RobertG1
Very, very preliminary testing on 27.2 (released today): problem seems to be gone, but this is still much to small testing period to say something definite.
It's still there in 27.2, just some time must have passed 🙂
I guess that Merki engineers are more busy with changing dashboard's rainbow logo for the 4th time that solving real bugs in their product...
Just trying to recap here.
The initial issue were clients connecting to the SSID were authenticating with incorrect PSK, even though PSK configuration has been verified mulitiple times.
The issues is seen across MR27.x and MR26.x, but not in MR25.x.
Also disabling 802.11r seems to fix it as well, also on MR27.x and MR26.x.
I was also seeing "Client entered wrong PSK" in the logs, but I'm not seeing it on MR27.2. I'm using WPA2/WPA3 Transition mode, with 802.11w enabled.
Still facing this issue with MR55 / v26.6.
And now discovering it in MR74 / v26.6 environment.
For the moment, the only observed workaround is a downgrade to v25.14 ?
@AJafri Meraki support is refusing to acknowledge the problem. I tried to reach them many times but they are keep asking for wire shark logs and not doing anything else.
yes, I think downgrading to 25.14 is our best option. Zero issues since I have done that
@alicanit is frustrating. I have yet been able to capture the problem on wire shark I am starting to believe it is on the wireless side that you would not see on wire shark. has anyone tried running a airmagnet WiFi analyzer to scan to see if they can pick it up on the wireless side?
I've stopped talking with support about that issue as they clearly are not going to help.
They are still denying problem being known and always ask for wireshark packet captures - which show nothing - as they are difficult to capture as problem is random.
They probably know the problem, but it is difficult to solve - so better not to confirm it exists 😉
Or maybe we all have something wrong with our networks....