802.11无线网络观察：从AX201驱动到160MHz协商排障

1. 观察实验的出发点：802.11 标准与 Wi-Fi 的“两张皮”

最近整理手头几台笔记本电脑时，我决定好好做一次“网络观察实验”，对象就是大家都离不开的 802.11 无线局域网（Wi-Fi）。起因很简单，同事的一台笔记本用的是 Intel Wi-Fi 6 AX201 无线网卡，系统重装后驱动一直装不上，报错时好时坏，而他在网上搜到的解决办法基本都是“重装驱动、换驱动版本”，没有一个人讲清楚为什么 AX201 这块卡会如此挑环境。于是我把手头的实验设备翻出来，从标准、协议、空口报文到驱动排障，完整走了一遍，这篇文章就是这次实验的记录。

这次实验适合谁参考？两类人。一类是网络运维、弱电工程、无线实施相关从业者，平时大量时间花在“信号满格但网速不稳”这类问题上，需要建立一套从物理层到链路层的观察方法；另一类是普通用户，手头正好有 Intel AX201 或类似 Wi-Fi 6 网卡，遇到驱动安装失败、协商速率上不去、5GHz 频繁断连的问题，想弄明白背后真正的原因。我会把实验里用到的工具、看的指标、踩过的坑全部列出来，尽量做到“你看完能自己操作”。

先说一个最容易被混淆的前提：802.11 和 Wi-Fi 并不是同义词。IEEE 802.11 是一套由电气电子工程师学会维护的标准族，定义了无线局域网的物理层和 MAC 层行为；而 Wi-Fi 是 Wi-Fi 联盟做的互操作认证品牌，联盟从 802.11 标准中挑选出实际可用的子集，进行厂商间互通性测试，通过后允许贴“Wi-Fi”标志。也就是说，设备上贴不贴 Wi-Fi 认证标，和它内部是否完整支持 802.11ax 协议字段，是两码事。

我在实验里刻意不把“Wi-Fi 6”当成一个整体黑盒，而是去抓取具体的协议元素，比如 HT Capabilities、VHT Capabilities、HE Capabilities、HE Operation 元素。很多所谓的“网速跑不满”问题，从这些字段里能直接找到答案。这套思路，就是这篇博文的核心：与其把 Wi-Fi 当电器用，不如把它当系统来观察。

2. 协议观察的三层视角：射频、帧交换与性能表象

2.1 观察要有地图：物理层、链路层、传输层分开看

无线网络问题最麻烦的地方在于，用户看到的都是“下载速度慢”“网页转圈”，但造成这个结果的原因可能分布在三个完全不同的层面。我的做法是把观察对象分成三层，每一层只看该层能回答的问题。

物理层解决的是“信号行不行”的问题。这里要看的指标包括接收信号强度（RSSI）、底噪、信噪比（SNR）、信道空闲评估、物理层速率（PHY Rate）。如果一个位置 RSSI 在 -70dBm 以下，还谈什么 MCS 速率、重传率，都是舍本逐末。信号是地基，地基不行上层全白搭。

链路层解决的是“帧换得顺不顺”的问题。802.11 是一个共享介质协议，所有终端都在同一信道里轮流发声，避让冲突靠的是 CSMA/CA（载波侦听多址接入/冲突避免）。这一层要观察的重传率（Retry Rate）、帧聚合情况、Beacon 帧质量、以及关联终端的数量和行为。比如一个 2.4GHz 信道上挂了 30 台物联网设备，哪怕每台设备只产生一点点流量，也会把信道利用率吃满，正常终端的帧得排很久队才能发送一次。

传输层解决的是“端到端体验如何”的问题。通常用 iperf3 打流测试，记录吞吐量、延迟、重传、乱序。这一层的表现最直观，但恰恰最容易误导人——我见过很多现场，工程师一上来就跑 iperf3，看到吞吐低就断定无线有问题，结果最后发现是笔记本的省电模式把网卡降频了，或者 AP 的上联交换机端口协商到了百兆。

所以我在实验里严格规定：分析问题时，先物理层，再链路层，最后传输层。绝不在没看 RSSI 和重传率的情况下直接调整 AP 参数。

2.2 关键帧类型：Beacon、Probe、Data 各有各的读法

空口抓包后，Wireshark 里密密麻麻的帧很容易让人看晕。我习惯先把帧分类，再决定关心哪些。

**Beacon 帧（信标帧）**是 AP 周期广播的，相当于无线网络的心跳。一个合格的 Beacon 里包含了 SSID、支持速率、信道信息、以及关键能力字段。观察它可以看到 AP 实际在哪个信道工作、开启了哪些特性（比如是否开启了 802.11ax，是否启用了 OFDMA）、有没有广播隐藏 SSID。在 5GHz 频段，Beacon 帧间隔通常为 100ms，2.4GHz 常常也是 100ms，你可以通过抓包统计 Beacon 是否准时、是否出现丢帧，来判断 AP 是否存在供电不稳、固件异常等问题。

