GL.iNet GL-BE3600 与 Intel BE200 无法协商到 802.11be 的排查记录

一、问题背景

测试环境如下：

• 路由器：GL.iNet GL-BE3600

• 固件版本：GL.iNet 4.10.0

• 无线网卡：Intel Wi-Fi 7 BE200 320MHz

• 网卡驱动：23.150.0.4

• 客户端系统：Windows

• 测试网络：

  • 普通 5GHz SSID：GL-5G
  • MLO SSID：GL-MLO

问题表现是：

虽然路由器和 BE200 均标称支持 Wi-Fi 7，Windows 也能够识别 GL-MLO 的多链路信息，但连接状态始终显示：

无线电类型：802.11ax

而不是预期的：

802.11be

因此，本次排查重点是确认问题究竟出在：

1. 路由器区域限制；
2. 无线驱动能力；
3. hostapd 配置；
4. MLO 配置；
5. Intel BE200 驱动；
6. Qualcomm QSDK 与 Intel 网卡的兼容性。

二、首先排除国家区域限制

GL-BE3600 原始 ART 校准分区中的国家代码是中国区域。由于不同区域对 Wi-Fi 7、160MHz、6GHz、发射功率和 DFS 的限制不同，因此首先将 ART 中的国家代码由 CN 修改为 US。

修改后执行：

iw reg get

能够看到 Qualcomm 无线 PHY 已经应用：

country US: DFS-FCC

这说明驱动实际采用了美国 FCC 规则，而不是仅在 OpenWrt 配置层修改了国家代码。

因此可以排除：

因国家码仍然是 CN，导致 802.11be 被完全禁用。

但需要说明，修改 ART 分区存在风险，错误写入可能导致无线校准信息损坏，因此不应在没有备份的情况下重复操作。

三、确认路由器无线驱动支持 EHT

随后查看无线 PHY 能力。

执行：

iw phy1 info

结果显示 Qualcomm 无线驱动在 AP 和 Managed 模式下均包含完整 EHT 能力，包括：

• EHT MAC Capabilities
• EHT PHY Capabilities
• EHT MCS/NSS
• 160MHz EHT 能力
• AP 模式 802.11be 支持

内核日志同样明确出现：

ol_ath_update_ext_eht_caps: 11be 5G supported case

并加载了多个 EHT MCS/NSS 映射。

这说明：

GL-BE3600 的 Qualcomm 芯片、驱动和固件底层确实具备 802.11be/EHT 能力。

因此问题不是“硬件不支持 Wi-Fi 7”。

四、确认 hostapd 已启用 802.11be

检查运行时生成的 hostapd 配置：

grep -Ei "ieee80211be|eht|mlo|ieee80211ax|op_class" \
/var/run/hostapd-wlan12.conf

得到：

ieee80211ax=1
ieee80211be=1
eht_oper_chwidth=2
eht_oper_centr_freq_seg0_idx=auto
ssid=GL-MLO

这说明 hostapd 配置层已经明确启用：

ieee80211be=1

其中：

eht_oper_chwidth=2

表示 EHT 运行信道宽度已配置到对应的宽信道模式，当前 5GHz 实际运行在 160MHz。

因此可以排除：

OpenWrt 或 hostapd 配置中没有开启 Wi-Fi 7。

五、确认 Qualcomm 固件确实初始化了 EHT 和 MLO

启动日志里出现了多个关键记录。

首先，Qualcomm 固件检测到 2.4GHz 和 5GHz 均支持 11be：

ol_ath_update_ext_eht_caps: 11be 2G supported case
ol_ath_update_ext_eht_caps: 11be 5G supported case

随后，两个无线芯片分别注册为 MLO Link 0 和 Link 1：

mlo_setup_link_ready
mld link 0
mld link 1
Valid link bitmap 3

系统最终识别：

Num MLO Links: 2

并且 hostapd 向内核提交了两个 MLO Link：

wlan_cfg80211_start_ap: Num links from user space: 2
mlme_mlo_validate_partnerinfo: Num MLO Links: 2

这证明：

GL-MLO 并不是普通的双频同名 SSID，而是 Qualcomm 驱动实际建立的两链路 MLO AP。

六、发现 mlo_config.ini 缺失

日志启动阶段出现：

Could not find firmware /lib/firmware/mlo_config.ini
Failed to read file mlo_config.ini
Set default MLO config

随后系统使用默认 MLO 配置继续启动，并成功建立两个 Link。

这意味着：

• mlo_config.ini 缺失没有导致 MLO 完全失效；
• Qualcomm 驱动会回退到默认配置；
• 但默认参数是否和 Intel BE200 完全兼容，不能确定。

日志中还出现：

Couldn't register handler for link switch WMI event 11

这可能表示部分动态链路切换事件没有成功注册。它不一定阻止基本 MLO 建链，但可能影响：

• 多链路切换；
• 双链路并发；
• MLO 调度；
• Qualcomm 与 Intel 客户端的兼容性。

因此，mlo_config.ini 缺失是一个值得注意的固件完整性问题，但目前没有证据证明它是唯一根因。

七、Windows 和 Intel BE200 的能力确认

Windows WLAN Report 显示 Intel BE200 驱动明确支持：

802.11b
802.11g
802.11n
802.11a
802.11ac
802.11ax
802.11be

驱动版本为：

23.150.0.4

驱动日期为：

2025-06-12

报告还显示 BE200 支持最多 4 个 MLO 连接。

因此可以排除：

