Description of problem: The new NetworkManager version of Fedora 8 does not connect to an enterprise WPA network with ttls/pap support anymore. This still works with wpa-supplicant though. It also worked with the F7 version of NM. A /var/log/messsages output of a session is attached. Version-Release number of selected component (if applicable): NetworkManager-0.7.0-0.5.svn3030.fc8 How reproducible: I just try to connect to the enterprise network via the nm-applet, but it fails. Steps to Reproduce: 1.Open the nm-applet, enter the data. 2.Wait for NM to connect. 3.See the message that it queries for the login data. Actual results: It doesn't connect but asks again for the login data. Expected results: It should connect without asking again. Additional info: A workaround is to call wpa_supplicant directly with this config file: network={ ssid="802.1X" proto=WPA key_mgmt=WPA-EAP pairwise=TKIP group=TKIP eap=TTLS anonymous_identity="anonymous" identity="user" password="*******" ca_cert="/etc/cert/cacert.pem" phase2="auth=PAP" priority=1 } In case you wonder, this network is part of the http://en.wikipedia.org/wiki/Eduroam project. Therefore it is a pretty important login method for European users.
Created attachment 262341 [details] /var/log/messages output
priority and severity to medium since it makes it impossible for average computer users to connect to WLAN university networks in Europe.
I have a very similar problem---I'm using the University of Amsterdam's wireless, but I could just as well be using Eduroam instead. The relevant part of my wpa_supplicant.conf looks like this: network={ ssid="uva" scan_ssid=1 key_mgmt=IEEE8021X eap=TTLS identity="user" password="**********" ca_cert="/etc/pki/uva/SURFnet-PCA-Root-CA.crt" phase2="auth=PAP" } This works for me every time when I: 1) Stop NetworkManager and NetworkManagerDispatcher. 2) iwconfig wlan0 up 3) iwconfig wlan0 essid uva 4) Restart wpa_supplicant. 5) Start dhclient. but NetworkManager fails to get an IP address (and also seems never to remember any of the configuration information, like where the key is) every time.
Created attachment 265991 [details] /var/log/messages
Check bug #323371, the issue may be related. In either case, there is a new NetworkManager you could try: 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'
Joel; is your network using hidden SSIDs, and if so, what driver and card do you have? There are some problem with iwlwifi (3945 and 4965) with hidden SSIDs and dynamic WEP. Also, what kernel version do you have? Further, can you please list the versions of the kernel, NetworkManager, and wpa_supplicant RPMs that you have installed as well. Thanks!
Here's what I'm using, presently: NetworkManager-0.7.0-0.6.6.svn3109.fc8 kernel-2.6.23.8-63.fc8 wpa_supplicant-0.5.7-16.fc8 (I've upgraded all three since the first time I posted on this bug.) My office network isn't using hidden SSIDs. The 'uva' SSID shows up in NetworkManager plain as day. The wireless card is an Intel 3945, and the driver is iwl3945. I'm passing the options '-iwlan0 -Dwext' to wpa_supplicant when it starts. So, the newer version of NetworkManager mentioned in <a href="#6">comment 6</a> didn't help me.
BTW, one thing about NetworkManager got worse with version NetworkManager-0.7.0-0.6.6.svn3109.fc8 for me: The file chooser for the CA certificate is broken now. When the dialog pops up asking me for the authentication type, my username and password, etc., and I hit the button to select the certificate file, no files show up in the dialog box. I suspect that the problem is related to the file filter showing up as "Untitled filter" and their being no other file filter to select. If I type in the filename myself, I get it, though. I'll see about reporting that as a separate bug...
Ok, the bug I mentioned in comment #8 has been reported as bug #410201.
I tested the newest version, and the problem is still there, I cannot connect using NetworkManager. Used versions: 2.6.23.1-49.fc8 NetworkManager-0.7.0-0.6.6.svn3109.fc8 wpa_supplicant-0.5.7-17.fc8 One thing I wonder about though is that when I use NetworkManager I get these lines: <info> Config: added 'proto' value 'WPA RSN WPA RSN' <info> Config: added 'pairwise' value 'TKIP CCMP TKIP CCMP' <info> Config: added 'group' value 'WEP40 WEP104 TKIP CCMP WEP40 WEP104 TKIP CCMP' Why is the third line having all values twice? And why can't I specify the other values (like WPA and TKIP)? Is there anything I can do to increas the debug output of a running NetworkManager session? How can I pass any options to the wpa-supplicant which is started by NetworkManager?
NetworkManager starts up wpa_supplicant on its own--there should be no need or desire to start it up manually with 'service wpa_supplicant start' or automatically by 'chkconfig wpa_supplicant on'. The arguments as configured in /etc/sysconfig/wpa_supplicant are not used when NetworkManager launches wpa_supplicant via D-BUS. Instead, the following file is used to set the arguments: /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service However, you DO NOT want to be passing in -i interface or -D driver options since those parameters should be passed by D-BUS. The default parameters should be fine. They are: -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f Also, the config file should be left at the default, which contains just these lines: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel BTW, there is a wpa_supplicant-0.5.7-17.fc8, although I don't think it makes any changes that matter here. Can you try again after making these changes? /sbin/chkconfig wpa_supplicant off /sbin/service wpa_supplicant stop /sbin/service NetworkManager restart
In reply to Comment #10, you can add -ddd arguments to the dbus file I mentioned in Comment #11 for debugging. Note that this will cause your /var/log/wpa_supplicant.log to grow large rather quickly. As to why the proto, pairwise, and group values are always duplicated, they are specified this way by NM and set in the gconf settings this way. I don't know why this was done, but it should do no harm. WPA is TKIP and WPA2 is CCMP.
The duped values are a bug in NM but as you correctly point out, they are harmless. There are still bigger fish to fry rather than fixing that particular problem, even though I know where it is and mostly how to go about fixing it...
I did as Comment #11 advised, but this made no difference that I could see. I still get NetworkManager stuck in a loop, where it keeps asking me for "Wireless network Secrets" without ever completing the connection.
Created attachment 277181 [details] The wpa_supplicant log generated by using NetworkManager As mentioned in Comment #112 I added -ddd to the dbus file and tried to associate again. The generated output is attached. I wonder if the problem could be due to a authentication time out - is there any way to extend the authentication time to some larger value?
WRT the auth timeout, no, because if you're not connected in 30 seconds, you aren't going to be, or your connection is so crappy that you're going to have a lot of other problems. Besides, the ASSOCIATING state is just between the card and the AP. That should happen very quickly. The EAP exchanges, _after_ the card has associated, are the parts that might take a longer time. If the card doesn't get to ASSOCIATED within 5 seconds there's clearly something wrong in the driver or the configuration.
(In reply to comment #16) > WRT the auth timeout, no, because if you're not connected in 30 seconds, you > aren't going to be, or your connection is so crappy that you're going to have > a lot of other problems. I'd like to be the one to make that decision. IMNSHO it is simply wrong to deny users that choice.
As of upgrading to NetworkManager-0.7.0-0.6.7.svn3204.fc8, this problem disappeared for me. NetworkManager now detects and connects to the wireless network in my office (an EDUROAM network) very quickly.
The same is true to me: I installed the updates and it works now with the configuration used here in the EDUROAM network. Perfect! I close the bug. Thanks for everyone helping out and/or confirming the bug!