OpenWrt Wi-Fi slow after idle: a 10-minute diagnostic and reversible tests

By Wu Jun · Updated 2026-10-29 · 5 min read

Symptom: after an idle period, one device's downlink drops to around 10 Mbps and may remain slow, while other devices are fine. On a GL-MT6000 running OpenWrt mt76, we reproduced two independent conditions: vow_atf preventing rate recovery, and a 40 MHz-only client operating inside an 80 MHz BSS.

This page gives a reversible diagnostic order. It does not recommend blindly copying "optimisation commands". The CSI capture is public ^[1], the diagnostic/tuning scripts ship in the toolkit ^[2], and the driver is upstream mt76 ^[3].

0. Back up before measuring

Record:

uname -a
cat /etc/openwrt_release
iwinfo <ap> info
iw dev <ap> station dump
ubus call system board

Save /etc/config/wireless and the installed firmware. Do not run an unknown script on a production router.

1. Locate the layer that is slow

Separate broadband from Wi-Fi first. One Speedtest screenshot cannot prove which layer is responsible.

2. Check whether WAN/LAN is really 100 Mbps

for i in /sys/class/net/*; do
  name=$(basename "$i")
  [ -r "$i/speed" ] && echo "$name $(cat "$i/speed") Mb/s"
done

Then inspect the WAN and suspect LAN ports:

ethtool <wan-iface>
ethtool <lan-iface>

Look for:

• Speed 100 versus 1000/2500;
• local and link-partner advertised modes;
• rx_errors, tx_errors, rx_crc_errors;
• cable, wall port and computer NIC limitations.

In our case the WAN link was 1000 Mbps full duplex all along. The actual 100 Mbps link was another machine's advertised NIC mode. Calling that LAN result "the router turned gigabit into 100 Mbps" was a diagnostic error: check link-partner advertisement before touching Wi-Fi.

3. Sample the station rate repeatedly

for i in $(seq 1 20); do
  date +%H:%M:%S
  iw dev <ap> station dump | grep -E "Station|tx bitrate|rx bitrate|signal:"
  sleep 2
done

Interpretation:

• tx bitrate is AP-to-client and often explains slow download;
• a drop to VHT-MCS 0 1SS after idle, with occasional recovery under traffic, points to rate adaptation/recovery;
• high rx and low tx shows the client can transmit but AP transmit is impaired;
• if every client is low, investigate channel/DFS/interference first.

One tx bitrate value is the last sample, not an average. Observe it over time.

4. Byte accounting: low rate or retransmission?

During a LAN transfer record:

• bytes transmitted by the AP radio;
• bytes actually received by the client;
• PHY rate, duration and retry counters.

If AP transmitted and client received roughly the same:

• data is not being lost en masse;
• the radio may be staying at a low rate and leaving airtime idle;
• rate selection is a strong suspect.

If AP transmitted far more than the client received:

• suspect retransmission, interference, weak signal or a receiver issue;
• inspect RSSI/SNR, channel and hardware before changing vow_atf.

5. A/B test one: vow_atf and recovery

On this MT7986 + mt76 setup, vow_atf=1 allowed the client to fall to MCS0 after idle and remain there under continuous traffic. Setting it to 0 allowed recovery within roughly 15-20 seconds.

Read first:

for f in /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf; do
  echo "$f: $(cat "$f")"
done

Temporary A/B on a research device only:

echo 0 > /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf
# idle 60 s, then run six 6-second LAN downloads
# record tx bitrate, achieved throughput, AP TX bytes and client RX bytes

Restore the original value:

echo 1 > /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf

The toolkit's mt76-wifi-tune and watchdog can persist the zero value, but this is not a universal patch. Different firmware, chips and clients may not reproduce it. Keep a rollback path: tar.gz / SHA-256.

6. A/B test two: client width versus BSS width

Inspect the radio and stations:

iw dev <ap> info
iw dev <ap> station dump | grep -E "Station|bitrate|signal"
iwinfo <ap> info

In this case:

• an older client could negotiate only 40 MHz and repeatedly fell to MCS0 inside HE80;
• an 80 MHz phone and another 80 MHz device were stable;
• switching the 5 GHz radio to HE40 produced 328-419 Mbps in 6/6 runs for the older client.

This does not mean 40 MHz is always better or 80 MHz is always worse:

• 80 MHz provides more CSI subcarriers and finer range resolution;
• a narrow-band client in a wide BSS needs explicit compatibility testing;
• if the router also serves the home, isolate the sensing radio/AP from ordinary clients where possible.

Before switching, save the configuration. After switching, confirm interface names, CSI daemon bandwidth metadata and client association.

7. Ten-minute decision flow

slow
|- wired also slow?
|  |- check WAN/LAN speed, link partner, errors and ISP
|  \\- Wi-Fi is not the first suspect
|- only Wi-Fi downlink slow?
|  |- tx bitrate at MCS0?
|  |  |- idle-triggered and stuck -> test vow_atf A/B
|  |  \\- 40 MHz client in an 80 MHz BSS -> test width A/B
|  |- AP TX versus client RX differs a lot -> retries/signal/interference
|  \\- every client slow -> channel/DFS/airtime
\\- Speedtest slow but LAN normal -> ISP/server/DNS

8. Record results

Save for every A/B:

9. Do not do this

• use a public Speedtest as the only A/B;
• trust one iw station dump;
• permanently modify debugfs/wireless without backup;
• call vow_atf the only firmware root cause based on correlation;
• keep every legacy client unusable just to obtain 80 MHz CSI.

Verify first, persist second. Publish failed sessions before publishing an "optimisation script".

Related: the full slow-Wi-Fi investigation · mt76 rate-control analysis · 80 versus 40 MHz