AP-STA-POSSIBLE-PSK-MISMATCH - IoT devices cannot connect

Hi Guys. (posted this on Reddit - no response)
Several of my IoT Wifi clients constantly drop off my net:

Sun Oct 27 16:16:53 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:16:54 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:16:55 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:16:56 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:16:59 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: authenticated
Sun Oct 27 16:16:59 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: associated (aid 7)
Sun Oct 27 16:16:59 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:17:00 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:17:01 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Sun Oct 27 16:17:02 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4

This started after downgrading my Openwrt from snapshot to 23.05.4, necessary due to stability issues on my Zyxel G5 (and yes, I should have known better at the start as it was well documented that snapshot would not work).

After downgrading 3 devices (2 shellie’s, one Broadlink) just started having issues with authentication to the 2.4 Ghz IOT Wifi set to WPA / WPA2 PSK (CCMP).
they would try to authenticate, sometimes succeed but then get thrown out again:

Sat Oct 19 07:03:13 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:XX:XX:XX IEEE 802.11: authenticated

Sat Oct 19 07:03:13 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72 :XX:XX:XX IEEE 802.11: associated (aid 2)

Sat Oct 19 07:03:13 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72 :XX:XX:XX

I know the password IS CORRECT.

I managed to get the Shellies to behave by regaining access to them using an old router and then assigning the failing AP as a „Wifi-client Backup“ (to not lose connection again) - funnily it has worked ever since - no idea why…

No luck with the Broadlink though, I can add it to the wifi, but after a day it‘s back to this.

Here are my wireless settings so far:

        option type 'mac80211'
        option path 'platform/soc/c000000.wifi+1'
        option channel '1'
        option band '2g'
        option htmode 'HE20'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'iot'
        option mode 'ap'
        option ssid 'MrRobot'
        option encryption 'psk-mixed'
        option key 'XXXXXXX'

I have tried about every combination of encryption and cypher as well as shorter passwords and no special characters - no luck.

This is driving me absolutely nuts.
Any recommendations would be welcome…

Devices needing WPA1 are in their late teens by now.

1 Like

Psk-mixed will cause issues too.

1 Like

I agree, I hope to be able to get back to WPA2/3

Tried PSK as well

Try wpa2 (only). Do not use wpa1/2 mixed mode or wpa2/3 mixed. Just wpa2 on its own.

2 Likes

Thanks @psherman - looks calm so far, but I have been there before. I will give it a day and report on it.

1 Like

So I am back to square 1.
Since a few days one of the Broadlink devices has disconnected again - nothing was changed on the network/firewall site:

Fri Nov  8 09:22:24 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: authenticated
Fri Nov  8 09:22:24 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: associated (aid 3)
Fri Nov  8 09:22:25 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:25 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:26 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:27 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:30 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: authenticated
Fri Nov  8 09:22:30 2024 daemon.info hostapd: phy1-ap0: STA e8:70:72:3f:13:a4 IEEE 802.11: associated (aid 3)
Fri Nov  8 09:22:31 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:31 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:32 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4
Fri Nov  8 09:22:33 2024 daemon.notice hostapd: phy1-ap0: AP-STA-POSSIBLE-PSK-MISMATCH e8:70:72:3f:13:a4

Here is my wireless config right now, I have actually set up a 2nd SSID just for this to make sure special characters in the key:

config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option ssid 'MrRobot2'
	option encryption 'psk2'
	option key 'xxxxxx'
	option network 'iot'

I wonder if this is in anyway related with DHCP.
Theoretically it could have happened right when the lease expired...
DHCP config:

config dhcp 'iot'
	option interface 'iot'
	option start '100'
	option limit '150'
	option leasetime '480h'

All ideas are welcome...

Good morning, why dont you disable tkip?

I could do that, and have done it before. Sadly it did not solve the issue.
But I have done it again, maybe ...

	option encryption 'psk2+ccmp'

And why your iot sends wrong psk?

well, you know, that is the exact issue.
I doubt it actually does that.
When I reset it and assign again all is fine.
It was also working flawlessly for years (with the rm3 pro to be honest).
Also the RM4 used to show the same problem
...

I don't think that anything other than an actual key mismatch causes that message.

'psk2' is an alias for CCMP only.

So I just upgraded to @asvio ‘s latest fork of openwrt. Already feels way more stable for the Armor G5…
Will keep posting.