**Probe Request / Response（探测请求/响应）**是终端扫描网络时使用的。终端发出 Probe Request，AP 回复 Probe Response。这一对帧能看出终端的支持能力，尤其是客户端是否声明支持 160MHz 频宽、是否支持 HE（也就是 Wi-Fi 6）、是否支持多链路操作等。我遇到过一种情况：路由器和网卡都支持 160MHz，但协商结果只有 80MHz，后来抓包发现网卡的 Probe Request 里 160MHz 的偏好位是对的，但 AP 没有在响应里确认，问题出在 AP 固件的频宽回退策略。

Data 帧是真正的用户数据传输。观察重点包括 QoS 优先级字段、序列号连续性、重传标记以及聚合情况。如果一个 TCP 流的重传率超过 5%，不管物理层信号多好，体验大概率拉垮。重传帧在 Wireshark 里表现为同一个序列号出现两次，可以用 wlan.fc.retry == 1 过滤统计。

2.3 信道与频宽：160MHz 协商到底卡在哪

802.11 的信道设计，不同频段差异很大。2.4GHz 只有 3 个互不重叠的 20MHz 信道（1、6、11），设备密集区域天然拥挤；5GHz 信道多，但其中一部分是 DFS 信道（动态频率选择），有雷达规避要求；6GHz 是 Wi-Fi 6E 引入的新频段，信道资源最富裕。

频宽方面，802.11n 最高支持 40MHz，802.11ac wave 2 支持 80MHz 和 160MHz，802.11ax 延续了这些宽度并加入了 80MHz 内 OFDMA。160MHz 频宽在 5GHz 下由两个相邻的 80MHz 信道拼接而成，主信道（Primary Channel）和辅信道（Secondary Channel）之间必须保持一致。如果 AP 配置了 160MHz，但某个辅信道检测到雷达信号，AP 会触发信道可用性检查并回退到 80MHz，这就是“昨天还是 160MHz，今天只有 80MHz”的典型原因。

对于 Intel AX201 这类网卡，观察 160MHz 是否协商成功，最简单的办法是看连接状态里的“信道”和“接收速率”。在 Windows 下命令是：

如果输出里“信道”显示 100 之类的主信道，而“接收速率”只有 1200Mbps 左右，那大概率只协商到了 80MHz。理论上 2x2 MIMO 的 Wi-Fi 6 网卡在 80MHz 下最高协商速率约 1200Mbps，在 160MHz 下可以达到 2400Mbps 左右。当然，这只是链路层协商速率，实际吞吐还要打折扣。

3. 实操全过程：从空口抓包到验证 802.11ax 能力协商

3.1 环境准备：一台支持 Monitor 模式的无线网卡

要真正看到空口报文，普通网卡自带的“捕获模式”是不够用的，必须把无线网卡切到 Monitor 模式。Windows 系统对 Monitor 模式的支持非常有限，Intel AX201 这块卡在 Windows 下无法直接开启 Monitor 模式，所以我实验里准备了一台 Linux 系统的备用机和一张 USB 无线网卡。

Linux 下切换 Monitor 模式的方式很多，我惯用的是 iw 命令：

切换到 Monitor 模式后，执行 iw dev 可以确认。另外还要注意，如果这张网卡有多个虚拟接口（比如 system wlan0 和 managed wlan0 同时存在），切换时可能会有干扰，建议先把多余接口删掉。

Wireshark 在 Linux 下选择这个 monitor 接口就能开始抓包。Windows 下的替代方案是用支持 promiscuous 模式的 USB 网卡配合 Npcap 驱动，但效果和稳定性都不如 Linux 下原生 Monitor 模式。

这里有必要强调一下边界：整个观察实验必须在你自己拥有或明确授权的无线环境中进行，只抓取自己的 AP 和自己终端发出的帧。空口抓包能力本身是中性的网络诊断工具，但如果把它用在未授权的网络上，性质就完全变了。我在实验全程都只开了自己的实验室 AP，这一点非常重要。

3.2 从 Beacon 帧里读出的关键字段

启动抓包后，先找到一个属于自己的 Beacon 帧。Wireshark 里可以用一个显示过滤器直接筛选：

这个是 Beacon 帧对应的数值。点击任意一条 Beacon，展开 IEEE 802.11 Beacon frame，重点看几个字段：

Tagged parameters 里的 DS Parameter Set，直接标识当前信道号。例如值 6 表示 2.4GHz 信道 6，值 36 表示 5GHz 主信道 36。

