Intermittent client auth failures on AP7; appears to clear after ~5-minute quiet period
Environment
-
Router: Firewalla Purple
-
AP: Firewalla AP7 (1 wall unit)
-
Topology: Purple → AP7 (bridge/AP mode)
-
SSIDs: two separate networks (2.4 GHz and 5 GHz), different SSID names and passwords
-
Security: WPA2/WPA3
-
Channel settings: [Auto]; DFS: [On]
Issue
-
Random previously working clients will suddenly fail to (re)connect and the device OS prompts for the Wi-Fi password. Usually just 1 random device at 1 time will randomly have this issue within 24-48 hours.
-
Entering the correct, previously saved password on that device does not succeed.
-
If I power the device off or turn its Wi-Fi off for ~5 minutes (no connection attempts during that time), it immediately reconnects with the same saved credentials.
-
Other clients remain connected and unaffected while one client is “stuck.”
-
This affects various device types (phones/tablets/IoT/etc.), not a single model.
Impact
-
Device gets stuck in a disconnected WiFi loop state: the device auto-retries rapidly, which appears to keep it blocked; only a 5-minute quiet period clears it.
-
Happens intermittently; no consistent trigger I can see.
What I’ve tried
-
Re-entering the SSID password → still fails until the ~5-minute no-attempt window passes.
-
Power-cycling the device or disabling Wi-Fi for ~5 minutes → connects immediately afterward.
Hypothesis
-
AP7 may be applying some sort of temporary per-client block/blacklist (≈300 s) after certain auth/assoc failure patterns.
-
Alternatively, a WPA2/WPA3 state mismatch could be causing the OS to reprompt as if the password were wrong until state clears.
Request
-
Please confirm whether AP7 enforces a client “temporary block” after repeated auth/assoc failures and the default duration.
-
Guidance to disable or tune this behavior (or logs to confirm it).
-
Recommended settings for a single-AP setup to avoid false password prompts.
-
Any known issues on current AP7 firmware that match these symptoms.
Repro (as observed)
-
Client has been connected and stable.
-
At some later time, client drops and prompts for password.
-
Immediate retries (manual or auto) fail repeatedly.
-
Leave client powered off or Wi-Fi disabled for ≥5 minutes (no attempts).
-
Re-enable Wi-Fi → connects instantly with the same saved credentials.
-
Can you double check and make sure there is no other wifi / AP (like your previous setup) is advertising the same SSID? After checking this, try turn DFS off and see if you still have issues, if you do, let me know, I can create a case
(Firewalla does NOT temporarily block anything)
-
I turned off DFS on the 5 GHz radio, but the issue still occurs.
I figured out now how reproduce the issue reliably: if I disconnect and reconnect a client to Wi-Fi about five times in quick succession, the client gets “locked out” and is prompted for the Wi-Fi password. Even with the correct password, it won’t reconnect until the client stays completely offline (powered down or Wi-Fi off) for ~5 minutes. After that quiet period, it reconnects immediately with the same saved credentials.
This happens on both 2.4 GHz and 5 GHz, across old and brand-new devices (phones, cameras, IoT plugs/switches, etc.). I’ve used several other Wi-Fi systems at this location over the years and never saw this behavior with these same devices.
The workaround (forcing a 5-minute offline period) is manageable for phones but not practical for unattended smart devices. Any guidance on settings or other steps to avoid triggering this would be helpful.
Please sign in to leave a comment.
Comments
5 comments