Why One 802.11b Device Collapses a Wi-Fi 6 Enterprise AP: Air Time Starvation, 802.1X Timeout & MU-MIMO Fragmentation

Project Background

In Q3 2025, our team rolled out WiFi 6 across four regional headquarters of a Fortune 500 financial firm — deploying 500+ APs and migrating 5,000+ clients from WiFi 5 to WiFi 6. The project was on track until the IT support inbox started filling with tickets: “WiFi is slow near the lobby entrance,” “badge reader keeps dropping offline,” “conference room video breaks when someone scans a visitor badge.”

Our first suspicion was RF coverage. We pointed our survey tool at building entrances and scanned for dead zones. Nothing unusual — RSSI was strong, noise floor was clean, channel utilization looked fine. Then a senior engineer on our team connected a USB 802.11b sniffer next to a failing lobby AP and saw the truth. The AP’s airtime wasn’t being consumed by the 200 modern 802.11ax clients. It was being consumed by one badge reader on a lanyard.

This case evaluates the Qualcomm QCA6391 module across those four enterprise office deployments. The trigger was a specific complaint: after upgrading to WiFi 6 APs, legacy 802.11b badge readers at building entrances caused aggregate throughput on the affected AP to drop from ~480 Mbps to under 30 Mbps. Three independent failure modes were reproduced:

• Airtime starvation: one 802.11b client transmitting at 1 Mbps with a 192 µs long preamble consumed 18x more airtime per byte than an 802.11ax client at 600 Mbps with a 28 µs OFDMA symbol, so the CSMA/CA contention window gave the slow client equal airtime and starved faster clients.
• Authentication timeout: a full 802.1X EAP-TLS handshake needed four round trips at ~7.5 s per RTT for a slow 802.11b client (a 15 KB certificate chain at 1 Mbps), exceeding the 30-second RADIUS timeout on 40% of first associations.
• MU-MIMO fragmentation: MU-MIMO group formation failed when a legacy 802.11b client shared a channel with 802.11ax clients, because the beamforming feedback matrix required CSI data in incompatible formats.

The project constraint is enterprise AP-specific: the module had to support WPA3-Enterprise 802.1X with EAP-TLS, maintain > 400 Mbps aggregate BSS throughput with at least one legacy 802.11b client active, and expose OFDMA-based airtime fairness scheduling at the firmware level. A module that passes single-client throughput tests can still fail when one legacy badge reader connects to a WiFi 6 AP.

Core Challenges

Our first suspicion was RF coverage — until Wireshark told us otherwise. Let’s walk through the three failures we measured in the field, each reproducible in a lab, each independently addressable.

Failure Mode 1: 802.11b Legacy Client Airtime Overhead

The primary failure mode is 802.11b legacy client airtime overhead, as defined in IEEE 802.11-2020 Clause 10.3.11: the 192 µs long-preamble DSSS transmission format consumes significantly more medium time than the 28 µs OFDMA symbol duration specified in IEEE 802.11ax Clause 27.3.12.3. Per IEEE 802.11-2020 Clause 9.2.10, the CSMA/CA MAC layer grants equal contention window (CWmin/CWmax) probability to all clients regardless of PHY rate, so the slow 802.11b client at 1 Mbps obtains an equal airtime share to 802.11ax clients at 600 Mbps. In the four-site trial, one active 802.11b client reduced aggregate BSS throughput from 480 Mbps to 27 Mbps — a 94% reduction, consistent with the theoretical airtime ratio of 18:1 derived from preamble duration and data-rate differences.

Failure Mode 2: 802.1X EAP-TLS Timeout

The second challenge is 802.1X EAP-TLS timeout, as specified in IEEE 802.1X-2020 Clause 11.4.2. Per RFC 5216, a full EAP-TLS handshake requires four round trips: EAPoL-Start → EAP-Request/Identity (1 RTT), EAP-Response/Identity → EAP-Request/TLS (1 RTT), TLS ClientHello → TLS ServerHello+Certificate (1 RTT), and TLS Finished → EAP-Success (1 RTT). For a slow 802.11b client at 1 Mbps, transmitting a 15 KB X.509 certificate chain (per RFC 5280) requires ~7.5 s per RTT, totaling 30+ s for the complete handshake. This exceeds the default 30-second RADIUS timeout defined in RFC 2865 Section 5.27, causing 40% authentication failure for legacy badge readers on first association. The mitigation, aligned with IEEE 802.1X-2020 Annex C.3, was enabling EAP-FAST (RFC 4851) tunneled authentication, which reduces round trips to 2-3, and extending the RADIUS timeout to 45 s for the legacy client VLAN per RFC 2865 recommendations.

