Networking: wlan0: WPA: 4-way handshake failed - pre-shared key may be incorrect / WRONG_KEY
The Wi-Fi association started but key negotiation failed, almost always a wrong password.
WPA: 4-way handshake failed - pre-shared key may be incorrectCTRL-EVENT-SSID-TEMP-DISABLED reason=WRONG_KEYIncorrect password Wi-FiCan't connect to this network Wi-Fi4-Way Handshake timeout Meaning
Re-enter the passphrase (watch case and look-alike characters), forget and rejoin the network, and make sure the access point security mode (WPA2/WPA3 transition, WPA3-only) is supported by the client. Weak signal can also time out the handshake.
Common causes
- Wrong Wi-Fi password
- WPA3-only or mixed mode unsupported by an old adapter
- Saved profile with the old password
- Very weak signal during the handshake
- MAC filtering or too many clients on the access point
⚡ Quick fix
- Forget the network and join again with the correct password
- Test with WPA2/WPA3 transition mode
- Move closer to confirm it is not a signal problem
Detailed fix by platform
Linux
journalctl -u wpa_supplicant -n 50 | grep -iE "handshake|WRONG_KEY|PSK"
How to diagnose
- Password — Correct, case-sensitive?
- Security mode — Supported?
- Signal — Strong enough?
🔧 Still not fixed?
Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:
Similar errors
- arp -a shows (incomplete) Networking: `arp -n` shows (incomplete) / Destination Host Unreachable — no ARP reply from the next hop
- Cannot assign requested address (EADDRNOTAVAIL) Networking: connect: Cannot assign requested address — ephemeral port range exhausted by TIME_WAIT connections
- captive portal Browser: This network requires you to sign in — captive portal (hotel, airport, café Wi-Fi) blocking HTTPS sites
Most viewed in Networking
- Native VLAN mismatch / wrong VLAN, no connectivity Networking: %CDP-4-NATIVE_VLAN_MISMATCH / device on the wrong VLAN can't reach the gateway
- Rogue DHCP server hands out wrong gateway/DNS Networking: Clients receive the wrong default gateway or DNS server — a rogue DHCP server (often a home router) answers first
- Idle connections silently dropped by firewall/NAT Networking: Connection works, then fails after being idle — firewall/NAT idle timeout dropped the TCP session (use keepalive)
Other ways to find it
Where this error sits
Origin: Network. Errors that are often confused with or caused by this one (click to open):
🧠 Still stuck? Analyze your error
Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.
💬 What worked for others
No tips yet — did something else fix this for you?
Share what worked for you
Tips are checked by an editor before they appear. Links are removed.
Report a correction or suggest an improvement
Last updated 5 Nov 2026