HT Capabilities 和 VHT Capabilities 里能看到是否启用 40MHz、80MHz、160MHz。VHT 字段中包含 Supported Channel Width，如果值为 160 MHz，说明 AP 宣告支持 160MHz。

HE Capabilities 是 802.11ax 的特征字段，里面能看到 HE Support，以及是否声明支持 80MHz 以内的 OFDMA 多用户资源调度、是否支持 TWT（目标唤醒时间）省电机制。我实验中的 AP 抓包结果里，这些字段都正常，但终端侧的 Probe Request 才真正暴露了问题。

用同样的方法过滤 Probe Request：

展开客户端发出的 Probe Request，找到 HE Capabilities 里的 HE PHY Capabilities Information。里面有 8 个 bit 位代表对 80MHz、160MHz、80+80MHz 的支持情况。如果这里就显示不支持 160MHz，那无论 AP 多强，最终协商也不会出现 160MHz。我这次实验里，Windows 下 AX201 驱动安装失败后，Linux 下用同一个网卡抓到的 Probe Request 里，160MHz 支持位是“未知”，这就说明问题出在固件/驱动还没有正确加载。

3.3 验证协商过程与吞吐：以 160MHz 频宽为观察窗口

协议抓包只能看到“宣告的能力”，真正要确认协商结果，最好结合 netsh wlan show interfaces 或 Linux 下的 iw dev wlan0 link。

在 Linux 下关联自己的 AP 后，执行：

输出里会有 tx bitrate: 1200.0 MBit/s 这类信息，这是当前协商到的物理层速率。假设一个 2x2 MIMO 的 Wi-Fi 6 客户端，在 80MHz 下最大协商速率就是 1200Mbps，提高不了的直接原因就是带宽还是 80MHz。再配合抓包时看到的 Beacon 帧频宽声明，就能快速定位到底是 AP 端没开 160MHz，还是客户端协商失败。

再说吞吐。链路速率不等于实际速率，我实测下来，80MHz 2x2 的 802.11ax 链路，在无干扰环境下用 iperf3 TCP 上传大概能跑 600-800Mbps，实际效果受终端功耗策略、AP 转发性能、驱动实现质量影响非常大。想要稳定复现测试，建议用网线连接一个 iperf3 服务端，再让被测终端无线连接，多次取平均：

跑完后看 Retr 列的重传计数，如果稳定超过 5 次每秒，基本可以确定无线链路存在问题。

4. 故障实录：Intel Wi-Fi 6 AX201 160MHz 安装失败的排查过程

4.1 故障现象与初步定位

同事这台笔记本重装 Windows 11 后，无线网卡设备在设备管理器里长时间处于黄色感叹号状态，属性显示错误代码 10，也就是“设备无法启动”。有时候重启后能恢复，但每次恢复时间不稳定，而且网络连接速度只有 144Mbps，明显停留在 2.4GHz 20MHz 水平。

我的第一步不是急着装驱动，而是先确认硬件身份。在弹出的设备属性窗口里，选择“详细信息”，属性列表选“硬件 ID”，看到类似 PCI\VEN_8086&DEV_51F0 的字符串。这里 VEN_8086 是 Intel 的厂商号，DEV_51F0 是 AX201 无线网卡常见的设备号。如果看到的是 DEV_2723，那大概率是 AX200，两者外观相似但接口和配套芯片组完全不同。

AX201 是 CNVi 接口，必须搭配 Intel 400 系列及以上芯片组使用；AX200 走的是通用 PCIe 接口，兼容范围广得多。 这块卡安装失败，第一个要排除的就是接口不匹配问题。

4.2 驱动与固件层面的排查顺序

确认硬件身份无误后，我按下面的顺序做了一遍排查，顺序很重要，别跳步：

1. 查看 Windows 事件日志。Win+R 打开事件查看器，系统日志里过滤 Kernel-PnP 来源，找到设备启动失败事件，里面会给出失败状态代码。状态代码 0xC0000071 这种，往往指向驱动文件缺失。

2. 彻底清除旧的驱动残留。Windows 重装后最容易被忽略的是旧驱动的残留信息。设备管理器里先选择“卸载设备”，勾选“尝试删除此设备的驱动程序”。然后打开管理员命令提示符执行：

找到所有和 Intel 无线有关的 OEM 驱动包后，用 pnputil /delete-driver oemXX.inf /uninstall 清理。这一步能解决很多“装新驱动后还是老版本生效”的玄学问题。

3. 从 Intel 官方渠道获取正确驱动。注意不要使用所谓的“万能网卡驱动”第三方打包工具，这类工具经常把针对特定平台优化的驱动强行套到另一套硬件上，装完就报代码 10。Intel 官网的驱动包型号区分很清楚，AX201 用对应 / WiFi-6 的驱动版本，安装前先确认驱动包里的 Netwtw6e.sys 文件版本号和操作系统位宽一致。

