Hide Forgot
Description of problem: NetworkManager seems never to be able to associate with our (large) WPA-Enterprise wireless network. I unplug the cable, select the WPA SSID from the list, select TTLS+MSCHAPv2 and enter the info; NetworkManager goes away and eventually times out. However, wpa_supplicant can connect to the same network with a minimal config, including when wpa_gui is used to prompt for username/password info. Hardware is HP 2510p laptop with intel 4965 wireless Version-Release number of selected component (if applicable): wpa_supplicant-0.5.7-16.fc8 NetworkManager-0.7.0-0.5.svn3030.fc8 iwl4965-firmware-4.44.1.18-2 kernel-2.6.23.1-49.fc8 How reproducible: Always (i.e. it can never connect) Steps to Reproduce: 1. Unplug wired ethernet 2. Select "Imperial-WPA" SSID from list 3. Enter WPA settings (TTLS, inner MSCHAPv2) 4. Wait about a minute Actual results: Fails Expected results: Associates, authenticates and gets an IP Additional info: Please see following attachment for the simple wpa_supplicant config that *does* work
Created attachment 269041 [details] basic wpa_supplicant config that does work
Created attachment 269051 [details] /var/log/messages for a failing attempt
Created attachment 269061 [details] /var/log/wpa_supplicant.log for a (different) failing attempt I see messages saying: OpenSSL: Failed to load private key TLS: Failed to load private key '(null)' TLS: Failed to set TLS connection parameters EAP-TTLS: Failed to initialize SSL. ...private key? TTLS should not need one.
If I install: NetworkManager-0.7.0-0.6.5.svn3096.fc8 ...and use "(None)" as the CA certificate, it seems to work (However: that SVN version of NM seems to have a crash-bug in nm-applet - when choosing "(None)" and clicking through the "It's insecure without CAs!" if you leave "Don't notify me again" UNCHECKED the applet segfaults)
Actually, scratch that. It does not work reliably.
Don't you need an identity + password for your TTLS config? Or did you remove that for privacy reasons?
I was submitting the identity & password with wpa_gui i.e. via the wpa_supplicant control socket; which works fine. It also works if I put the identity/password in the config file directly.
Are you using ap_scan options in the config, and is your SSID hidden at all?
The wpa_supplicant.conf was exactly as specified, so the ap_scan was whatever the default is. The SSID is not hidden; however the AP *is* a multiple-broadcast-SSID one (Cisco heavyweight). The reason I mention this is we've seen certain supplicants have problems with this in the past.
yeah, that's good to know. Does the AP use the _same_ BSSID for multiple SSIDs? Or does it use different BSSIDs for each SSID? Or, is it the case of one broadcast SSID for the BSSID plus one hidden SSID for the same BSSID?
2nd option i.e. different BSSID for each SSID, all of which are broadcast
Koji build 0.7.0 Release 0.6.5.svn3096.fc8 seems to significantly improve matters i.e. I can actually connect, get an IP and walk around using the network now.
Bah. Once again, it stops working. It was definitely an improvement though. FYI - it would be reasonable but incorrect to assume local wireless/radio conditions are behind it; however I have colleagues with the same model of laptop about 10 feed away running both XP and Vista (and opposite me running MacOS X) who remain connected to the wireless. I am beginning to wonder if it's an iwl4xxx driver/firmware issue. Also - note that using "no CA cert" with PEAP (added in the svn version, as above) and clicking "ignore" causes a segfault. This works with TTLS.
I am having similar problems in my setup. I am using Cisco 1231 APs with multiple SSIDs. Each SSID has its own BSSID, and all SSIDs are broadcast. I could not get anything to come up with NetworkManager. I could, however get things to come up manually with wpa_supplicant, provided that I used SSL private keys that did not have an encryption key on them. Every time that I try to get wpa_supplicant to connect with a encrypted private key, I get one of those "TLS: Failed to load private key" errors. Of course, NetworkManager is now forcing you to use encrypted private keys, so this makes for a slight problem in that respect. I have tried encrypted keys in multiple formats including PKCS#8, traditional PEM, etc. This is happening with the latest wpa_supplicant from Fedora, 1:0.5.7-16.fc8 as well as the latest NetworkManager, 1:0.7.0-0.6.6.svn3109.fc8.
John: can you paste the top bits from your PEM formatted private key? ie, the bits like this: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,5FA2D6D6242C26D0
Created attachment 277451 [details] Errors from trying to load an encrypted private key into wpa_supplicant Here is the private key header: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-CBC,DC59A57164B32D4D Also, I am adding a small attachment with the precise error message that I get when I try to use this key. I get this same error message when I try use the same key PKCS8 PEM-encoded format and PKCS8 DER-encoded format as well.
John: can you post the RPM version of wpa_supplicant you are running as returned from: rpm -q wpa_supplicant Thanks.
rpm -q wpa_supplicant returns: wpa_supplicant-0.5.7-16.fc8 By the way, I decided to see if this problem was a result of the type of encryption that I was using for the private key. Here is another header of a private key that is having the same problem. This time though, I used 3DES instead of DES: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,C99C537AEE381916
Ok, some more info. The following are the syslog messages from the Cisco AP. The first two lines are a failing attempt to associate with NetworkManager. The 3rd line is a succeeding attempt with wpa_supplicant directly: sh-wap-4-5.net.ic.ac.uk Dec 6 111510.162 UTC %DOT11-6-ASSOC Interface Dot11Radio0, Station 0013.e8c1.f8f9 Associated KEY_MGMT[NONE] sh-wap-4-5.net.ic.ac.uk Dec 6 111523.909 UTC %DOT11-6-ASSOC Interface Dot11Radio0, Station 0013.e8c1.f8f9 Associated KEY_MGMT[NONE] sh-wap-4-3.net.ic.ac.uk Dec 6 111721.774 UTC %DOT11-6-ASSOC Interface Dot11Radio0, Station 0013.e8c1.f8f9 Associated KEY_MGMT[WPAv2] Note the different key management. Is there some debugging I could do which will narrow the problem down?
Nope; I think I see the issue. NM for whatever reason isn't passing the phase2 method to wpa_supplicant, which in your case is MSCHAPv2, and that's causing wpa_supplicant to think that it should use certificates with TLS because TLS is likely the defualt phase2 auth method. One question though; can you do the following and _email_ me the output? It shouldn't expose any private keys or passwords at all: gconftool-2 --dump /system/networking/connections Thanks.
Created attachment 279661 [details] As requested, "gconftool-2 --dump /system/networking/connections" output
While we are on the topic of log files, when I check the logs on my AP, I'm not seeing any different types of key management, rather all I see there is stuff like the following: Dec 1 00:17:05.489 EST: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0013.02b3.1d76 Reassociated KEY_MGMT[WPAv2] Dec 1 00:18:15.386 EST: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0013.02b3.1d76 Reason: Previous authentication no longer valid Dec 1 00:18:15.650 EST: %DOT11-4-MAXRETRIES: Packet to client 0013.02b3.1d76 reached max retries, removing the client Where I do see a difference however, is in my RADIUS logs: Sat Dec 1 00:15:32 2007 : Auth: Login incorrect: [guthrie.org] (from client guthrie-ap port 1662 cli 0013.02b3.1d76) Sat Dec 1 00:16:02 2007 : Auth: Login OK: [guthrie.org] (from client guthrie-ap port 1663 cli 0013.02b3.1d76) The first one is from using an encrypted private key. The second one is from switching back to an unencrypted private key. (Although, I don't know if this is terribly surprising.) I guess it does indicate that wpa_supplicant is trying to send something even though it can't open the private key correctly. On a different note, Phil, apparently when you create an attachment, that does *not* automatically make the NEEDINFO status revert back to ASSIGNED. (That is as opposed to just making a comment. I found this out with one of my attachments above.) I would change it for you, but I wasn't certain what the edicate in that situation would be.
Dan, I believe that Phil provided the requested info above. It is in an attachment which does not seem to update the NEEDINFO status. (Is this a bugzilla bug, and is there a bug number for it?) In the absense of any other action, I am checking the box that says, "I am providing the requested information for this bug." (Which I'm trying to do indirectly by pointer. ;-)
(In reply to comment #23) > (Is this a bugzilla bug, and > is there a bug number for it?) This is OT, but the answer is Bug #213941.
Is this still an issue with latest kernel, NM, and supplicant? If so, please reopen. Tested successfully against freeradius, Cisco 1131 with WPA/WPA2 EAP-TTLS MSCHAP-v2 phase2, with kernel 2.6.26.5-28.fc8 (ipw2200), wpa_supplicant-0.5.10-6.fc8, NM 0.7.0-0.11.svn4022.4.fc8.
I've since upgraded to Fedora 9 where (with current updates) everything is working fine. I've no idea if things are working in F8, though I assume so. Apologies for not closing the BugZilla myself.