All my ESP-based IoT (WLED, ESPHome, Tasmota - Espressif chips) constantly drop on a UniFi U7-Pro-Max, while everything else is fine. They associate, then loop disconnect/reconnect every ~10–15 s.
The AP’s own log shows why - its Qualcomm driver kicks the client for Excessive Retries, which breaks the WPA2 4-way handshake. Cold-boot capture of a single ESP32-S3 (running a stock ESPHome image - only SSID/password, no app logic):
kernel: ol_peer_sta_kickout_event_handler: Station …e0:80 kicked out reason: Excessive Retries (1)
hostapd: STA …e0:80 IEEE 802.11: disassociated (sta_dc_reason “excessive retries”)
…
hostapd: STA …e0:80 802.11: authenticated → associated (aid 1)
hostapd: WPA: sending 1/4 msg of 4-Way Handshake
hostapd: WPA: sending 1/4 msg of 4-Way Handshake ← resends (no ACK)
hostapd: WPA: received EAPOL-Key frame (2/4 Pairwise)
hostapd: WPA: sending 3/4 msg of 4-Way Handshake
hostapd: WPA: sending 3/4 msg of 4-Way Handshake ← resends (no ACK)
hostapd: WPA: received EAPOL-Key frame (4/4 Pairwise) → EAPOL-4WAY-HS-COMPLETED → got IP
…~13s later…
stahtd: “soft failure” sta_dc_reason: “excessive retries” ← kicked again
It reproduces with a blank ESPHome config, so it’s not WLED/Tasmota/app-specific - it’s the U7 radio ↔ ESP. The kick reason is Excessive Retries, i.e. the AP isn’t getting its frames ACK’d by the ESP - a PHY/MAC/rate-control level
problem, surfacing worst during the 4-way handshake.
Ruled out (all by test):
Power - 3 separate PSUs (500 W rail, USB, another), identical failure.
Steering / min-RSSI / roaming - all off; radio is plain 11ng HT20, WPA2-PSK, PMF disabled.
IPv6 / RA / DNS - VLAN made fully RA-free; no change.
Device firmware - multiple WLED versions + stock ESPHome all do it.
Proof it’s the U7: identical devices are rock-solid on a U6-Pro (WiFi 6) and a UAP-AC-Pro (WiFi 5) - 0 disconnects in 5 min vs ~50 on the U7. So it’s U7-specific, not “WiFi 6/7” generally.
Firmware: downgrading the U7-Pro-Max stabilised my classic-ESP32 devices, but an ESP32-S3 still fails on the downgraded firmware - so the rollback is only a partial workaround.
U7-Pro-Max firmware (current/bad): 8.6.11
Downgraded to: 8.5.21 (helped ESP32, not ESP32-S3)
Since upgrading from 6.7.41, I have less bandwidth on my Wifi 6E Apple devices with 6GHz (500MBit/s instead of 1200MBit/s and I also have occaisonally higher pings (70ms instead of 7ms).
Version 8.6.10 was a not usable at all for me, TX retries around 30% and constant connection dropping.
I am currently running 8.7.3 and it is ok. Still the issues from above, but at least stable for everyday usage.
My learning from it as someone that turned away from Unifi and came back in recent years: software / firmware is still betatest. Disable auto updates. If you have a stable version, stay with it, don’t upgrade. It is not worth it.
just need to roll back to an earlier firmware. this was a known issue and they pushed the firmware out anyway. typical unifi… I will try to get the version #. Once you update you have to powercycle because, I think, some radio firmware is only loaded at boot time. And when you downgrade it does NOT auto reset properly.
Be aware that dropping to the 7.x branch may cause problems as the Network application will require a certain firmware level to operate properly.
Also be aware there have been a few 8.0+ severity score security patches in the latest couple updates, so dropping this far back likely exposes your network to some serious vulnerabilities. One or two of which started actively being exploited already from what I saw on forum posts. It is possible that some of the recent performance and stability problems are due to those security fixes being put in so quickly. The finding of new vulnerabilities and exploiting of them came fast and furiously for around a month there when the new Claude Code security analysis started being used
Or maybe it isnt the firmware itself, but a specific setting you may not even have access to that is being enforced on the Network/UniFi OS side of things.
Some things I would check would be:
use a 2.4GHz only SSID
WPA2-Personal
disabled PMF/Protected Management Frames
turn off BSS transition, UAPSD, Wifi speed limit, proxy ARP, fast roaming
turn ON Force Wifi 4 mode.
Turn on minimum data rate, and leave it set at the lowest of 1mbps (just to ensure this doesnt use some auto mode that sets higher)
turn off BSS transition, UAPSD, Wifi speed limit, proxy ARP, fast roaming
turn ON Force Wifi 4 mode.
All of the above has been set (Last one i needed a console update to show)
Wild update, when i set the channel to 6 all of the issues went away, but this leaves more questions then answers, i cant see anything saying that ESP32 does not support channel 11
I noticed a note that says many wifi 4 IoT devices dont like other channels besides 6. IDK why, it is what it is. Maybe it is something specific to the Qualcomm chipsets inside the U7 access points?
Carefull, Unifi recently had a bug in their Wifi doctor optimization that used these channel 6 only settings. So I would be carfull making conclusions about that ESP32.
The current stable version still has this bug, you have to switch to early access.
To quote from their release notes:
Improved compatibility with legacy WiFi devices when IoT mode is enabled.
and
Fixed IoT and legacy devices failing to connect when IoT (WiFi 4) mode was enabled or changed.
I’m currently on 8.7.4 i believe this is a EA build.
I haven’t tried the “Force WiFi 4 Mode” as this disables the 5ghz on that SSID and i have a few things using that (video doorbell, google speakers, smart Tv’s)
IMHO iot means trash Wifi devices that can’t handle 5GHz, not seperate VLAN for insecure stuff. You can still put your 5GHz devices in the same VLAN but with a different SSID.
Been dealing with similar issues with my U7 pro. Ack not making it back to the server from my laptop causing issues with long running connections. Switching wifi card didn’t fix, seems my pixel sees the same issue. Server resending the same packet 4 times, etc. Unfortunately not seen the same success forcing channel 6 or similar changes.
Something not based on the Qualcomm IPQ53XX chipset that’s giving you trouble. If you want to stay in the Unifi ecosystem add one or more WiFi 5, WiFi 6, or WiFi 6E APs and restrict the IoT SSID to those devices.
unless there is a forum member on here who has it stashed away?
