使用 wpa_supplicant 从 Debian 直接将 wifi 客户端连接到基础设施 AP
wpa_cli -iwlan0 add_network
1
wpa_cli -iwlan0 set_network 1 ssid '"myssid"'
OK
wpa_cli -iwlan0 set_network 1 psk '"mypwd"'
OK
wpa_cli -iwlan0 enable_network 1
结果，系统日志中出现奇怪的条目“对驱动程序的关联请求失败”
nl80211：MLME 连接失败：ret=-1（不允许操作）
wlan0：对驱动程序的关联请求失败
SSID和PSK显然是正确的。撕扯我的头发 - 有什么问题吗？其他 ssid 也有同样的问题。
dmesg 输出
brcmfmac：brcmf_c_set_joinpref_default：设置 join_pref 错误（-1） brcmfmac：brcmf_cfg80211_connect：BRCMF_C_SET_SSID 失败（-1）
有想法吗？方向？去哪里看？
更新：问题已解决 它与驱动程序初始化优化的有趣副作用有关。我有一个物理无线适配器，带有两个虚拟接口：客户端（托管）和热点（接入点）。正确的加载顺序是 AP，然后是 Managed（这是另一个问题，不确定它来自哪里）。当两个接口同时启动或彼此足够接近时，后面的接口会尝试重用已加载的设备驱动程序实例，这显然是不可能的（这就是“不允许操作”的来源），因此 wpa_supplicant 是未正确初始化。
解决方案是让AP在早期自动加载，而将托管模式保留为手动模式。然后修改 rc.local（或任何其他后期运行触发器）以启用托管接口。对我来说（sleep 20 || sudo ifup wlan1）&工作完美，所以问题解决了。
话虽如此，我认为需要向 Debian 开票来解决这个问题，因为这显然是操作系统错误。
答案1
它与驱动程序初始化优化的有趣副作用有关。我有一个物理无线适配器，带有两个虚拟接口：客户端（托管）和热点（接入点）。正确的加载顺序是 AP，然后是 Managed（这是另一个问题，不确定它来自哪里）。当两个接口同时启动或彼此足够接近时，后面的接口会尝试重用已加载的设备驱动程序实例，这显然是不可能的（这就是“不允许操作”的来源），因此 wpa_supplicant 是未正确初始化。
解决方案是让AP在早期自动加载，而将托管模式保留为手动模式。然后修改 rc.local（或任何其他后期运行触发器）以启用托管接口。对我来说（sleep 20 || sudo ifup wlan1）&工作完美，所以问题解决了。
话虽如此，我认为需要向 Debian 开票来解决这个问题，因为这显然是操作系统错误。