Exclusive: why Wi-Fi collapses after you enable CSI (firmware ATF and the 40 MHz client trap)

2026-10-11 · 3 min read

This is the hardest problem we hit after putting CSI into a real home network, and we have not found it documented anywhere else:

On the same router, once CSI was enabled, one Mac's downlink dropped from 300–400 Mbps to 6–10 Mbps, while its uplink stayed at ~45 Mbps.

Below is the full isolation process, the two root causes, and the two fixes. Every number is a reproducible first-party measurement (grade E) — raw data, the A/B method and the scripts are published ^{[2] [3]}; the driver involved is the upstream open-source mt76 ^[1].

1. Narrow it to "wireless downlink"

Four control experiments ruled out everything else:

Conclusion: only the AP→client (downlink) direction collapses, pinned to VHT-MCS0 1SS (13.5 Mbps PHY).

2. The key clue: it collapses when idle, and does not recover

Watching the client's live rate from the router side:

iw dev <iface> station dump | grep -E "tx bitrate|rx bitrate|signal"

What we saw:

1. about 1 second after going idle, the AP's transmit rate for that client drops to MCS0;
2. under continuous traffic it sometimes climbs back to MCS9 (~400 Mbps) — and sometimes never recovers;
3. ping between client and AP: 0% loss, but RTT jitter up to 243 ms (a power-save / buffering signature).

In the "stuck" state, even a continuous 36-second saturated download stayed at 7–10 Mbps.

3. Root cause #1: firmware VoW ATF pins the rate

mt76 exposes a firmware feature switch in debugfs:

cat /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf   # default = 1

A/B test (same client, same time window, only this switch changed; each run is "60 s idle, then 6 consecutive downloads"):

Fix (made persistent): disable vow_atf and replay the setting at boot and every minute in the watchdog, so it survives driver reloads and reboots:

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

4. Root cause #2: a 40 MHz client inside an 80 MHz BSS

With ATF fixed, a periodic collapse remained. Further A/B testing showed:

Switching the 5 GHz radio from 80 MHz to 40 MHz (htmode=HE40):

Conclusion: a client that only negotiates 40 MHz is dragged down by rate adaptation / PPDU handling when it sits in an 80 MHz BSS. Set the radio to the client's native width and the problem disappears.

5. Choosing between the two fixes

A ~30-second switch script lets you move between them on demand:

sh /usr/bin/wifi-htmode HE80   # CSI experiment mode
sh /usr/bin/wifi-htmode HE40   # daily mode

6. A decision flow you can reuse

Wi-Fi got slow
  ├─ only downlink slow, uplink fine? ──▶ check the AP-side tx bitrate for MCS0
  │     ├─ collapses when idle, never recovers ──▶ disable vow_atf (and persist it)
  │     └─ still collapses periodically ───────▶ compare client width vs BSS width
  ├─ both directions slow ──▶ look at interference / channel / negotiation (not covered here)
  └─ wired is slow too ─────▶ check WAN negotiation and ISP (WAN stayed 1000 Mbps in our case)

If your router is also MT7986/MT7915 class (OpenWrt + mt76), run the two tables above first — five minutes tells you which of the two cases you are in.

Related: 80 MHz vs 40 MHz · mt76 rate control deep dive · OpenWrt Wi-Fi slow after idle · router CSI guide