Description of problem: NM 0.7 cannot connect to WPA/WPA2-Enterprise secured wireless networks. Version-Release number of selected component (if applicable): 0.7.0-0.3.svn2914.fc8 How reproducible: always Steps to Reproduce: 1. Click on NM applet, notice wireless networks 2. Click on a SSID that requires WPA Enterprise encryption 3. Nothing happens. Actual results: No dialog pops up asking to configure WPA Enterprise settings, such as certificate files, username/password, etc. Expected results: WPA/WPA2 Enterprise needs to work. There must not be a regression from previous Fedora releases in supported Wireless networks. Additional info: I've tried using the included ath5k driver (works fine on open networks) and also madwifi from livna. madwifi worked fine in FC6 connecting to WPA/WPA2 Enterprise networks.
It's not just certificate-based authentication. This will affect all eduroam <http://www.eduroam.org/> users, amongst others. I'm happy to test koji builds if that helps get NM working properly in F8.
Please test with svn3016 from koji; that should support WPA Enterprise networks. I've tested it with WPA-EAP TTLS MSCHAPv2 so far, and will do TLS today just to make sure that certificates work.
It still doesn't work for me. dmesg reports: ipw2200: Failed to send SYSTEM_CONFIG: Already sending a command. (as it did before; sorry if I failed to report that earlier) I hope to be using EAP-{TTLS,PEAP}-MSCHAPv2.
Seems more like a driver problem; What's your configuration? I can try to duplicate here and reproduce. If you could give me the output of 'iwlist <ethX> scan' for your access point that would help a lot. Can you also provide the output of /var/log/messages for the connection attempt? Thanks!
Nothing in /var/log/messages (I put my own markers in just to be sure). The ipw2200 message appears to occur later. The scan is: Cell 07 - Address: 00:14:C2:A3:A0:38 ESSID:"eduroam" Protocol:IEEE 802.11bg Mode:Master Frequency:2.462 GHz (Channel 11) Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Quality=91/100 Signal level=-37 dBm IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : 802.1x IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : TKIP CCMP Authentication Suites (1) : 802.1x Extra: Last beacon: 75ms ago I have a three-year-old Thinkpad X40 2386-H4G with the ipw2200 wireless. The AP is an HP ProCurve Radio Port 230 hooked up to their 'Wireless Edge Services Module', if that helps. It worked OK under F7.
Created attachment 236371 [details] /var/log/messages entry After rebooting (and hence upgrading the kernel from release 23 to 30), behaviour was different. (Previously I merely restarted the NM service.) I got a prompt (for the first time ever under NM 0.7) and it would let me hit 'Connect' till I had filled in the CA (something I must confess to not having done under F7). I gave it a PEM file of our root CA, and attached is what NM 0.7 thinks of it. Is that better?
s/would/wouldn't/
I've identified a number of problems when using certificates that I'm fixing for the next build.
Please retest with svn3020. Note that certificates will likely need to be in DER format, not PEM format. Thanks!
Created attachment 237311 [details] new errors under svn3020 This is what I get under 3020 (without a reboot). Will rebooting and creating a new user, and using the DER cert.
It's the same after rebooting, not allowing access to the keyring (rather than new user) and using the DER CA file. Sorry :-\
Did you force-install NetworkManager? The latest NM requires a newer version of wpa_supplicant, 0.5.7-13. Can you post the output of 'rpm -q wpa_supplicant' ?
I didn't use --force, just 'rpm -Uvh', which didn't complain despite me having wpa_supplicant-0.5.7-10.fc8. I won't be able to test this now till tomorrow, sorry.
Could you attach the output of 'rpm -q --requires NetworkManager' ? Thanks!
Created attachment 237901 [details] --requires output as requested Curious.. (though I had already by then grabbed the updated wpa_supplicant from koji)
Created attachment 237911 [details] correct version :-\
OK. It's now tomorrow, I get into work, open my laptop and get the same problem. After restarting wpa_supplicant, it magically starts working (so that's probably why rebooting helped before). I still don't know why I was allowed to install svn3020 with the old wpa_supplicant, but I'm less worried now. Thank you. It now looks like my password is in my keyring rather than gconf :) If you like, I will try to find another laptop to do a fresh rawhide install on.
If you could do a test with a fresh laptop, that would be awesome. Thanks! Make sure you get wpa_supplicant-0.5.7-13.fc8.
FYI, .4.svn3020 (.3 -> .4 because NM didn't change at all, just the applet) should allow PEM certificates too. Could you test that if you have some PEM versions hanging around? Otherwise you can make them with 'openssl -x509 -in cert.der -inform der -out cert.pem -outform pem' or something like that.
I tried .4.svn3020, wpa_supplicant-0.5.7-13.fc8. Doesn't work. Here are my settings: Wireless Security: WPA & WPA2 Enterprise Authentication: TLS Identity: Wireless User 06-07 User Certificate: Wireless-User.pem (in home dir) CA Certificate: netops-ca.pem (in home dir) Private Key: Wireless-User.pem (in home dir) Private Key Password: <alphanumeric password>
Created attachment 239681 [details] wpa_supplicant-0.5.7-13.fc8 log file with -ddd I added INTERFACES="-ddd" to /etc/sysconfig/wpa_supplicant. This is /var/log/wpa_supplicant.log from WPA Enterprise attempt.
Created attachment 239691 [details] NetworkManager-0.7.0-0.4.svn3020.fc8 log messages NetworkManager messages from /var/log/messages, WPA Enterprise connection attempt with pem certificates.
Also tried on a new user account, same results. BTW, these tests have been using kernel-2.6.23.1-31.fc8 and madwifi-0.9.3.3-1.lvn8.
(In reply to comment #18) > If you could do a test with a fresh laptop, that would be awesome. Thanks! > Make sure you get wpa_supplicant-0.5.7-13.fc8. Yup, tried the rawhide-20071019-i686 live CD. "yum upgrade NetworkManager" offered .5.svn3030 which installed without updating wpa_supplicant, so I'm now more confident my laptop is OK. I then downgraded to .4.svn3020 while upgrading wpa_supplicant to 0.5.7-13.fc8 and couldn't get it to work; I think I need to restart something other than NetworkManager and wpa_supplicant, but rebooting a live CD isn't very helpful ;) However, after installing from the live environment to hard drive and upgrading to .4.svn3020 and 0.5.7-13.fc8 (and rebooting) it works as expected. If I get time I'll look for more data points, and the PEM bits.
Update: manual config in /etc/wpa_supplicant/wpa_supplicant.conf and calling wpa_supplicant manually works with madwifi driver: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="WLAN6-Test" key_mgmt=WPA-EAP pairwise=CCMP TKIP group=CCMP TKIP eap=TLS identity="Wireless User 07-08" ca_cert="/etc/pki/tls/certs/netops-ca.pem" client_cert="/etc/pki/tls/certs/Wireless-User.pem" private_key="/etc/pki/tls/certs/Wireless-User.pem" private_key_passwd="<hidden>" } wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -ddd -K -iath0 I also added "-ddd -K" to /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service for debugging when NM runs wpa_supplicant itself. Right now I'm comparing log files between the two runs to see why NM fails. I did notice that NM sets the gconf keys strangely: group [wep40,wep104,tkip,ccmp,wep40,wep104,tkip,ccmp] pairwise [tkip,ccmp,tkip,ccmp] proto [wpa,rsn,wpa,rsn] Why are these duplicated? I tried deleting all but "tkip,ccmp" for the first two keys since that mirrors what I have configured in the manual wpa_supplicant case, but no dice. BTW, I'm moving the manual wpa_supplicant.conf out of the way and restoring the original when testing with NM.
NM seems to fail to associate to the AP. Here is an excerpt from wpa_supplicant.log while NM is attempting to connect: State: SCANNING -> ASSOCIATING wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) WEXT: Operstate: linkmode=-1, operstate=5 wpa_driver_wext_associate Setting authentication timeout: 15 sec 0 usec EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b06 len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b04 len=12 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b1a len=18 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b19 len=8 Received 1401 bytes of scan results (5 BSSes) Scan results: 5 Selecting BSS from priority group 0 0: 00:0b:0e:0f:99:00 ssid='WPI-Wireless' wpa_ie_len=30 rsn_ie_len=26 caps=0x11 skip - SSID mismatch 1: 00:0b:0e:47:26:41 ssid='WLAN6-Test' wpa_ie_len=30 rsn_ie_len=26 caps=0x11 selected based on RSN IE Already associated with the selected AP. RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag State: ASSOCIATING -> DISCONNECTED Here is the same thing that succeeds when I run wpa_supplicant manually. You can see that it associates and then starts EAPOL: State: SCANNING -> ASSOCIATING wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) WEXT: Operstate: linkmode=-1, operstate=5 wpa_driver_wext_associate Setting authentication timeout: 15 sec 0 usec EAPOL: External notification - portControl=Auto RSN: Ignored PMKID candidate without preauth flag RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b06 len=8 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b04 len=12 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) Wireless event: cmd=0x8b1a len=18 RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP]) Wireless event: cmd=0x8b15 len=20 Wireless event: new AP: 00:0b:0e:47:26:40 State: ASSOCIATING -> ASSOCIATED wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT) WEXT: Operstate: linkmode=-1, operstate=5 Associated to a new BSS: BSSID=00:0b:0e:47:26:40 No keys have been configured - skip key clearing Associated with 00:0b:0e:47:26:40 WPA: Association event - clear replay counter EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state CONNECTING EAPOL: SUPP_BE entering state IDLE EAP: EAP entering state INITIALIZE EAP: maintaining EAP method data for fast reauthentication EAP: EAP entering state IDLE Setting authentication timeout: 10 sec 0 usec Cancelling scan request I don't know why in the NM case it just returns a list of scan results at the point which it should associate to the AP. It seems to get a different wireless event in each case: NM: Wireless event: cmd=0x8b19 len=8 Manual: Wireless event: cmd=0x8b15 len=20
Ok, there are multiple problems happening at once here. madwifi is flaky associating to APs, and ath5k doesn't like to transfer data (i.e. DHCP packets) once associated and authenticated. Those problems aside, NM is simply not passing the certs correctly to wpa_supplicant, or wpa_supplicant isn't reading them correctly. I know this because the authentication phase works fine when running wpa_supplicant manually (with either madwifi or ath5k), but fails with SSL errors when run through NM. If I use ath5k and run wpa_supplicant manually, I can successully associate and authenticate to WPA: Key negotiation completed. If I use ath5k, run NM, and pass separate PEM certs (public, private, CA), it throws SSL errors. If I use ath5k, run NM, and pass DER certs (public/private, CA) it throws SSL errors. The SSL errors end with: OpenSSL: Failed to load private key TLS: Failed to load private key '(null)' TLS: Failed to set TLS connection parameters
Created attachment 242521 [details] wpa_supplicant.log, separate PEM certs, ath5k driver
Created attachment 242531 [details] wpa_supplicant.log, DER certs, ath5k driver
Created attachment 242541 [details] NM messages, separate PEM certs, ath5k driver
Created attachment 242551 [details] NM messages, DER certs, ath5k driver
Created attachment 242561 [details] working manual wpa_supplicant.log, PEM certs, ath5k driver
Created attachment 242571 [details] working manual wpa_supplicant.conf
I was unable to get blob:// syntax in wpa_supplicant.conf to work with PEM user_cert/private_key, but it works with P12 private_key (contains both user_cert and private_key in one file). Unfortunately, P12 isn't supported by nm-applet. Will continue testing with DER certs, but this is looking like it may partially be a wpa_supplicant issue.
So it turns out that when using blobs, you have to decrypt the private key before passing it to OpenSSL. So I need to do a bit more work in the applet to handle that. Until then, configs that use encrypted private keys won't work... it's probably a day or two of work but I don't think it will hit F8 gold, but as an update immediately thereafter.
changing the title to more accurately reflect the problem. Should get fixed in a couple of days but it won't hit F8 gold, which is locked down already.
Should nm-applet be decrypting the private key blob, or should wpa_supplicant be decrypting it like it does when it reads private keys off disk? I vote for the latter, since it makes sense to behave the same way when dealing with files or blobs.
Yes, we want the applet decrypting the private key blob. We don't want to pass the file all the way down to wpa_supplicant, because we don't want wpa_supplicant reading all over the HD. Furthermore, there are configurations where, like NFS, root is denied from reading from NFS stores for security reasons, and in that case the applet would have to decrypt the private key anyway. It's a lot easier to secure wpa_supplicant with stuff like SELinux if it doesn't go around reading random user-specified files from who knows where on the system.
I don't see why wpa_supplicant would be reading files off disk--it can decrypt the blob in memory as passed in by the applet. We already pass the private_key_password, so it already has everything it needs to decrypt it in memory before passing it off to OpenSSL.
wpa_supplicant _can't_ decrypt it in memory. It will only use the private key password when you give it a file, not a blob. This is because OpenSSL expects decrypted private keys when using blobs, and can only decrypt a private key if given a path to a file. wpa_supplicant just passes the file through to OpenSSL and sets the key callback. Therefore, it's useless to pass the private key to wpa_supplicant if you're using blobs. The decryption has to happen before you hit wpa_supplicant.
I have tried rawhide-20071019-i686 live cd, with intel 3945 wireless. I can see nm 0.7 but it doesn't show my wireless connection (it doesn't have any encription). Nm shows a message like "you are disconnected" when gnome starts.
toni2: you'll probably need to try with a later livecd; there was an iwl3945 and iwl4965 initialization bug that caused the device to not show up on boot that was fixed last week.
Yes, fedora 8 rc3 live cd works well with intel 3945 wireless. Dan Williams: Thank you!
NetworkManager-0.7.0-0.6.6.svn3109.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update NetworkManager'
I applied 0.7.0-0.6.6.svn3109.fc8 and all is well in WPA EAP-TLS land. As I mentioned in Comment #27, madwifi is still flakey and refuses to associate to any WPA AP that I tried. However, ath5k works beautifully. ath5k associates, NM/wpa_supplicant completes EAP-TLS authentication, DHCP gets an IP address, and it transfers data. A recent kernel update must have fixed the data transfer/encryption issue with ath5k. Thanks for all the hard work on this!
NetworkManager-0.7.0-0.6.6.svn3109.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
At my work they use WPA-Enterprice with PEAP and TKIP. Networkmamager just doesn't work at all or even give me the option to choose any correct protocol. I tried Ubuntu and SUSE also and they work perfect. Is this known and associated with this bug report? When I used FC7 it connected but worked very poor. Slow and soon disconnected. I use NetworkManager-0.7.0-0.5.svn3030.fc8
@micko: please update to NetworkManager-0.7.0-0.6.6.svn3109.fc8, which as the comment just above your latest comment says, has been pushed to updates to fix this problem. It enabled PEAP functionality.
(In reply to comment #48) Dan, I took it to work today, some new features was showing up, PEAP among others, but I could not choose TKIP. When I tried without it, just with MSCHAPv2, it crashed at once when I was trying to connect. I guess its a bit more to come. I'm sorry, I have no report to send. If you want me to, please send instructions.
One month has passed, some updates came in yesterday but still TKIP dosen't work. I'm I the only Fedora user suffering from this?
Micko: can you do the following and test again? yum update --enable-repo=updates-testing NetworkManager libnl wpa_supplicant and report if that works or not?
I tried today at work, but i could not connect. There are still no possibility to choose TKIP. But NM did not crash anymore when I still tried to connect. Tell me if I can be of help and I'll do my best.
After the last update (from updates-testing) I was able to connect to a eduroam network. It was just after the last update, I tried Monday morning before the update and it always failed. After the update I toggled the wireless button, removed the network cable and voilá the network was up and running. Thanks. :-)
New report from me. NM is working now :-) I tried it today without any modification and to my surprise it just connected fine. I could not choose the TKIP protocol, which is used at my network, but it still worked. So far its working fine, I've been connected now for about 10 minutes.
Report again! No, it did only work for about 10 minutes and then it dissconnected and it was not possible to reconnect again. Same behavior as in FC7 NM. Maybe problems occur when network changes key? Again, this does not happen in UbuntU or SUSE NM. Maybe it could be an idea to have a look how they solved it? Some data from the network: ESSID:"PORT-ADM" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=62/100 Signal level=-70 dBm Noise level=-87 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : 802.1x IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : 802.1x Bit Rates:5.5 Mb/s; 6 Mb/s; 9 Mb/s; 11 Mb/s; 12 Mb/s 18 Mb/s; 24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Extra:tsf=000000126a812018
Hello again! Please let me know if there is any work in progress to fix the NM? I've been waiting now for many months to be able to use Fedora at work. I'm starting to get a bit frustrated. Can you advice me? Is it better to change disto? I just can't figure it out when I see Ubuntu and Suse NM working perfect. Is there a completly new one in Fedora under development causing this? No support for TKIP seems to be the main problem for me.
The issue that I originally opened this bug report for has been fixed for many months. This bug has been closed in December. If you are still having issues, then please open a new bug. Thanks.