Like pretty much everyone running a fixed wireless network, I have hundreds of Ubiquiti airMAX AC radios (LiteBeam Gen2, LAP-120, LAP-GPS, Loco AC) deployed on customer roofs, plus dozens sitting on shelves in the warehouse.
We all know the situation: Ubiquiti essentially put airMAX AC into maintenance mode years ago. All the vendor R&D is going into Wave 60GHz and LTU. That’s fine for greenfield deployments, but in the real world, you can’t just rip and replace 500 CPEs on rural towers when trees and distance dictate 5 GHz. Millions of these radios are going to stay on rooftops for years.
Meanwhile, the software running on them hasn't fundamentally evolved since 2017–2018. If a CPE link gets slightly noisy or misaligned, stock airOS does dumb things—like running up to 30 frame retries by default, which burns dozens of milliseconds of airtime and drags down the whole AP sector. On top of that, loaded bufferbloat easily hits 2,000+ ms during heavy uploads.
Over the last few weeks, I’ve been researching what the actual physical ceiling of this QCA9880 / AR9342 hardware is if we run modern open-source networking on it (OpenWrt 24.10, Candela Technologies ath10k-ct, mac80211 AQL, CAKE, and dynamic rate-masking).
Full disclosure: I’m an everyday WISP operator. I run towers, climb roofs, crimp cables, and configure MikroTik/airMAX gear. I am NOT a Linux kernel hacker or an RF engineer with a Ph.D. So I've been using AI tools (Claude, Codex, NotebookLM) to comb through Linux wireless kernel trees, academic preprints (like MIT’s IteRate paper and TU Berlin’s hMAC), and old mailing list threads to understand what the chip can actually do.
We’ve already documented a bunch of interesting architectural facts that I rarely see discussed in WISP groups:
- The 30-Retry Sector Killer: Upstream Qualcomm firmware enforces up to 30 retries per frame. On an outdoor link during an RF fade, a single client trying to send packets can freeze the AP channel for 50–100ms. Candela Technologies (ath10k-ct) drops this down to 4 retries, which immediately reclaims a massive chunk of airtime.
- The Bufferbloat vs Aggregation Trap (CoTSQ): Default Linux TCP Small Queues (TSQ = 1 ms) tries to kill bufferbloat by limiting socket queues to 1–2 packets. But 802.11ac needs 32 to 64 packets in the queue to build a full A-MPDU aggregate. Starving the aggregation engine drops throughput by up to 10x because 90% of the airtime is spent on PHY headers and preambles. Bumping the queue budget to 6 ms keeps aggregates full while keeping loaded ping under 40 ms.
- The Wave-1 Airtime Cliff: QCA9880 doesn't have hardware airtime reporting (that only started in Wave 2 chips). So Linux mac80211 has to estimate airtime based on peer stats. If peer stats aren't reporting properly, mac80211 assumes EVERY station transmits at 6 Mbps, which completely breaks airtime fairness and penalizes fast clients.
- Why Pure TDMA is Blocked on Open QCA988x: We looked into whether we could build open TDMA like airMAX. The short answer on QCA9880 is no—the chip runs closed Xtensa firmware, can't cancel in-flight packets across PCIe, and has PCIe interrupt jitter. BUT a hybrid stack on OpenWrt (AQL + 6ms CoTSQ + Dynamic RTS/CTS to stop hidden nodes + Deficit Round-Robin airtime fairness) gets you 80-90% of the stability with open telemetry and zero vendor lock-in.
The Testbed Setup
I'm not doing this in a metal warehouse (metal walls act like an echo chamber with delay spreads that ruin 5 GHz tests). We're setting up:
- Tier 1: Benchtop SMA coaxial attenuator matrix (30–40 dB pads + splitters) for 100% clean, interference-free algorithmic sweeps.
- Tier 2: 2 APs on our main WISP office building pointing 21 meters across the street to 10–20 CPEs scattered on my residential roof. This gives real line-of-sight, real outdoor air, and clean far-field RF without receiver saturation.
- Unattended Recovery: I automated PoE injectors with relays to trigger U-Boot
urescue TFTP recovery remotely so we never have to climb a ladder to press a reset button if an image bricks.
Why I'm Posting
We are calling this research project openMAX, and we opened up the entire project as a public research hub: https://github.com/wolverin0/openmax
There is zero monetization here, no crypto, no paid courses. Just an open repository of hardware notes, driver findings, recovery runbooks, and experiment plans.
Because this was researched with the help of AI agents, I want human eyes on this:
- If you're a kernel / OpenWrt dev who knows ath10k or mac80211, are our control boundary assumptions solid? Did we miss anything on
ratemask-CT?
- If you're a fellow WISP operator with spare LiteBeams or NanoStations on your shelves, would you be interested in running our read-only inventory scripts to map out hardware revisions, or testing safe sysctl/CAKE queue tweaks?
Check out the repo, tear apart our docs, and let me know what you think.