Bug 388471 - REGRESSION: NM doesn't connect to WPAE/TTLS/PAP network
Summary: REGRESSION: NM doesn't connect to WPAE/TTLS/PAP network
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-17 16:40 UTC by Roland Wolters
Modified: 2008-01-23 16:03 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2008-01-23 16:03:38 UTC

Attachments (Terms of Use)
/var/log/messages output (9.97 KB, text/plain)
2007-11-17 16:40 UTC, Roland Wolters
no flags Details
/var/log/messages (12.16 KB, application/octet-stream)
2007-11-21 13:49 UTC, Joel Uckelman
no flags Details
The wpa_supplicant log generated by using NetworkManager (7.60 KB, text/plain)
2007-12-04 17:36 UTC, Roland Wolters
no flags Details

Description Roland Wolters 2007-11-17 16:40:15 UTC
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):

How reproducible:
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.
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:
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.

Comment 1 Roland Wolters 2007-11-17 16:40:15 UTC
Created attachment 262341 [details]
/var/log/messages output

Comment 2 Roland Wolters 2007-11-17 16:41:31 UTC
priority and severity to medium since it makes it impossible for average 
computer users to connect to WLAN university networks in Europe.

Comment 3 Joel Uckelman 2007-11-21 13:42:02 UTC
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.

Comment 4 Joel Uckelman 2007-11-21 13:49:43 UTC
Created attachment 265991 [details]

Comment 5 Charles R. Anderson 2007-11-29 04:29:52 UTC
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'

Comment 6 Dan Williams 2007-12-03 17:02:04 UTC
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!

Comment 7 Joel Uckelman 2007-12-04 11:28:06 UTC
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.

Comment 8 Joel Uckelman 2007-12-04 11:43:06 UTC
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...

Comment 9 Joel Uckelman 2007-12-04 11:53:36 UTC
Ok, the bug I mentioned in comment #8 has been reported as bug #410201.

Comment 10 Roland Wolters 2007-12-04 14:54:53 UTC
I tested the newest version, and the problem is still there, I cannot connect 
using NetworkManager.
Used versions:

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?

Comment 11 Charles R. Anderson 2007-12-04 14:55:55 UTC
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

Comment 12 Charles R. Anderson 2007-12-04 15:00:39 UTC
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.

Comment 13 Dan Williams 2007-12-04 15:14:25 UTC
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...

Comment 14 Joel Uckelman 2007-12-04 15:41:39 UTC
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.

Comment 15 Roland Wolters 2007-12-04 17:36:55 UTC
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?

Comment 16 Dan Williams 2007-12-04 17:45:32 UTC
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.

Comment 17 Dominik 'Rathann' Mierzejewski 2008-01-17 12:48:51 UTC
(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.

Comment 18 Joel Uckelman 2008-01-23 11:18:21 UTC
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.

Comment 19 Roland Wolters 2008-01-23 16:03:38 UTC
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!

Note You need to log in before you can comment on or make changes to this bug.