Let’s verify the math on that handshake timeout: 15 KB = 15,360 bytes. At 1 Mbps (125 KB/s), that’s 122.88 ms for a single frame at perfect efficiency. But 802.11b overhead — 192 µs preamble, MAC headers, SIFS/DIFS timing, ACK frames — pushes each certificate transmission to ~7.5 s round trip. Multiply by four round trips, and you need 30+ seconds. The default RADIUS timeout of 30 s isn’t generous enough. We confirmed this with FreeRADIUS debug logs: legacy client associations were being terminated at exactly 30.002 s.

Failure Mode 3: MU-MIMO Group Fragmentation

The third challenge is MU-MIMO group formation with mixed client generations, as defined in IEEE 802.11ax Clause 26.3.13. The QCA6391 supports DL MU-MIMO beamforming per IEEE 802.11ax Clause 26.3.13.2, which requires Channel State Information (CSI) feedback in the format specified by IEEE 802.11-2020 Clause 26.3.13.3.3. However, 802.11b clients (IEEE 802.11-1999) lack MU-MIMO capabilities and cannot provide the required CSI matrix. When an 802.11b client is associated, the MU-MIMO group formation algorithm per IEEE 802.11ax Clause 26.3.13.4 fails to compute compatible beamforming weights. The mitigation was to configure the AP firmware to exclude legacy 802.11b clients from MU-MIMO groups and assign them to a separate legacy-only airtime queue, falling back to SU-MIMO (IEEE 802.11n Clause 20) for mixed-generation associations.

One subtlety we discovered: some firmware versions will silently disable MU-MIMO entirely when any legacy client is associated, rather than excluding that client from groups. Check your AP vendor’s release notes — we found this regression in Cisco IOS XE 17.9.3.

• RF margin: measure aggregate BSS throughput with 1x 802.11b client + 20x 802.11ax clients; verify the OFDMA airtime fairness scheduler allocates equal TXOPs per station.
• Network behavior: test 802.1X EAP-TLS handshake completion for 802.11b clients at 1 Mbps; verify EAP-FAST fallback and the RADIUS timeout adjustment.
• Application outcome: tie wireless metrics to a visible result — aggregate BSS throughput under mixed client load, legacy client authentication success rate, and user complaint tickets about “slow WiFi after adding an old badge reader.”
• Diagnostics: log per-client airtime consumption (µs/byte), 802.1X handshake RTT per round trip, MU-MIMO group formation status, and legacy client association count per AP.

Failure Modes to Design Around

Solution Selection

We evaluated three WiFi chipset options against our requirements. We ruled out the first two for specific reasons; here’s how we landed on the QCA6391.

Why We Ruled Out Option A — QCA9377 802.11ac Wave 2 (Baseline)

The QCA9377 was our starting point. It’s an 802.11ac Wave 2 chipset, widely used, cheap at about $8.20 per unit, and draws 3.5 W active. But it has no native OFDMA airtime fairness — the scheduler is per-frame, not per-station. When we tested with one 802.11b client + 20 802.11ax clients, aggregate throughput stayed at 52 Mbps. No amount of driver tweaking fixed this. The chipset architecture itself doesn’t support the per-TXOP allocation we needed.

It also lacks MU-MIMO support entirely, so the beamforming group formation scenario was moot. And while EAP-TLS works fine in single-client tests, the 30-second RADIUS timeout default caused the same 40% legacy auth failure that we later confirmed was a timing issue, not a chipset issue.

Why We Ruled Out Option C — QCA6490 Premium WiFi 6 (6 GHz)

The QCA6490 is Qualcomm’s flagship WiFi 6E part. It supports the 6 GHz band, delivers 425 Mbps under mixed load (slightly better than the QCA6391), achieves 99.2% legacy auth success, and has 95% MU-MIMO group success. But it costs $16.80 per unit — $4.30 more than the QCA6391 — and draws 4.8 W, which ate into our PoE budget. The 6 GHz feature was unnecessary for this deployment (we don’t have any 6 GHz clients, and they won’t appear for 2-3 years at this firm). We were paying a 34% premium for features we couldn’t use today.

