CSI 上线后 Wi-Fi 变慢：vow_atf 与 40MHz 客户端的实测排障

作者 Wu Jun · 更新于 2026-11-02 · 约 5 分钟

这是我们在把 CSI 跑进真实家庭网络后遇到的最难排查的问题之一。它同时叠加了客户端空闲状态、 固件调优开关和带宽协商，所以单看一次测速很容易误判：

同一台路由器，开启 CSI 之后，Mac 的下行速度从 300–400Mbps 掉到 6–10Mbps，而上行依然有 45Mbps。

下面是完整的定位过程、可复现触发条件与两种修复方式。所有数字均为本项目一手实测（E 级）。 公开的 10 分钟 CSI 数据集 ^[1] 不包含这些网络吞吐日志，因此本文公开实验顺序、 条件、结果表和工具包 ^[2]；原始测速日志因含家庭网络信息不进入公开数据集。 涉及的开源驱动为上游 mt76 ^[3]。

1. 先把范围缩小到"无线下行"

我们做了四组对照，把可能的环节逐个排除：

结论：只有 AP→客户端（下行）方向塌陷，速率被压到 VHT-MCS0 1SS（13.5Mbps）。

2. 关键线索：空闲就塌，且"塌了回不来"

用路由器侧 debugfs 观察客户端实时速率：

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

现象：

1. 空闲约 1 秒后，AP 对该客户端的发送速率掉到 MCS0；
2. 持续流量下有时能爬回 MCS9（约 400Mbps），有时永远爬不回来；
3. 客户端与 AP 的 ping：0% 丢包，但 RTT 抖动到 243ms（省电/缓冲特征）。

在"卡死"状态里，即使连续 36 秒满载下载，速率依然停在 7–10Mbps。

3. 高置信度触发因素一：固件 VoW ATF 阻止速率恢复

在 mt76 的 debugfs 里有一个固件特性开关：

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

对照实验（同客户端、同一时段、只改这一个开关，均为"空闲 60 秒后连续 6 次下载"）：

可复现修复开关（已持久化）：关闭 vow_atf，并在开机与每分钟的 watchdog 中重放设置 （驱动重载/重启后不会丢）：

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

对应脚本已公开发布： 稳定工具包 / SHA-256。

4. 触发条件二：40MHz 客户端接入 80MHz BSS

ATF 解决后，仍然存在"周期性塌陷"。继续对照发现：

把 5GHz 射频从 80MHz 切成 40MHz（htmode=HE40）后：

结论：只协商 40MHz 的老客户端，在当前 MT7986 + mt76 固件组合中与 80MHz BSS 不兼容。 把射频设成该客户端的原生带宽后问题消失。由于没有继续获取固件内部速率状态，本文不把机制进一步归因到 某个确定的 PPDU 字段或寄存器，只声明可重复观察到的条件与修复结果。

以上属于本项目 E 级现场记录。实验方法与修复脚本已整理进公开工具包 ^[2]； 原始吞吐日志不属于公开 CSI 数据集 ^[1]。

5. 两种修复怎么选

可以做一个 30 秒切换的脚本，按需切换：

sh /usr/bin/wifi-htmode HE80   # CSI 实验模式
sh /usr/bin/wifi-htmode HE40   # 日常模式

6. 你可以直接复用的判断流程

Wi-Fi 变慢
  ├─ 只有下行慢、上行正常？ ──▶ 查 AP 侧 tx bitrate 是否被压到 MCS0
  │     ├─ 空闲后塌陷且不恢复 ──▶ 关 vow_atf（并持久化）
  │     └─ 仍周期性塌陷 ─────▶ 查客户端带宽 vs BSS 带宽是否不一致
  ├─ 上下行都慢 ──▶ 查干扰/信道/协商（本文不覆盖）
  └─ 有线也慢 ────▶ 查 WAN 协商与宽带（本案例 WAN 始终 1000Mbps）

如果你的路由器也是 MT7986/MT7915 系列（OpenWrt + mt76），建议先跑一遍上面两张表， 五分钟就能判定你遇到的是哪一种。

7. 30 分钟最小复现步骤

1. 记录路由器型号、OpenWrt/mt76 版本、Wi-Fi 固件 MD5、信道、带宽、国家码和发射功率；
2. 记录客户端型号、协商带宽、空间流、RSSI/SNR 与省电设置；
3. 先做上行、下行和有线三个方向测试，确认问题只在 AP→客户端；
4. 在路由器上连续采样 tx bitrate / rx bitrate，不要只看一次读数；
5. 空闲 60 秒，然后做 6 次 6 秒内网下载，记录每次 PHY 速率、实际吞吐和两端字节数；
6. 只修改 vow_atf，重复第五步；
7. 恢复 vow_atf，再把 BSS 从 HE80 改为 HE40，重复第五步；
8. 恢复原配置，并保留每一步的时间、命令输出和客户端状态。

建议的最小结果表：

8. 证据边界

• vow_atf=1/0 的 6 次对照结果支持：该开关与本次设备能否恢复高速率存在强关联；它不是固件内部因果机制的证明；
• HE80/HE40 对照在本次设备上支持：BSS 宽度与客户端原生宽度不匹配和问题复现相关；仍需其他设备复核；
• 本文没有反编译固件，也没有抓取内部速率控制状态，因此不声称已经定位到具体寄存器；
• 修复脚本改变的是可观察条件，不是给 MediaTek 固件打二进制补丁；
• 不同固件版本、客户端芯片和省电策略可能不复现，必须用自己的 A/B 数据判断。

9. 提交问题时的记录模板

router: GL-MT6000 / OpenWrt ... / mt76 ...
firmware: mt7986_wm.bin MD5 ...
client: model / chip / VHT or HE / NSS / negotiated width
radio: band / channel / width / country / txpower
problem: downlink only? idle trigger? persistent?
baseline: 6x6s results, tx/rx bitrate, bytes AP TX vs client RX
vow_atf=0: 6x6s results
HE40: 6x6s results
restored state: yes/no

只有把这些条件写全，维护者才能判断是驱动、固件、客户端省电还是环境问题。