I replaced a Netgear R7000 running DD-WRT (v3.0-r62365 std) with a Netgear R7800 running OpenWrt 25.12.5. Both act strictly as Layer 2 Wireless Access Points (no routing, no NAT, WAN port removed from br-lan, 802.1Q VLAN trunking back to a managed switch). Upstream routing is handled by an OPNsense firewall. The R7000 consistently hits 600+ Mbps on Speedtest. Initially, the R7800 was stuck at 250 Mbps. After swapping to non-CT firmware, enabling packet steering, and setting hardware flow offloading, speeds improved significantly to 400–450 Mbps. However, a ~25% performance gap remains. PHY rates, wired bridging, and VLAN tagging check out cleanly—looking for insights on squeezing out that final ~150 Mbps.
Environment & Setup
Upstream Routing: OPNsense firewall handling WireGuard, Zenarmor DPI, and DNSCrypt-Proxy.
Switching & VLANs: Netgear GS308Ev4 managed switch passing 802.1Q VLAN tags (LAN, NoVPN, IOT, Guest) to dedicated SSIDs across all APs.
R7800 / OpenWrt 25.12.5: 5GHz (80 MHz) → 400–450 Mbps consistently on the same test.
Back-to-back tests on a Pixel 7 running the Ookla Speedtest app (same server, <1 minute apart): 607 Mbps (R7000) vs 442 Mbps (R7800). Repeated over multiple days at different times with similar results.
What I've Already Ruled Out
PHY Rate / Negotiation: Both APs cleanly negotiate 866.7 Mbit/s (VHT80, MCS9, NSS2) per iwinfo / Associated Stations. The client gets the maximum 2x2 AC rate.
Bridge / Switch Overhead: Wired iperf3 straight into the R7800's br-lan hit 887 Mbit/s single-stream. Software bridging and 802.1Q VLAN tagging on the R7800 are not the bottleneck.
Packet Loss / RF Noise: Wireless iperf3 (LAN-only, bypassing WAN/VPN completely) caps out at ~350 Mbit/s with zero retransmits. Clean, stable, just throughput-capped.
VPN / Firewall: Tested both a VPN-routed SSID and a direct-WAN SSID on the same AP—no meaningful difference.
Specific Fixes Attempted on OpenWrt 25.12.5 (Pushed 250 Mbps → 450 Mbps)
Driver Stack Swap: Switched from ath10k-firmware-qca9984-ct to mainline non-CT packages: ath10k-board-qca9984 (20260221-r1), ath10k-firmware-qca9984 (20260221-r1), and kmod-ath10k (6.12.94.6.18.26-r1).
CPU & Offloading: Enabled Packet Steering (all CPUs) under Global Network Options and set Firewall Offloading to Hardware flow offloading.
802.11 Timers: Locked DTIM Interval to 3 and Key Renewal (GTK) to 7200s across all APs.
Bridge Cleanup: Removed wan from the br-lan bridge device.
These changes gave a huge boost from 250 Mbps up to 450 Mbps, but the R7800 remains plateaued there, while the R7000 running DD-WRT effortlessly pushes 600+ Mbps.
Questions for the Community
Has anyone else running Qualcomm IPQ8065 / QCA9984 hardware under recent OpenWrt release managed to push beyond ~450 Mbps on 802.11ac to match Broadcom FastPath/CTF performance?
Are there specific sysctl, ath10k module parameters, or A-MPDU aggregation / TX-queue scheduling tweaks that can bridge this gap?
In your case (no NAT), it's supposed to be useless.
I have and old AP ipq40xx DAP-2610, some time ago, I got better results playing with irqbalance package.
Maybe someone more expert than me could put some light on it
R7800 / R7000 do not have hardware flow offloading support here so don't set that. Enable software flow offloading and packet steering. The way to get hardware offloading support for your R7800 is to run a custom NSS build which you might want for your setup as it would be much more performant (albeit unofficial). Also, when they changed from swconfig to DSA (also in upstream Linux) there was a small performance hit on some targets. See also https://openwrt.org/toh/netgear/r7800#performance_tuning.
OpenWrt is an open source Linux distro which does not have hardware acceleration support unless it is open source (e.g. MediaTek Filogic SoC devices have many hardware acceleration features like HFO, WED, ATF, etc. since it's open source via mt76; but Qualcomm based SoCs like your ipq80xx are somewhat less supported).
DD-WRT also uses some proprietary/(closed source?) software for your devices (I used to run it on an R7000 over a decade ago it's good) and thus might perform better in some cases.
My R7800 running 25.12 snapshot does about 560 Mb/s measured with iperf3 between Samsung S20 and PC. PC connected by ethernet on the lan. But I do not use VLAN's.
When using the R7800 as AP do not use the wan port and do not add the wan port to the bridge
I use irqblance and packet steering, software flow offload is on but that does not matter when used as an AP
When using the R7800 as AP do not use the wan port and do not add the wan port to the bridge
Apologies for inserting my nose here.. Can I trouble you to explain why this might be frowned upon? Is there something unique to the R7800 or other qcom based units regarding this?
If I was still trying things around in your case, I would try SNAPSHOT and compare if it behaves the same
You can do owut upgrade -v -V SNAPSHOT and then go back with owut upgrade -v -V 25.12 as needed, there no much deviation between these w.r t to config files as of today
Nothing unique but it has two cpu ports one is attached to the wan, the other to the rest of the ports.
when the switch to DSA took place a bug was introduced which resulted in a non working bridge if you added the wan port to br-lan.
This has been corrected but not in an optimal way, it works but with many duplications so is slower.
I think this has also been corrected but not sure if this is in 25.12.5.
Even if fully corrected traffic might still has to go via the CPU port to the other ports so unless you really need the wan port as fifth port in your bridge do not use it if you use these routers as AP
I think this is actually corrected now, there are some qualcommax patches ported to generic, like 711-04 and around it. Not sure if these patches made to the 25.12.5 though, probably not, they were made after 12.5 was released. I wonder if anybody can actually confirm that they work...
Thanks everyone for the input - here's what I tried and where I landed
Really appreciate the detailed responses, especially @phinn for the NSS build link and DSA context, and @egc for the specific AP-mode advice and your 560 Mb/s data point to compare against. Wanted to close the loop with what I actually tested.
Changes made (all via UCI, R7800 as pure AP - WAN disabled, no NAT/routing):
Removed the wan port from the br-lan bridge entirely (per @egc's advice - previously had it added as a spare untagged LAN port)
Set flow_offloading and flow_offloading_hw both to 0 in firewall defaults (confirmed via testing this device doesn't route/NAT anything, so offloading shouldn't apply either way - wanted a clean baseline)
Set packet_steering to 0 - worth noting this is the opposite of what was suggested. I'd tested packet steering (all CPUs) earlier this week and saw a real, repeatable drop in single-stream throughput (442 -> 312 Mbps on a phone Speedtest, same conditions) when it was on, so I left it disabled for this round rather than re-introduce that variable
Result:
Wireless iperf3, phone -> AP -> switch -> OPNsense (LAN-only, no WAN/VPN in the path):
328 Mbit/s average, 0 retransmits across all intervals
That's essentially flat versus my original baseline (350 Mbit/s) before any of today's changes - maybe even a hair lower - zero retransmits both before and after, so whatever's capping it isn't packet loss or interference.
Where I've landed:
@egc's note that they don't use VLANs stood out to me - my setup runs 5 SSIDs across VLAN1/10/20/30 via bridge-vlan (802.1Q tagging happening in software, no hardware switch offload available since ipq806x lacks that outside the NSS build). Wondering if VLAN tagging overhead might be a bigger contributor to the gap than the WAN-port/offloading settings turned out to be, given those changes were basically a wash.
Planning to try the NSS build next since it directly targets hardware-accelerated forwarding, which seems like the more promising lever at this point. Will report back once I've tested it - and if anyone's run the NSS build specifically with multiple VLANs/SSIDs (not just a flat single-SSID setup), I'd love to hear how that went, since most of the numbers I've seen reported (including my own 560 comparison point) seem to be VLAN-free setups.