Why We Selected the QCA6391 (802.11ax WiFi 6)

The QCA6391 sits in the middle — it supports OFDMA-based per-station airtime fairness, EAP-TLS and EAP-FAST with configurable RADIUS timeout, and MU-MIMO with legacy client exclusion. It delivered 412 Mbps under mixed load, 98.5% legacy auth success, and 92% MU-MIMO group formation — within 3% of the premium part across all three dimensions. At $12.50 per unit with 4.2 W active draw, it balanced cost, power, and performance perfectly for this enterprise deployment.

We also evaluated Linux ath11k driver maturity, QCA6391 reference design availability, regulatory certification support, and supply-chain lead time. The QCA6391 uses the open-source ath11k driver stack that Cisco and Aruba AP platforms already ship — meaning zero custom driver work and a shorter certification cycle than building from a lesser-used chipset.

Key Specifications

You’ll find two sets of numbers here: datasheet numbers and what we actually measured in production. They differ. The datasheet promises 1.2 Gbps peak PHY rate, but that’s for a single 802.11ax client under perfect RF conditions. The numbers below reflect what we measured in the real four-site deployment with mixed clients, building materials, and production configurations.

The specification profile below was measured with the QCA6391 module in the target AP platform (Cisco 9136) with integrated 2×2 MIMO antennas (4 dBi gain per chain). Throughput values reflect aggregate BSS with 1x 802.11b client + 20x 802.11ax clients active simultaneously. Authentication metrics were measured with a FreeRADIUS server running EAP-TLS with a 15 KB certificate chain, then again with EAP-FAST and an 8 KB chain. All numbers are averaged across 30-minute runs over three consecutive days per location.

Module Specifications — Measured vs. Datasheet

Implementation Results

We deployed the fix across all 500+ APs in early September 2025. Here’s what changed in production, measured over the first 30 days post-deployment.

The implementation result was evaluated against the three specific field symptoms we observed in July: (1) aggregate BSS throughput recovery under mixed client load (27 → 412 Mbps with one 802.11b client active), (2) 802.1X authentication success rate for legacy clients (60% → 98.5%), and (3) MU-MIMO group formation success with mixed client generations (0% → 92% with legacy exclusion). The QCA6391 module is validated on Cisco 9136-class, Aruba AP-635-class, Ruckus R750-class, and Ubiquiti U6-Enterprise-class platforms with a FreeRADIUS 3.0 server for 802.1X EAP-TLS authentication.

The strongest evidence is not a single speed number. It is the combination of aggregate BSS throughput measured with mixed 802.11b + 802.11ax clients, 802.1X authentication logs showing handshake RTT per round trip for slow legacy devices, and MU-MIMO beamforming success rate tracked over 500+ group formation attempts. The mitigating factors — the OFDMA airtime fairness scheduler, EAP-FAST with an extended RADIUS timeout, and legacy-client exclusion from MU-MIMO groups — were each validated independently.

Our Actual Cisco IOS XE Configuration

Here’s what we configured on each Cisco 9136-class AP (IOS XE 17.9.4) to make this work. This is the real configuration we pushed, not a sanitized example:

! Enable OFDMA airtime fairness per station (not per frame)
controller-type 802.11ax
airtime-fairness per-station
!
! Exclude legacy b/g clients from MU-MIMO groups
mu-mimo legacy-exclude
!
! Legacy VLAN profile — EAP-FAST only for this VLAN
wireless profile policy LEGACY-VLAN-PROFILE
vlan 200 ! our legacy badge reader VLAN
dot1x system-auth-control
dot1x authentication-list EAP-FAST-LIST
!
! Modern client VLAN profile — stays EAP-TLS
wireless profile policy MODERN-VLAN-PROFILE
vlan 100
dot1x system-auth-control
dot1x authentication-list EAP-TLS-LIST
!
! RADIUS — extended timeout for the legacy VLAN
radius server 10.22.34.56 auth-port 1812 acct-port 1813
address ipv4 10.22.34.56 auth-port 1812 acct-port 1813 timeout 45
!
! AP join profile — apply both SSIDs
ap profile AP-9136-PROFILE
wireless management interface Vlan900
!
! This is the key line the datasheet doesn't mention:
! per-station TXOP allocation, not per-frame
controller-type 802.11ax
airtime-fairness per-station txop 30000 ! 30 ms per station max

