Red Hat Bugzilla – Bug 388471
REGRESSION: NM doesn't connect to WPAE/TTLS/PAP network
Last modified: 2008-01-23 11:03:38 EST
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):
I just try to connect to the enterprise network via the nm-applet, but it
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.
It doesn't connect but asks again for the login data.
It should connect without asking again.
A workaround is to call wpa_supplicant directly with this config file:
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]
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:
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]
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:
(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
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
One thing I wonder about though is that when I use NetworkManager I get these
<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
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:
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
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!