OpenWrt 空闲后变慢：10 分钟诊断流程

2026-10-11 · 约 2 分钟

症状：空闲一段时间后，某台设备的下载掉到约 10Mbps（有时更差），而其他设备正常。 下面是我们用来在一台 MT7986 路由器上找到两个根因的 10 分钟诊断流程 （E 级证据；修复以脚本形式提供 ^[2]，测量数据已公开 ^[1]）。

1. 方向测试：是不是只有下行？

# 在 AP 上
iw dev <ap> station dump | grep -E "Station|tx bitrate|rx bitrate|signal:"

• tx bitrate 很低（MCS0）而 rx bitrate 很高 → AP→客户端方向出问题；
• 如果两个都低 → 那更可能是信号/干扰/法规问题。

2. 采样速率，别信单次读数

for i in $(seq 1 20); do
  iw dev <ap> station dump | grep -m1 "tx bitrate"
  sleep 2
done

在 MCS0 与 MCS9+ 之间来回跳 → 指向速率控制/状态问题。被钉在中间速率 → 指向信道条件。

3. 字节对账：是重传还是空口空闲？

在一次内网传输里，对比 AP 发出的字节与客户端收到的字节：

• 发出 ≈ 收到：空口是空闲的，只是速率低（速率控制问题）；
• 发出远多于收到：重传风暴（射频/干扰问题）。

4. 核对两个已知的 mt76 陷阱

# 陷阱 1：固件 VoW ATF（默认 1）阻止速率恢复
cat /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf
echo 0 > /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf     # 立即验证

# 陷阱 2：80MHz BSS 里的 40MHz 客户端
iw dev <ap> info | grep -E "channel|width"                 # 射频宽度
iw dev <ap> station dump | grep -m1 "tx bitrate"           # 客户端宽度会体现在速率串里

修好陷阱 1 后的预期结果（MT7986 实测）：最初几次突发仍然慢，然后在 15 秒内爬回约 400Mbps。 如果你的客户端是 40MHz 设备，再把射频切到 40MHz（稳定 330–420Mbps）。

5. 让修复在重启后仍然生效

vow_atf 位于 debugfs，驱动重载后会丢失，所以要靠开机初始化脚本 （/etc/init.d/mt76-wifi-tune）加上每分钟重放一次的 watchdog 来持久化。两个脚本都在本项目工具箱里。

6. 速查表

相关：mt76 速率控制深度分析 · 80 vs 40MHz · 复现教程