OpenWrt 空闲后变慢：10 分钟诊断流程与可回退实验

作者 Wu Jun · 更新于 2026-10-29 · 约 5 分钟

症状：空闲一段时间后，某台设备的下载掉到约 10Mbps，甚至长时间不恢复，而其他设备正常。 在 GL-MT6000 + OpenWrt mt76 上，我们复现到两个独立条件：vow_atf 阻止速率恢复，以及 40MHz-only 客户端处在 80MHz BSS。这个页面给出可回退的诊断顺序，不鼓励直接复制“优化命令”。

所有结果来自本项目真机记录；CSI 原始抓包公开 ^[1]，诊断和调优脚本放在 公开工具包 ^[2]。上游驱动为 mt76 ^[3]。

0. 先备份，再测量

开始前记录：

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

保存 /etc/config/wireless 和当前固件版本。不要把生产路由器的无线配置直接交给未知脚本。

1. 先判断“慢”发生在哪一层

先把“宽带问题”和“Wi-Fi 问题”分开。仅凭一次 Speedtest 截图无法完成这一步。

2. 检查 WAN/LAN 是否真的只有百兆

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

再对 WAN 和可疑 LAN 口运行：

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

重点看：

• Speed 是 100 还是 1000/2500；
• 本端和 link partner 的 advertised modes；
• rx_errors / tx_errors / rx_crc_errors；
• 网线、墙内端口和电脑网卡是否只支持百兆。

本项目的真实案例里，WAN 一直是 1000Mbps 全双工，真正只有百兆的是另一台机器的网卡协商； 如果把那条 LAN 的结果当成 WAN，就会误判“刷机把千兆刷成百兆”。这类问题应先看 link partner 通告， 而不是改无线。

3. 采样客户端速率，不要只读一次

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

判断：

• tx bitrate 是 AP→客户端，通常比 rx bitrate 更能解释“下载慢”；
• 空闲后掉到 VHT-MCS 0 1SS，而持续流量有时能爬回高速率，说明速率自适应/恢复问题；
• 上行速率高、下行低，说明不是客户端完全不会发射；
• 所有客户端都低，应优先查信道/DFS/干扰。

不要把单个 tx bitrate 当作平均值。它是最后一次采样的状态，必须按时间连续观察。

4. 字节对账：低速率还是重传

在一次内网下载期间同时记录：

• AP 无线接口发送字节数；
• 客户端实际收到的字节数；
• PHY 速率、耗时、重传计数。

如果 AP 发出和客户端收到大致相同：

• 数据没有大量丢失；
• 空口可能长期停留在低速率，剩余时间空闲；
• 优先怀疑速率选择。

如果 AP 发出的字节远大于客户端收到：

• 可能存在重传、干扰、信号差或设备接收问题；
• 先检查 RSSI/SNR、信道和硬件，不要直接关闭 vow_atf。

5. A/B 实验一：vow_atf 与速率恢复

在 MT7986 + mt76 的本次实测中，vow_atf=1 时客户端空闲后掉到 MCS0，连续流量也可能无法恢复； 把开关临时改为 0 后，约 15–20 秒可爬回高速率。

先读取，不修改：

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

临时 A/B（只在研究设备上做，记录原值）：

echo 0 > /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf
# 空闲 60 秒，然后连续做 6 次 6 秒内网下载
# 记录每次 tx bitrate、实际吞吐、AP TX 字节、客户端 RX 字节

恢复原值：

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

工具包里的 mt76-wifi-tune 和 watchdog 用于持久化关闭，但不是通用补丁。不同固件、芯片和客户端可能 没有相同行为，必须保留原值和回退路径。工具包： tar.gz / SHA-256。

6. A/B 实验二：客户端宽度与 BSS 宽度

查看射频和站点信息：

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

在本次案例中：

• 一个只能协商 40MHz 的旧客户端，在 HE80 BSS 中反复塌到 MCS0；
• 80MHz 手机和另一台 80MHz 设备稳定；
• 将 5GHz 射频切到 HE40 后，旧客户端 6/6 次恢复到 328–419Mbps。

这不是“40MHz 永远更差”或“80MHz 永远更好”的结论：

• 80MHz 提供更多 CSI 子载波和更细距离分辨率；
• 但窄带客户端与宽带 BSS 的兼容性需要实测；
• 若设备同时承担家用网络，最好使用独立射频/AP，把感知链路和日常客户端分开。

切换前保存配置，切换后确认接口名、CSI daemon 的带宽元数据和客户端关联没有丢失。

7. 十分钟决策流程

慢
├─ 有线也慢？
│  ├─ 查 WAN/LAN speed、link partner、错误计数、ISP
│  └─ Wi-Fi 不是第一嫌疑
├─ 只有 Wi-Fi 下行慢？
│  ├─ tx bitrate 掉到 MCS0？
│  │  ├─ 空闲触发且不恢复 → 做 vow_atf A/B
│  │  └─ 40MHz 客户端在 80MHz BSS → 做宽度 A/B
│  ├─ 两端字节差很大 → 查重传/信号/干扰
│  └─ 全部客户端慢 → 查信道/DFS/空口
└─ Speedtest 慢、内网正常 → 查公网/服务器/DNS

8. 结果怎么写

每次 A/B 至少保存：

9. 不该直接做的事

• 用公网 Speedtest 代替内网 A/B；
• 只看一次 iw station dump；
• 未备份就永久修改 debugfs/无线配置；
• 把 vow_atf 的相关性宣传成唯一固件根因；
• 为了追 80MHz CSI 分辨率，让全家的旧客户端长期不可用。

先验证，再持久化；先写失败记录，再发布“优化脚本”。

相关：CSI 上线后 Wi-Fi 变慢的完整排障 · mt76 速率控制分析 · 80 与 40MHz 取舍