5 GHz AP cluster sees high retransmits and video call stalls after enabling airtime-fairness

Environment

Small office: 3 identical enterprise 802.11ac APs (vendor firmware v3.2.1), controller-managed SSID on 5 GHz only, mixed client set (laptops, smartphones). Airtime-fairness and TX power auto enabled via controller at 02:00 during maintenance window.

Symptoms

Users report recurring video-call freezes and high packet retransmits on 5 GHz only. Affected clients show severe uplink latency spikes and media stalls; 2.4 GHz clients unaffected.

Observations

Controller health dashboard shows per-client retransmit rate on 5 GHz increased after airtime-fairness enable. Packet captures near AP show many 802.11 retransmissions and repeated MAC-layer ACK timeouts; goodput at TCP layer falls despite RSSI remaining stable. AP CPU/memory normal. AP firmware release notes mention airtime-fairness changes but no bugfix matched.

Already attempted

Rolled back airtime-fairness on one test AP — retransmits dropped and video call stable on that AP. Temporarily lowered 5 GHz channel width on test AP with no improvement. Rebooted APs and cleared client associations; problem persisted when airtime-fairness re-enabled. Gathered pcap from affected AP and client during a failing call.

Question

What are the most likely causes of the sudden 5 GHz-only retransmit storm after enabling airtime-fairness, how to prove root cause without broad impact, and safe corrective actions to restore call quality across APs?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1d ago• Trouble ID

Most likely causes

AP firmware airtime-fairness implementation bug (scheduling/aggregation causing excessive retransmits on 5 GHz) 78%

Airtime-fairness parameters set too aggressively (per-client TX cap / short TXOPs) causing rapid rate oscillation on clients 60%

Client Wi‑Fi driver incompatibility with airtime-fairness (older devices mis-handle altered TXOPs leading to retransmits) 45%

Summary

Symptoms (5 GHz-only, improvement when airtime-fairness disabled on a test AP) point at an interaction between airtime-fairness scheduling and either client rate selection or a firmware/driver bug on the AP. High MAC retransmits with stable RSSI suggests scheduling or aggregation mishandling rather than RF interference. Possible misconfiguration (too-aggressive fairness thresholds), bugs in AP firmware's airtime implementation, or a client driver reacting poorly to altered TX opportunities are the top suspects. Environmental RF interference is less likely because 2.4 GHz unaffected and RSSI stable.

Suggested Fixes

Diagnostic step 1

Perform a controlled A/B test: keep airtime-fairness disabled on one AP and enabled on another in same RF environment and capture simultaneous pcap on both sides and client to compare 802.11 sequences.

Diagnostic step 2

Collect full AP and controller logs (debug/trace if available) during a failing call and capture client driver logs; preserve timestamps and client MACs.

Diagnostic step 3

On a test AP, revert airtime-fairness but incrementally enable gentler fairness parameters (increase TXOP, raise per-client minimum) to determine threshold that triggers retransmits.