Bugzilla – Bug 178210
NetworkManager doesn't authenticate with WPA
Last modified: 2006-06-02 16:01:57 UTC
I'm trying to connect to WLAN router configured with WPA and passphraze. NetworkManager detects the network, but does not authenticate. Using plain wpa_supplicant directly works without problems. I have bcm43xx, I use ndiswrapper, KDE UI. This is my functional wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant network={ ssid="Rebel" scan_ssid=1 key_mgmt=WPA-PSK psk="********" } Successful run: bash# wpa_supplicant -Dndiswrapper -iwlan0 -c/etc/wpa_supplicant.conf Trying to associate with 00:11:d8:ea:ee:b4 (SSID='Rebel' freq=2437 MHz) Associated with 00:11:d8:ea:ee:b4 WPA: Key negotiation completed with 00:11:d8:ea:ee:b4 [PTK=TKIP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:11:d8:ea:ee:b4 completed (auth) After that just dhcpcd wlan0 and I'm running over that right now.
Created attachment 84874 [details] /var/log/NetworkManager NM log file, any further info needed?
BTW in the course of testing NM died with this message in the log: NetworkManager: file nm-device-802-11-wireless.c: line 1985 (ap_need_key): assertion failed: (security) Everything is in the attached log, is it worth a separate report?
Michal: Is your accesspoint (Rebel) hidden? jg: Association is timing out, card is a broadcom. I thought we fixed these with the ndiswrapper version bump. Is this configuration supported?
AP is not hidden, it broadcasts its essid if you mean that. It's on stock SL10.1 btw: ndiswrapper-1.10-19 wpa_supplicant-0.4.8-14 NetworkManager-0.6.2-23 NetworkManager-kde-0.1r534534-4
I don't think anything related to ndiswrapper is supported at all, it's simply a binary only crap, just bcm43xx is so common unfortunately :-( Anyways, the point is that it works with a plain wpa_supplicant, but not with wpa_supplicant which is run from NM. So there must be something strange in between.
You are using WPA-PSK, that means you need to specify the ciphers to use in that case. Would be a good idea if NetworkManaged forced the user to select a ciphe when it is going to use AP_SCAN 2. In that particular case (b'casted SSID) AP_SCAN 2 shouldn't be necessary (that's why your manual wpa_supplicant run worked), but that's another story.
Sorry, but I don't consider this as working. Either NM has to ask for a cipher or (preferably) shouldn't require AP_SCAN 2 whatever it is.
jg: Could we get away with using "AP_SCAN 2" only if the network is not broadcasting?
In that case, yes, this should do the trick. However, if the use of AP_SCAN 2 is unavoidable, it would be still a good idea imho to let the user choose the ciphers, and maybe explain why, but I guess that's something for 10.2 resp. SP1.
jg: So you are confirming that changing the logic from if ndiswrapper then use "AP_SCAN 2" to if ndiswrapper && hidden then use "AP_SCAN 2" is should be okay? I'll commit it. Also - we do let the user select the cipher, but when selecting from the scan list we obviously go with automatic. When doing a manual connect, the user can select TKIP, CCMP, or Automatic.
Yes, the change should be safe.
Great, I'll make the change, test, and submit.
Perfect, thanks. You could let me know when an updated package is ready, I'd give it a try.
Submitted to autobuild. Michal, packages for SLES10 are available here: http://primates.ximian.com/~rml/misc/NetworkManager/ Sorry, I don't have a 10.1 machine on which to build. These fix the problem, as now NM can automatically determine the cipher type.
*** Bug 164394 has been marked as a duplicate of this bug. ***
Submitted. Marking as FIXED.
I will test it, thanks. I suppose it doesn't need NetworkManager-kde update.
Works OK now, thanks.