我正在尝试让我的 Linux 可靠地在 AP 之间漫游。目前,我正在使用 iwlwifi - iwd - NetworkManager 组合来管理一切,除了漫游之外,一切都运行良好,我对此很满意。
但我无法得到可靠的漫游体验。
我的笔记本电脑紧贴着远处的 AP(< -80dBm(40MHz 信道))并完全忽略其旁边的 AP(-60dBm,160MHz信道)。连接到“弱 AP”会出现很多传输错误,流量会一次停止几秒钟等等 - 体验非常糟糕,wifi 基本上无法工作。
我还必须提到,我们正在谈论 5/6GHz wifi 网络,因为我知道 2.4GHz 网络在更大规模上存在这个问题,因为 2.4GHz 的覆盖范围比更高频段要远得多。
(不是)棘手的客户问题
此问题发生在多个地点,由不同的网络供应商(Ubiquiti 和 Aruba)提供服务,因此我猜测问题不在于 wifi 网络。正如 @Peregrino69 提到的(谢谢!),此问题的正确名称是棘手的客户端问题常见的解决方案是尝试强制客户端漫游 - 通常通过设置一些 RSSI 阈值,这会使 AP 向客户端发送 DEAUTH 数据包,从而强制客户端重新关联/漫游。
但粘性客户端问题意味着客户端不愿意切换到另一个 AP。从 IWD 的日志中我可以清楚地看到它正在尝试但失败了。这意味着我没有这个问题。
正在调试 IWD?
我下载了源代码并添加了许多调试,以便弄清楚发生了什么以及在哪里发生。我知道 IWD 是 SW 中负责处理漫游的部分,我知道它尝试漫游但失败了。
01| station_roam_scan_notify() Will do scan & prepare for roaming [BSS=AP-FAR-AWAY SSID='xxx'
02| station_roam_scan_notify() |- Candidate [BSS=AP-CLOSE SSID='xxx' FREQ=5180 RANK=589 DBM=-7500 DATARATE=72.0]
03| station_roam_scan_notify() | |- This IS a roaming candidate!
04| station_roam_scan_notify() |- Candidate [BSS=AP-FAR-AWAY SSID='xxx' FREQ=5180 RANK=140 DBM=-8100 DATARATE=17.2]
05| station_roam_scan_notify() | |- SKIPPING: Already connected
06| station_roam_scan_notify() Calling station_transition_start()
07| station_transition_start() Starting roaming process - will try BSS one by one
08| station_transition_start() AP-CLOSE| Trying to roam
09| station_try_next_transition() Trying to roam [IF=36 TGT=AP-CLOSE]
10| station_fast_transition() ft_authenticate() branch taken
11| wiphy_radio_work_insert() Inserting work item 6
12| station_fast_transition() wiphy_radio_work_insert() -> FT / PRIO_CONNECT
13| wiphy_radio_work_insert() Inserting work item 7
14| station_try_next_transition() Trying Fast Transition [SUCCESS]
15| station_transition_start() AP-CLOSE| Successfully started roaming!
16| station_transition_start() Roaming process SUCCESFULLY started!
17| wiphy_radio_work_next() Starting work item 6
18| netdev_mlme_notify() MLME notification Frame TX Status(60)
19| netdev_unicast_notify() Unicast notification Frame(59)
20| netdev_mlme_notify() MLME notification Remain on Channel(55)
21| netdev_mlme_notify() MLME notification Cancel Remain on Channel(56)
22| wiphy_radio_work_done() Work item 6 done
23| wiphy_radio_work_next() Starting work item 0
24| ft_associate() We got new BS but did not auth YET!!
25| station_ft_work_ready() ft_associate(AP-CLOSE) returned -2
26| station_ft_work_ready() Calling station_transition_start() as -ENOENT
27| station_transition_start() Starting roaming process - will try BSS one by one
28| station_transition_start() Roaming process FAILED for all candidate BSS
29| station_roam_failed() 36
30| station_roam_failed() [SIGNAL_LOW=1 AP_DIRECTED=0]
802.11r 遭殃
根据该日志我做出以下假设:
IWL 希望按预期漫游(从 AP-FAR-AWAY 到 AP-CLOSE,这完全合理)
我们正在尝试使用 802.11r (FT) 进行漫游
我们尚未获得 AP-CLOSE 的授权,因为我们尚未从驱动程序收到必要的信息(尚未)
无法关联到新 AP -> FT 漫游失败
我又做了一些测试:我禁用了 802.11r (FT),现在电脑能确实可以漫游,正如我所期望的那样。是的,漫游时会出现(短暂的)中断,因为我们必须对新 AP 进行全面身份验证,但它可以正常工作。
没有什么是容易的
我在 IRC 上联系到了 Denis Kenzior(IWD 的作者之一),他告诉我 FT 确实应该可以正常工作。经过一番挖掘,我们(好吧,Denis)发现罪魁祸首是定时。