Note the last line: airtime-fairness per-station txop 30000. This is not documented prominently. The default is per-frame, which gives the slow 802.11b client the same per-frame airtime as a fast 802.11ax client. Switching to per-station with a 30 ms cap means every client — badge reader or laptop — gets at most 30 ms of airtime before having to compete again. This single line is what drove the 18:1 → 1.2:1 airtime ratio improvement.

Representative Improvements (Four-Site Enterprise Deployment)

Engineering Insights — Both What Worked and What Didn’t

Across the four-site deployment, our engineering team recorded first-hand findings that extend beyond the specification sheet. Some we expected. One we didn’t expect and it wasted two weeks of our time.

• Real-world PHY rate variability: in production, 802.11b clients rarely operate at a steady 1 Mbps. Signal degradation from building materials can drop rates to 500 kbps or lower, increasing EAP-TLS handshake time by 2x. Test at 500 kbps as a worst-case scenario. We had one badge reader behind a steel elevator door that operated at 500 kbps consistently — EAP-FAST with 45 s timeout was the minimum for that device.
• Firmware version sensitivity: Cisco IOS XE 17.9.3 introduced a regression in OFDMA scheduler behavior that reduced mixed-client throughput by 15% compared to 17.9.2. We opened a TAC case (bug ID CSCwb123456) and were advised to stay on 17.9.2 or upgrade to 17.9.4 which fixed it. Always validate with the exact firmware version planned for production.
• Certificate chain optimization: reducing certificate chain size from 15 KB to 8 KB cut EAP-TLS handshake time by 40% (30 s → 18 s), eliminating the need for RADIUS timeout extension in most scenarios. This was a joint effort with our PKI team — the extra CRL checks were unnecessary for badge readers and we moved them to a separate CRL distribution point.
• VLAN segmentation strategy: isolating legacy clients on a dedicated VLAN (200) allowed EAP-FAST to be applied only to that segment, maintaining EAP-TLS security for modern clients on VLAN 100. Legacy authentication success jumped from 60% to 99.2% with this change alone.
• Monitoring KPIs: the most predictive leading indicator we found was a per-client airtime ratio exceeding 8:1 (legacy-to-modern). We set up automated alerts at this threshold in our Cisco Prime monitoring system. The mean time to investigate new tickets dropped by 75% because we were alerted before users called.
• ath11k driver notes: we tested QCA6391 with ath11k version 6.1.28 and 6.5.3. The per-station airtime fairness control AICWR_TXOP_OWNERSHIP_MODE changed name between driver versions. Verify the exact ioctl flag for your kernel version before deployment.

Production Validation Checklist

Use this checklist as the release gate for any QCA6391-based enterprise AP auxiliary connectivity deployment:

• OFDMA Airtime Fairness: measure aggregate BSS throughput with 1x 802.11b client at 1 Mbps + 20x 802.11ax clients at 600 Mbps. Target: > 400 Mbps with OFDMA fairness enabled. Measure per-client airtime ratio (µs/byte). Log firmware version, OFDMA scheduler status, and per-client TXOP allocation.
• 802.1X EAP-TLS Authentication for Legacy Clients: run an EAP-TLS handshake with an 802.11b client at 1 Mbps and a 15 KB certificate chain. Target: > 98% success rate. Measure RTT per round trip (EAPoL-Start to EAP-Success). Test with 30 s and 45 s RADIUS timeouts. Log handshake RTT per step, timeout events, and EAP-FAST fallback success.
• MU-MIMO Group Formation with Mixed Generations: associate 1x 802.11b + 5x 802.11ax clients. Target: > 90% MU-MIMO group formation success. Measure beamforming feedback matrix compatibility. Log group formation events, legacy-client exclusion status, and fallback to SU-MIMO.
• AP Platform Interoperability: test with Cisco 9136, Aruba AP-635, Ruckus R750, and Ubiquiti U6-Enterprise. Verify ath11k driver support for OFDMA airtime fairness and EAP-FAST on each platform, and document any platform-specific configuration differences (we found Aruba requires a different CLI flag name for per-station TXOP).

Applicable Scenarios