4. 检查 BIOS 里的无线设备状态。有些笔记本的 BIOS 里有单独的 WLAN 开关，重装系统后默认会被禁掉。进 BIOS 后找 Wireless LAN、WLAN 等相关项，确认状态为 Enabled。另外，把 BIOS 更新到最新版本再重试，这一步对 CNVi 网卡的稳定性帮助极大。

5. Windows 侧驱动安装成功后，进入 Linux 环境用 dmesg 验证固件加载情况。我用的命令是：

正常加载时能看到 iwlwifi 0000:00:14.3: loaded firmware version ... op_mode iwlmvm 这样的日志。如果日志停在 firmware not found，说明 /lib/firmware 目录下缺少对应固件文件，可以手动将固件文件复制进去并执行 update-initramfs -u 刷新。

4.3 代码 56 与协商速率异常的合理解释

除了代码 10，AX201 还会出现代码 56（设备卡在错误配置状态），通常和 BIOS 中预留的 CNVi 资源冲突有关。遇到代码 56，我建议先重置 BIOS 到出厂设定，再手动关闭 PCIe ASPM（电源管理）相关选项。原因是 CNVi 网卡依赖芯片组提供的专用连接，电源管理策略过于激进时，设备无法完成重新初始化。

至于 160MHz 协商不到，我在实验里发现还有一个非常隐蔽的原因：很多路由器默认开启“国家/地区自动选择”，这会限制 5GHz 末段高频信道的可用性。如果 AP 自动切换到一个带有 DFS 标记的信道，又检测到干扰，AP 会立刻缩小频宽，客户端只会默默接受新的协商结果。这时候抓包能看到 AP 发送了 Channel Switch Announcement 帧。用户层面看到的现象就是“之前还能 160MHz，重启就没了”，解决方案其实很简单：把 AP 固定在一个非 DFS 信道上尝试 160MHz，比如 36+40+44+48 组成的 160MHz 段，但要注意附近是否有多运营商基站等干扰源。

5. 观察实验中的高频误判与避坑心得

5.1 常见问题速查表

下面的表格是我这次实验过程中整理出来的，以后遇到类似无线问题可以直接对照看。

5.2 三条独家经验

先说“筛选参考标准”的问题。我在调试时习惯用 Wireshark 的着色规则把 Beacon、Probe Request、数据重传帧分别标记出来，这样在长时抓包里一眼就能扫到异常波动。如果你不经常用 Wireshark，可以在显示过滤里先保存常用过滤器，比如只显示数据帧：

或者只显示关联过程帧：

第二条经验是关于基线数据的。无线环境每时每刻都在变化，单次抓包只能代表当时的情况。我给自己的要求是在目标位置至少连续测 3 轮，早中晚各一次，记录 RSSI、协商速率、重传率三个核心数值的波动范围，再下结论。很多“时好时坏”的问题，单看某一时刻的数据会发现一切正常，但把三天数据摊开，能看到周期性干扰源。

第三条经验是关于 160MHz 频宽的取舍。实验做下来，我个人的真实感受是：160MHz 确实能带来更高的极限吞吐，但在居住密集区域，它的实际收益不一定比自己降到 80MHz 更稳。160MHz 需要占据 5GHz 中大半个可用频谱，任何一个辅信道上有干扰，整个链路都会回退，回退过程还会产生短暂卡顿。如果你不想牺牲可靠性去追求低频宽下的高参数，建议直接把 AP 固定到 80MHz，换来的稳定性和延迟表现往往更好。

6. 实验复盘与最后一句话

一周的观察实验结束后，我对 802.11 无线局域网（Wi-Fi）的感受可以浓缩成一句话：标准给的是能力上限，链路协商给的是现实交点，而用户体验最终取决于最短板的那一跳。没有必要因为某个参数上不去就怀疑硬件损坏，也不要一看到驱动报错就反复重装浪费大量时间。

如果你也想复现这套实验，我给两个建议。第一，准备一台支持 Monitor 模式的备用网卡，不需要特别贵，市面上常见的 USB 外接网卡就足够，注意芯片型号别太冷门，否则固件和驱动会让你吃不少苦头。第二，抓包工具就用 Wireshark 加 Npcap 的组合，配合 Linux 环境下的 iw 命令，这一套够你用很久。

实际跑完一遍，你会发现很多所谓的“玄学无线问题”在协议面前没有任何秘密。Beacon 帧里的能力集、Probe 交互里的协商过程、重传帧的密度、AP 的信道切换通告，这些信号早就把答案写在了空口里，只是我们平时没有把它当成可观察的对象而已。