(Originally, I posted this in a thread specific to the Xiaomi AX3000T router, but I was kindly asked to create a dedicated topic for better visibility. Thank you for understanding!)
Yesterday, I installed OpenWRT OpenWrt 24.10.0-rc5 r28304-6dacba30a7 / LuCI openwrt-24.10 branch 24.337.27339~b1968d9 on my Xiaomi AX3000T router. Since then, I’ve been facing two persistent issues that I’ve been unable to resolve (I sincerely apologize for posting here, but I’ve scoured forums exhaustively and found no solutions).
Issue 1: Ethernet Speed Limitations
My ISP’s advertised speed is 890 Mbps, but via Ethernet, I’m only getting around 430 Mbps download and 650 Mbps upload. I tested this on two different laptops, and both showed identical results. For reference, my previous router (which recently died) delivered nearly full speed (~860 Mbps) over Ethernet.
Issue 2: Wi-Fi 6 Inconsistencies
I configured the 5 GHz interface with the following settings: MODE AX, Channel 36, Width 160 MHz. Strangely, speed tests show download speeds ranging from 150–250 Mbps, while upload speeds are nearly maxed out at ~750–780 Mbps (close to the ISP’s advertised rate).
What I’ve Tried:
Network Optimization: Under Network → Global Network Options → Packet Steering, I set it to “Enabled (All CPUs)” with Steering Flows = 256. This improved initial Wi-Fi download speeds from ~100 Mbps to ~200 Mbps (originally, after installing OpenWRT, Wi-Fi downloads barely hit 100 Mbps).
Flow Offloading: Experimented with Software and Hardware flow offloading in Network → Firewall. Hardware offloading had no noticeable impact, but Software offloading tanked download speeds to ~50 Mbps. I’ve since disabled it.
SQM Tweaks: Enabled SQM with fq_codel as the queueing discipline and simplest.qos as the script. Also tried Link Layer Adaptation (Ethernet with overhead) and set Per Packet Overhead = 64. Minor improvements occurred, but nothing significant. SQM is now disabled.
Questions:
Why is Ethernet capped at ~430 Mbps?
Why is Wi-Fi download speed so low while uploads are nearly full speed?
I’m at my wit’s end here and would deeply appreciate any guidance. Thank you in advance for your help!
Below, I’ll attach the contents of my configuration files for reference.
/etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd60:f58d:44cf::/48'
option packet_steering '2'
option steering_flows '256'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
/etc/config/firewall
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
You know that you share wifi link 2.4gbps speed not only between ap and sta, but also with anyone 50m from you. Ch36 is really poor choice in 99% of the world.
I noticed that enabling SW flow offloading significantly improved the LAN test—results were practically flawless (seems I overlooked testing this setup earlier and got a bit tangled in the process). However, the Wi-Fi test performance was downright disappointing. Oddly, the Wi-Fi test didn’t complete on the first try: it stalled during the uploading phase, with download speeds dropping to a mere 40 Mbps. Regrettably, I couldn’t capture a link or screenshot since the test never finalized.
Shoild not matter in context but -rc7 is out, owut or luci-app-attendedsysupgrade can help
All things point to flow control towards wan.
ethtool wan
: check agreed flow control
ethtool -a wan
: check configured
ethtool -A wan tx off rx off autoneg on
ethtool -r wan
: check logread | tail -10 that tx rx are off
redo speedtest (any, just compare feith previous)
For wifi try ch 100 or 149 , mzaybe even 80mhz autoch.
In your opinion, would it be better to upgrade to rc7 while preserving the current settings or perform a clean install/update in this scenario? I'm going to upgrade using the attended sysupgrade.
root@OpenWrt:~# ethtool wan
Settings for wan:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
root@OpenWrt:~# ethtool -a wan
Pause parameters for wan:
Autonegotiate: on
RX: off
TX: off
RX negotiated: on
TX negotiated: on
It didn’t make much sense, but I tried anyway...
root@OpenWrt:~# ethtool -A wan tx off rx off autoneg on
autoneg unmodified, ignoring
rx unmodified, ignoring
tx unmodified, ignoring
no pause parameters changed, aborting
root@OpenWrt:~# ethtool -r wan
root@OpenWrt:~# logread | tail -10
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for test
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for onion
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for localhost
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for local
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for invalid
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for bind
Thu Jan 30 00:17:01 2025 daemon.info dnsmasq[1]: using only locally-known addres ses for lan
Thu Jan 30 00:17:02 2025 user.notice firewall: Reloading firewall due to ifup of wan (wan)
Thu Jan 30 00:17:02 2025 user.notice natflow: Reloading natflow-zone due to ifup of wan (wan)
Thu Jan 30 00:17:02 2025 user.notice nlbwmon: Reloading nlbwmon due to ifup of w an (wan)
P.S. It looks like there’s an API issue — every time I try to update via luci-app-attendedsysupgrade, I get this error: Could not reach API at "https://sysupgrade.openwrt.org/api/v1/overview?1738196901775". Please try again later.
ethtool -r re-negotiates link speed and pauses.
After that ethtool and ethtool -a would show negotiated link parameters.
Lots of noise, better check dmesg (kernel log under luci/system/logs)
Alright, so I finally figured out what the issue was. Turns out it wasn’t the OpenWRT firmware itself or the settings alone causing the problem. Here’s the breakdown:
First, the best Ethernet performance came after enabling software flow offloading (special thanks to brada4) alongside packet steering. For optimal results, I had to set it to "Enabled (All CPUs)" and adjust "Steering Flows" to 256.
Second, digging through forums, I learned Xiaomi routers are notoriously sensitive to physical obstructions. Coming from a lifetime of Asus routers, I’ve never seen signal degradation this severe. After trial-and-error testing and using RF analysis tools, I nailed down the Wi-Fi settings. Switching to channels 44 or 48 on 5GHz worked best. Avoid channel 36 and anything above 140 — for some reason, channels above 140 just dropped entirely, making the network invisible to all devices.
Here’s a pro tip for weak signal areas: If the router’s behind walls or obstacles, try maxing out the channel width (160 MHz) but lowering the transmit power to between 75% and 93% of max (for the AX3000T, that’s 21dBm or 125 mW). Counterintuitively, reducing power improved speeds dramatically, even through walls.
P.S. When testing with a laptop in direct line-of-sight (2.5 meters away), speeds hit 890 Mbps — exactly what my ISP promises.
Using the SQM tweaks mentioned in the first post of this thread, you can squeeze out a slight speed boost (~25 Mbps from what I’ve seen). That said, fq_codel and simplest.qos performed the best here, while piece_of_cake.qos didn’t really move the needle — no noticeable difference in speeds.
