Diagnosing a WiFi Retry Storm with UniFi API

My Galaxy Tab S7 was playing a movie and suddenly could not finish a speedtest — requests just timed out. Nothing else on the network had changed. Time to dig in.

The Symptom

The Tab (192.168.1.117) was on the 5GHz LunarWolves SSID. Speedtests were timing out completely, not just slow. Other devices on the same network were fine, so this was not an ISP issue or a firewall problem.

Pulling Client Stats from UniFi

The Ubiquiti U6+ reports per-client statistics including TX retry counts. I queried the UniFi Network API directly to see what was happening on the radio:

curl -sk -b /tmp/unifi_cookies.txt \
  https://192.168.1.10:8443/api/s/default/stat/sta \
  | python3 -c "
import sys, json
d = json.load(sys.stdin)
for c in sorted(d['data'], key=lambda x: x.get('tx_retries',0), reverse=True)[:5]:
    print(c.get('mac'), c.get('hostname',?), 'tx_retries:', c.get('tx_retries',0))
"

The output was immediate. The Xbox (MAC 90:6a:eb:e9:e9:61) had 14.6 million TX retries. The PS5 was not far behind at 6.1 million. The Tab S7 had a few thousand — normal.

What Is a TX Retry Storm?

When a WiFi client has a borderline signal or is transferring a large amount of data at high rates, the AP may need to retransmit frames repeatedly. Each retry consumes radio airtime. With enough retries, the AP spends most of its time re-sending data to one or two clients and cannot respond to anyone else fast enough — including the Tab trying to complete a speedtest.

The Xbox was in the middle of a large game download. Console downloads can sustain 100+ Mbps for minutes at a time, and if the signal is not ideal, retry counts pile up fast.

The 5GHz channel utilization was sitting at 83%. That is the number that explains everything. When utilization is that high, new connections stall and latency spikes for every other device on the band.

Short-Term Fix: Kick the Offenders

With the download complete (or close enough), I kicked the Xbox and PS5 from the network via the UniFi API:

for MAC in "90:6a:eb:e9:e9:61" "a4:c3:f0:xx:xx:xx"; do
  curl -sk -b /tmp/unifi_cookies.txt -X POST \
    https://192.168.1.10:8443/api/s/default/cmd/stamgr \
    -H "Content-Type: application/json" \
    -d "{\"cmd\":\"kick-sta\",\"mac\":\"$MAC\"}"
done

Channel utilization dropped from 83% to 4% within seconds. The Tab S7 speedtest completed normally.

Root Cause: 5GHz Gaming Consoles With No LAN Requirement

The Xbox and PS5 belong to my son. He does not host LAN parties. Neither device needs access to the local fleet or home devices — only internet. Keeping them on the main 5GHz LunarWolves SSID is the wrong tool for the job.

Permanent Fix: VLAN30 + 2.4GHz Only

The network already had a Home123 SSID on VLAN30 (internet-only, LAN blocked). I made two changes via the UniFi API:

1. Restrict Home123 to 2.4GHz only

WLAN_ID="69fb3d60001ac6695837b4b3"
curl -sk -b /tmp/unifi_cookies.txt -X PUT \
  "https://192.168.1.10:8443/api/s/default/rest/wlanconf/${WLAN_ID}" \
  -H "Content-Type: application/json" \
  -d '{"wlan_band":"2g","wlan_bands":["2g"]}'

2.4GHz has lower throughput ceiling than 5GHz but is far more tolerant of distance and obstacles. Game downloads will be slower, but the 5GHz band stays clear for devices that need it.

2. Move the Xbox to Home123

Jacob connected the Xbox to Home123 manually. It picked up a 192.168.30.x address on VLAN30. The Ring doorbell migrated at the same time — also internet-only, also no reason to be on the main LAN.

Result

5GHz channel utilization: consistently low
Tab S7: full speed restored
Xbox and PS5: still get internet, no LAN access needed
LunarWolves 5GHz: reserved for devices that actually need it

What Is Next

The PS5 is still on VLAN1. It will follow the Xbox to Home123. Long-term I will wire both consoles — a direct ethernet connection eliminates retry storms entirely, and a wired console download does not consume any radio airtime at all.