室内 Wi-Fi 漫游优化：基于 OpenWRT 的深度实践解读

背景

在将家庭网络全面迁移至 OpenWRT 系统并部署 Cudy AX3000 接入点（AP）数月后，作者重新审视了一个此前被刻意忽略的问题：Wi-Fi 漫游体验。

尽管作者已经升级了 5GHz 频段并调整了 AP 的物理位置，但在实际居住环境中，混合设备（包括手机、平板、笔记本以及坚持使用旧协议的 IoT 设备）带来的连接问题逐渐显现。这些问题起初并不明显，但随着网络拓扑的变化，信号覆盖的“粗糙点”开始暴露。

作者的网络架构采取了一种“硬隔离”策略：

• 2.4GHz 网络：保留为兼容旧设备的 WPA2 网络，主要服务于 IoT 设备和老旧客户端。
• 5GHz 网络：面向现代客户端，采用更安全的 WPA3/SAE 协议。
• 回程连接：通过四个“哑”AP 实现 2.5GbE 有线回程。
• 管理方式：零云管理、零厂商专有软件，完全去中心化。

然而，这种架构导致了一个核心痛点：当用户在屋内移动时，iPhone、iPad 和 MacBook 等苹果设备往往拒绝切换 AP，死死连接着信号微弱的旧节点。由于公寓结构复杂（围绕电梯井分布，厨房等区域存在瓷砖、管道及冰箱等射频干扰），这种“粘滞客户端”现象尤为严重。

核心内容

1. 初始困境与诊断

作者最初启用了基于 802.11r/k/v 的快速漫游选项，并安装了 wpad-mbedtls 以支持 Mesh 功能。日志中确实出现了 auth_alg=ft 条目，表明快速转换（Fast Transition, FT）机制在运行。但实际体验表明，漫游效果依然不佳。

问题在于：

• 缺乏引导机制：客户端完全自主决定漫游，导致它们倾向于保持与远距离 AP 的连接，直到信号质量变得极差。
• 邻居报告缺失：虽然启用了 802.11k，但 hostapd 并未向客户端暴露邻居报告（Neighbour Reports）。rrm_nr_list 在每个无线接口上均为空，意味着客户端无法获知周围有哪些可用的 AP，从而无法做出明智的切换决策。
• 跨频段漫游局限：由于 2.4GHz 和 5GHz 使用不同的 SSID 和安全设置，跨频段漫游被视为客户端的责任（而许多客户端在此方面表现不佳）。因此，优化重点必须放在同一频段/SSID 内部的漫游引导上。

2. 解决方案：引入 usteer 与静态邻居报告

为了解决上述问题，作者引入了两个关键组件：usteer 和 static-neighbor-reports。

第一步：安装 usteer usteer 是一个用于 Wi-Fi 漫游引导的守护进程。作者在所有四个 AP 上执行了以下操作：

opkg update
opkg install usteer luci-app-usteer
/etc/init.d/usteer enable
/etc/init.d/usteer restart

默认配置仅启用 LAN 内广播、Syslog 调试，并禁用了 IPv6（出于对 ISP 路由器稳定性的不信任）。这使得所有 AP 能够互相感知并交换客户端数据。

第二步：解决 802.11k 邻居报告缺失 尽管 usteer 已运行，但 hostapd 仍无法生成有效的邻居列表。作者发现缺失的关键包是 static-neighbor-reports。

• 原理：每个 AP 可以通过 ubus call hostapd.<iface> rrm_nr_get_own 生成自身的邻居报告元素。但客户端要获得有用的列表，必须知道其他 AP 的存在。
• 实施：安装 static-neighbor-reports 并启用服务。
• 频段隔离：报告是频段特定的。2.4GHz 无线电仅广播 2.4GHz 的邻居，5GHz 无线电仅广播 5GHz 的邻居。这符合作者“不同频段不同 SSID”的设计初衷，避免了跨频段混淆。

实施后，每个无线接口上每个 AP 都能看到三个邻居，usteer 掌握了 AP/客户端状态，而 hostapd 则向请求的客户端提供明确的 802.11k 邻居数据。

3. 效果验证

作者通过 Graphite 数据进行了前后对比分析：

• 2.4GHz 频段：变化不大。该频段依然拥挤、嘈杂，受邻居干扰严重。部分 AP 信号略有改善，部分变差，但整体拥堵状况未发生根本性改变，这符合预期。
• 5GHz 频段：
  • 活跃度分布：数据显示客户端在 AP 之间的使用分布发生了明显转移，更符合实际的物理位置逻辑。
  • 粘滞客户端消除：这是最关键的指标。虽然弱信号客户端（-75dBm 以下）并未完全消失，但极弱信号客户端（约 -90dBm）的粘滞连接消失了。这表明客户端不再死守旧 AP，而是成功漫游到了信号更好的新节点。

4. 潜在风险与后续监控

作者保持谨慎态度，指出单次采样并非科学结论，Wi-Fi 环境充满不确定性。部署后出现了一次 Fast Transition 日志错误：FT: Missing required pairwise in pull response from a peer AP。虽然仅发生一次，不足以判定配置失败，但鉴于 SAE 和 FT 机制的复杂性，作者选择信任日志而非假设，并计划通过本地 Gitea 实例存储的稳定配置和 LLM 辅助生成的监控脚本，持续进行长期观察。

关键要点

• SSID 分离策略：对于混合了老旧 IoT 设备和现代智能设备的家庭网络，将 2.4GHz（WPA2/兼容模式）与 5GHz（WPA3/高性能模式）分离是更务实的选择，而非盲目追求单一 SSID。
• 漫游不仅是协议支持：仅启用 802.11r/k/v 并不足以保证良好的漫游体验。如果接入点不向客户端提供邻居信息，客户端将无法做出最优切换决策。
• usteer 的核心作用：usteer 作为漫游引导守护进程，能够协调 AP 间的客户端状态，防止客户端“粘滞”在信号差的节点上。
• 静态邻居报告的重要性：在 OpenWRT 环境中，static-neighbor-reports 包是解决 hostapd 不自动生成邻居列表的关键，它确保了客户端能获取准确的周边 AP 信息。
• 频段特异性配置：邻居报告必须按频段隔离配置，避免将 2.4GHz 和 5GHz 的邻居信息混淆，特别是在使用不同 SSID 和安全策略的网络中。
• 去中心化与可观测性：作者推崇无云管理、无厂商锁定的纯 OpenWRT 方案，配合 collectd/Graphite 监控和 SSH 调试，确保了网络异常时的可排查性和透明度。

意义与影响

这篇实践记录为家庭网络高级用户和小型企业网络管理员提供了一份极具参考价值的技术蓝图。它揭示了在去中心化、高性能 Wi-Fi 部署中，“连接”与“漫游”是两个不同的维度。

1. 技术启示：许多用户误以为开启 802.11k/r/v 就能解决漫游问题，但本文证明，缺乏有效的邻居报告（Neighbour Reports）和漫游引导（Steering Daemon），这些协议只是空转。usteer 和 static-neighbor-reports 的组合填补了这一关键空白。
2. 架构哲学：在追求现代协议（WPA3）的同时，必须兼顾遗留设备（IoT）的兼容性。通过频段隔离而非简单的 SSID 统一，可以在不牺牲安全性的前提下，最大化网络的整体可用性。
3. 可维护性价值：在云管理日益普及的今天，本文强调了本地控制、日志驱动和透明监控的重要性。当网络出现“怪异”行为时，拥有底层