Firmware: 4.9.1 (be14000-4.9.1_release2-1053-0722-1784729880.bin), OpenWrt 21.02-SNAPSHOT, BusyBox built 2025-10-10
Hardware: 2× GL-BE14000 (Flint 4), 10G backhaul via Sodola SL-SWTGW3C8F switch
WAN service: ~900/900 Mbps
Topology
-
Unit A (downstairs, 192.168.1.1): router mode, DHCP WAN, public IPv4
-
Unit B (bedroom): router or AP mode, DHCP WAN on a private address behind Unit A (double NAT)
-
Ubuntu 24.04 test server (192.168.1.11, ConnectX-4 Lx) on Unit A's SFP+
Symptom
Wi-Fi clients on Unit B are capped at 450–580 Mbps upload to internet endpoints while download reaches the full 900. Setting mtkhnat.global.enable='0' on Unit B restores ~900/800 immediately in router mode and persists across reboot.
| Client | Upload, HNAT on | Upload, HNAT off |
|---|---|---|
| Pixel 9 Pro XL | 450–550 | ~800 |
| Pixel 6 Pro | 450–700 | ~800 |
| Pixel 4a (Wi-Fi 5) | 580 | — |
| PC (MT7927) | 850–870 | ~700 |
Unit A is unaffected. Same clients, same firmware, HNAT enabled: 900/900.
Key evidence: LAN path unaffected, WAN path capped
Same clients, same AP, LAN target (OpenSpeedTest to 192.168.1.11), HNAT on:
| Client | LAN up | Internet up |
|---|---|---|
| Pixel 9 Pro XL | 1,450 | 450 |
| Pixel 6 Pro | 1,540 | 470 |
| PC | 3,250 | 870 |
Clients sustaining 1,450+ Mbps upload through Unit B's Wi-Fi and Ethernet path were simultaneously limited to 450 on WAN.
Ruled out
-
Configured shaping —
qos.general.enable='0',gl_dpi_qos.prio_enable='0', parental control disabled, notcshaping instantiated on either unit, no nft limit/quota/meter rules. VPN policy routing scoped to an ipset covering two domains. -
MLO/EMLSR — reproduces on single-band 6 GHz and on a non-MLO Wi-Fi 5 client.
-
Client radio generation — a Wi-Fi 5 Pixel 4a hits the same ceiling as Wi-Fi 7 devices.
-
RTT sensitivity — 7 ms of
netemdelay on the LAN server left phone upload at 1,358–1,820 Mbps. -
Test tooling — Cloudflare speed test in-browser matches the Ookla app.
-
IPv6 — disabled throughout.
Packet capture
tcpdump on Unit A's WAN (eth1.3) during a phone upload captured 2,710 packets / 1.9 MB over 19.5 s against a transfer of several hundred MB, with a flat ~33 kB/s trickle after connection setup. Bulk data never reaches the CPU, consistent with the flow being handled entirely in the PPE.
Trade-off
Disabling acceleration moves forwarding to software. LAN throughput drops (phones 1,800→1,100; PC 2,700→1,430) while WAN upload becomes correct. Users cannot currently have both.
Open question
Why does the offload path degrade Wi-Fi→WAN upload on a downstream unit while leaving download and Wi-Fi→LAN intact, and while the same firmware on the upstream unit is unaffected? The private-address WAN on Unit B is the most obvious difference between the two units but has not been isolated as the cause.
Secondary issue: HNAT toggle not exposed in AP mode
With Unit B in AP mode, the Network Acceleration setting is absent from the UI, though mtkhnat.global.enable remains readable and settable via UCI. Users who need to change it in AP mode have no supported way to do so.
Third issue: separate upload ceiling in AP mode
With Unit B in AP mode and mtkhnat.global.enable='0' confirmed via UCI, clients reach only 850/600 (Pixel 9 Pro XL) and 860/570 (Pixel 6 Pro) — below the ~900/800 the same clients achieve in router mode with HNAT disabled, and with download also reduced from 900 to ~850. Since HNAT is off in both cases, this appears to be a distinct limitation in the AP-mode forwarding path rather than the offload issue above.
