Bug 388471
Summary: | REGRESSION: NM doesn't connect to WPAE/TTLS/PAP network | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Roland Wolters <roland.wolters> | ||||||||
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 8 | CC: | cra, dcbw, dominik, uckelman, wtogami | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | 0.7.0-0.6.7.svn3204.fc8 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-01-23 16:03:38 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Roland Wolters
2007-11-17 16:40:15 UTC
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! |