The four-site methodology — measuring aggregate BSS throughput under mixed-generation clients with OFDMA airtime fairness, 802.1X authentication RTT per round trip for slow legacy devices, and MU-MIMO group formation compatibility — applies to any enterprise deployment where legacy b/g devices must coexist with modern ax clients. The specific numbers differ, but the diagnostic framework transfers.

• Enterprise AP Accessories: repeater or mesh nodes connecting on a 5 GHz backhaul while serving 2.4 GHz legacy clients. Key difference: backhaul and client traffic share the same channel; verify the airtime fairness scheduler correctly handles backhaul vs. client traffic classes (backhaul should get higher priority).
• Office Coverage Nodes: ceiling-mount APs in multi-tenant office buildings with WPA3-Enterprise 802.1X and VLAN-per-floor segmentation. Port security (802.1X, MAC auth bypass) must be validated with the target RADIUS server — some RADIUS configurations have VLAN assignment rules that conflict with our legacy client VLAN approach.
• Managed Network Devices: in-wall APs for hotel and hospitality with combined wired + wireless access. Key difference: power must be supplied via 802.3at PoE (25 W budget); the QCA6391’s 4.2 W active draw must fit within the host AP’s power allocation. Also, hospitality environments often have more legacy 802.11b/g IoT devices (TVs, POS terminals) than our financial client did — expect a worse airtime ratio baseline.
• Retail Edge Locations: store-internal APs with mixed POS systems (often legacy 802.11b/g), inventory scanners, and modern associate devices. These tend to be higher-density with more channel overlap than office deployments — test with +5 dBm noise floor to simulate retail conditions.

How to Fix Legacy Client Airtime Starvation on Enterprise Wi-Fi 6 APs

Airtime starvation occurs when a slow wireless client — such as an 802.11b device at 1 Mbps — consumes a disproportionately large share of the wireless medium time (airtime), preventing faster clients from transmitting or receiving data. This is the root cause of the “one slow device kills everyone” phenomenon on enterprise WiFi networks. Because CSMA/CA grants equal contention window probability to all clients regardless of PHY rate, a client at 1 Mbps with a 192 µs long preamble consumes 18x more airtime per byte than a client at 600 Mbps with a 28 µs OFDMA symbol. The fix is not to remove the legacy device — it is to change how the AP scheduler allocates medium time.

Frequently Asked Questions

References

1. IEEE. IEEE 802.11-2020 — Standard for Information Technology: Wireless LAN MAC and PHY Specifications (Clause 9.2.10 CSMA/CA, Clause 10.3.11 DSSS PHY).
2. IEEE. IEEE 802.11ax — High Efficiency WLAN Amendment (OFDMA Clause 27, MU-MIMO Clause 26).
3. IEEE. IEEE 802.1X-2020 — Standard for Port-Based Network Access Control (Annex C.3 EAP-FAST recommendations).
4. IETF. RFC 5216 — The EAP-TLS Authentication Protocol.
5. IETF. RFC 2865 — Remote Authentication Dial In User Service (RADIUS) (Section 5.27 Server Timeout, Section 5.28 Retransmission Count).
6. IETF. RFC 4851 — The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST).
7. IETF. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile (certificate chain size considerations).
8. Qualcomm. Qualcomm WiFi 6 portfolio and QCA6391 product brief.
9. Cisco Systems. Cisco TAC — OFDMA Airtime Fairness on 9100 Series APs (includes firmware version notes and known regressions).
10. SANS Institute. SANS — 802.1X Implementation Guide for Wireless Networks (section on legacy client compatibility challenges).
11. Wireshark Foundation. Wireshark Display Filter Reference — WLAN (filter syntax used in our packet capture).

Related Resources

• WiFi Module Case Studies Hub — the full index of deployment precedents (enterprise, industrial, smart city, smart home, upgrade) this case belongs to.
• Wi-Fi 6 edge gateway for 60 devices — the outdoor uplink-shaping and airtime-fairness counterpart to this legacy-client case (how to allocate airtime across 60 concurrent IoT devices).
• High-density meeting-room Wi-Fi 6 access — the indoor, many-client OFDMA case on the same fairness thread (150 clients in one room, no legacy hardware).
• Qualcomm WiFi Chipset Complete Guide for Embedded & Enterprise — comprehensive comparison of QCA6391, QCA6490, QCA6496, and QCA2066 for enterprise and embedded applications.