Windows 当前驱动完全不支持 Wi-Fi 7 或 MLO。

八、Windows 确实识别到了 MLO 网络

连接 GL-MLO 后，Windows 显示：

AP BSSID: 0e:dc:ed:46:bb:55
Colocated APs: 1
MldID: 0
LinkID: 1
BSSID: c2:25:ec:60:ec:ba
波段: 5 GHz
信道: 36

其中：

• 主连接落在 2.4GHz 信道 11；
• Windows 同时识别到 5GHz 信道 36 的合作链路；
• 存在 MldID 和 LinkID；
• 说明 AP 广播中包含足够的 Multi-Link 信息。

这一点非常重要。

它说明：

Intel BE200 不仅看到了两个同名 SSID，而且已经把它们识别成同一个 MLD 下的两个 Link。

也就是说，MLO 的发现阶段是成功的。

九、实际连接仍然退回到 802.11ax

尽管 Windows 识别到了 MLO，实际无线电类型仍然是：

802.11ax

当前连接信息显示：

波段：2.4 GHz
信道：11
无线电类型：802.11ax
接收速率：287 Mbps
传输速率：244 Mbps

这说明本次连接并不是单纯的显示问题。

因为如果只是 Windows 界面没有更新：

• 路由器侧通常仍应将客户端标记为 EHT；

• 连接速率和链路属性也应体现 EHT；

• 但此前 ubus call hostapd.wlan1 get_clients 中客户端只有：

  • ht: true
  • vht: true
  • he: true

• 没有观察到明确的：

  • eht: true

因此更合理的解释是：

Windows 能识别 AP 的 MLO拓扑，但实际关联时，客户端和 AP 最终只协商到了 HE，也就是 802.11ax。

十、为什么 AP 自身扫描不到 GL-MLO

尝试执行：

iw dev wlan1 scan ap-force
iw dev wlan1 scan

并筛选：

SSID: GL-MLO

结果没有任何输出。

这并不能证明 AP 没有广播 EHT。

原因是：

• wlan1 本身正在作为 AP 接口运行；
• Qualcomm QSDK 驱动通常不会让工作中的 AP 接口扫描并返回自身 Beacon；
• 某些驱动甚至不支持 AP 接口主动扫描；
• 因此无法通过本机 AP 接口抓取自身的 Beacon 内容。

要真正检查 Beacon 中是否包含：

• EHT Capabilities
• EHT Operation
• Multi-Link Element

需要使用：

1. 第三台支持监听模式的无线设备；
2. Wireshark 抓取 Beacon；
3. 独立 Linux 无线网卡运行 monitor mode；
4. 专业无线分析工具。

十一、排查过程中出现的其他现象

Windows WLAN Report 中还出现多次：

关联时驱动程序已断开连接

尤其在连接 GL-5G 时，曾多次发生关联失败。

同时也出现：

网络被驱动程序断开连接

这些现象表明 Intel 驱动与当前 AP 配置之间可能存在关联阶段的不稳定，尤其是在：

• Wi-Fi 7；
• WPA3-SAE H2E；
• 160MHz；
• MLO；
• Qualcomm QSDK 私有实现；

多种特性同时启用时。

不过最终客户端能够连接并正常获得网络，因此这不是完全无法关联，而更像是能力协商或重试过程中发生了降级。

综合分析

目前已经排除的因素包括：

因此，问题已经不再是简单的“没有打开 Wi-Fi 7”。

真正的问题发生在：

客户端关联和能力协商阶段。

AP 能力、MLO拓扑和 EHT 配置都已经存在，但 Intel BE200 与 Qualcomm QSDK 最终没有完成 EHT 关联，而是退回到 HE。

最终结论

GL-BE3600 当前已经正确开启了 802.11be 和 MLO，路由器端的硬件、驱动、国家码及 hostapd 配置基本正常。

Intel BE200 也具备 802.11be 和 MLO 能力，并且 Windows 已经识别出 GL-MLO 的 MldID、LinkID 和 5GHz合作链路。

但是，从 Windows 实际连接结果和路由器客户端状态来看：

BE200 最终仍然按 802.11ax/HE 方式完成关联，没有真正协商到 802.11be/EHT。

最可能的根因是：

1. GL.iNet 4.10.0 所使用的 Qualcomm QSDK 与 Intel BE200 存在 EHT/MLO 互操作兼容问题；
2. 固件缺少 /lib/firmware/mlo_config.ini，使用默认 MLO 配置，可能导致部分链路或协商参数不完整；
3. Intel BE200 驱动在 2.4GHz+5GHz MLO、WPA3-SAE H2E 和 160MHz组合下发生能力降级；
4. 较小概率是 AP Beacon 中虽然包含 Multi-Link Element，但 EHT Capability或EHT Operation字段不完整。

因此，目前最准确的结论不是“路由器不支持 Wi-Fi 7”，也不是“Windows 只是显示错误”，而是：

路由器已启用 Wi-Fi 7，客户端也识别到了 MLO，但双方在实际关联阶段没有完成 EHT协商，最终降级为 Wi-Fi 6/802.11ax连接。

在没有外部抓包确认 Beacon 和 Association Request/Response 之前，无法百分之百判断是 AP 拒绝了 EHT，还是 Intel 客户端没有提交完整 EHT Capability。但综合现有证据，问题更偏向 GL.iNet Qualcomm QSDK 固件与 Intel BE200 的兼容性或固件实现问题，而不是用户配置错误。

折腾一下午没整明白，看有没有懂的大佬，文章根据AI对话总结生成。