GNOME Bugzilla – Bug 464215
Support WEXT scan capabilties
Last modified: 2008-01-11 16:48:04 UTC
Please describe the problem: When the AP hides the ESSID of a WPA wireless network, NM is not able ever to successfully connect. When the ESSID is unhidden, then it connects no problem. One can manually associate using wpa_supplicant. Steps to reproduce: 1. hide an ESSID using WPA 2. try to associate to the wireless net using NM 3. see? Actual results: no association Expected results: association to the AP and wireless netowrk Does this happen every time? yes Other information: a fellow on NetworkManager list has a detailed description of the problem and a suggested patch ... I will ask for his permission to post it here.
Created attachment 93194 [details] [review] proposed patch (should at least be reviewed) I've been experimenting a bit tonight and this is what I've found. AP_SCAN 2 : ESSID is set on the wireless device, but it never associates. Presumably because it cannot find the AP. AP_SCAN 1: ESSID does NOT get set on the wireless device, so does not work alone - during the device setup phase, if you issue an "iwconfig wlan0 essid whatever", the device will associate fine. So I made a patch to incorporate the two and to prove a point. :) Please note, that this patch is intended to prove that the association to hidden IS possible, even with ipw4965 devices. The patch changes the AP_SCAN value for hidden networks and I have no clue as to what that will do for other wireless devices. Also, since I've not gotten acquainted to very much of the NetworkManager code, there might be better places to put some of these things. So it should at the very least be reviewed by someone more familiar with the NM code than myself. This patch has also been posted on the NetworkManager development mailinglist for comments. There are people there who are experiencing the same problem.
It might be important to note that this is not related to EAP, but more general to WPA and iwl4965 devices connecting to hidden networks.
I have exactly the same problem with iwl3945 .. any update on this?
So the problem with switching to ap_scan=1 is that this completely breaks other drivers. Drivers need to support at _least_ ap_scan=2, which is the fallback, but ideally support ap_scan=1 + scan_ssid=1 as well. Unfortunately, it appears that iwlwifi doesn't work with ap_scan=2 which is a driver bug. The driver should probably be sending out a probe request to the specified SSID if it can't find that SSID in the internal scan list anyway (libertas and others do this). The point here is that all the ap_scan stuff really sucks and drivers vary in their implementation. But the basic functionality that all drivers need to support is ap_scan=2. ap_scan=1 + scan_ssid=1 is an _optimization_ of the ap_scan=2 case. Drivers need to get fixed here to work with wpa_supplicant and ap_scan=2. That said, thanks for the patch and trying to debug this further... :) I really, really hate ap_scan and it's caused no end of trouble with both wpa_supplicant and NetworkManager, since people keep insisting on using hidden SSIDs.
*** Bug 465187 has been marked as a duplicate of this bug. ***
Note that the _correct_ fix for this issue is for drivers to report what scan capabilities they have. I've submitted a patch to the kernel that provides this capability, and NM will check this and do the right thing with AP_SCAN when the driver reports it correctly. This does mean that madwifi will have to update their driver for it to work correctly with NetworkManager. The hack that most people have used so far is to special case things based on the HAL-reported driver name, which is just so wrong it's not funny. Once 2.6.24 is released and a new wireless-tools shows up with the userland support for scan capabilities, I'll add the necessary bits to NetworkManager.
*** Bug 421980 has been marked as a duplicate of this bug. ***
fixed on stable and trunk, provided you have a kernel and drivers with the right bits.
Thanks a lot! Any version numbers too look out for, for kerlen, wpa_supplicant, NM etc?
What a bunch of typos... Hope you understand the meaning, though. For one - kerlen should have been kernel. I guess my keyboard is having a meltdown :-p Anyways - Sorry 'bout that!
You shouldn't need a different version of wpa_supplicant. Any NetworkManager SVN version later than and including r3235 should work here. The kernel patch isn't in Linus kernels yet (but is in wireless-2.6 and slated for 2.6.25 I think) but Fedora 2.6.23 testing kernels have it, for example. I'd encourage you to open bugs to get the patch backported to whatever distro kernels you are using.
Thanks - I'm on Fedora myself, so I'll check out the Fedora testing kernels to find out which one has the right bits. Thanks again!
I've been testing with 2.6.23.13-104.fc8 myself on an iwl4965. I think there are also F-7 testing kernels that have the patch as well.