Bug 399631 - NetworkManager can't assoc/auth with network; wpa_supplicant/wpa_gui can
Summary: NetworkManager can't assoc/auth with network; wpa_supplicant/wpa_gui can
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 8
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-26 16:29 UTC by Phil Mayers
Modified: 2008-10-20 14:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-10-20 14:43:00 UTC
Type: ---

Attachments (Terms of Use)
basic wpa_supplicant config that does work (271 bytes, application/octet-stream)
2007-11-26 16:29 UTC, Phil Mayers
no flags Details
/var/log/messages for a failing attempt (8.56 KB, text/plain)
2007-11-26 16:36 UTC, Phil Mayers
no flags Details
/var/log/wpa_supplicant.log for a (different) failing attempt (2.98 KB, text/plain)
2007-11-26 16:42 UTC, Phil Mayers
no flags Details
Errors from trying to load an encrypted private key into wpa_supplicant (694 bytes, text/plain)
2007-12-04 22:42 UTC, John Guthrie
no flags Details
As requested, "gconftool-2 --dump /system/networking/connections" output (24.26 KB, text/xml)
2007-12-06 12:07 UTC, Phil Mayers
no flags Details

Description Phil Mayers 2007-11-26 16:29:14 UTC
Description of problem:

NetworkManager seems never to be able to associate with our (large)
WPA-Enterprise wireless network. I unplug the cable, select the WPA SSID from
the list, select TTLS+MSCHAPv2 and enter the info; NetworkManager goes away and
eventually times out.

However, wpa_supplicant can connect to the same network with a minimal config,
including when wpa_gui is used to prompt for username/password info.

Hardware is HP 2510p laptop with intel 4965 wireless

Version-Release number of selected component (if applicable):


How reproducible:

Always (i.e. it can never connect)

Steps to Reproduce:
1. Unplug wired ethernet
2. Select "Imperial-WPA" SSID from list
3. Enter WPA settings (TTLS, inner MSCHAPv2)
4. Wait about a minute
Actual results:


Expected results:

Associates, authenticates and gets an IP

Additional info:

Please see following attachment for the simple wpa_supplicant config that *does*

Comment 1 Phil Mayers 2007-11-26 16:29:14 UTC
Created attachment 269041 [details]
basic wpa_supplicant config that does work

Comment 2 Phil Mayers 2007-11-26 16:36:45 UTC
Created attachment 269051 [details]
/var/log/messages for a failing attempt

Comment 3 Phil Mayers 2007-11-26 16:42:04 UTC
Created attachment 269061 [details]
/var/log/wpa_supplicant.log for a (different) failing attempt

I see messages saying:

OpenSSL: Failed to load private key
TLS: Failed to load private key '(null)'
TLS: Failed to set TLS connection parameters
EAP-TTLS: Failed to initialize SSL.

...private key? TTLS should not need one.

Comment 4 Phil Mayers 2007-11-26 17:14:44 UTC
If I install:


...and use "(None)" as the CA certificate, it seems to work (However: that SVN
version of NM seems to have a crash-bug in nm-applet - when choosing "(None)"
and clicking through the "It's insecure without CAs!" if you leave "Don't notify
me again" UNCHECKED the applet segfaults)

Comment 5 Phil Mayers 2007-11-26 17:30:38 UTC
Actually, scratch that. It does not work reliably.

Comment 6 Dan Williams 2007-12-03 15:23:20 UTC
Don't you need an identity + password for your TTLS config?  Or did you remove
that for privacy reasons?

Comment 7 Phil Mayers 2007-12-03 15:26:05 UTC
I was submitting the identity & password with wpa_gui i.e. via the
wpa_supplicant control socket; which works fine.

It also works if I put the identity/password in the config file directly.

Comment 8 Dan Williams 2007-12-03 16:56:07 UTC
Are you using ap_scan options in the config, and is your SSID hidden at all?

Comment 9 Phil Mayers 2007-12-03 17:04:58 UTC
The wpa_supplicant.conf was exactly as specified, so the ap_scan was whatever
the default is.

The SSID is not hidden; however the AP *is* a multiple-broadcast-SSID one (Cisco
heavyweight). The reason I mention this is we've seen certain supplicants have
problems with this in the past.

Comment 10 Dan Williams 2007-12-03 17:24:13 UTC
yeah, that's good to know.  Does the AP use the _same_ BSSID for multiple SSIDs?
 Or does it use different BSSIDs for each SSID?  Or, is it the case of one
broadcast SSID for the BSSID plus one hidden SSID for the same BSSID?

Comment 11 Phil Mayers 2007-12-03 17:37:58 UTC
2nd option i.e. different BSSID for each SSID, all of which are broadcast

Comment 12 Phil Mayers 2007-12-04 15:08:45 UTC
Koji build 0.7.0 Release 0.6.5.svn3096.fc8 seems to significantly improve
matters i.e. I can actually connect, get an IP and walk around using the network

Comment 13 Phil Mayers 2007-12-04 16:59:35 UTC
Bah. Once again, it stops working. It was definitely an improvement though.

FYI - it would be reasonable but incorrect to assume local wireless/radio
conditions are behind it; however I have colleagues with the same model of
laptop about 10 feed away running both XP and Vista (and opposite me running
MacOS X) who remain connected to the wireless.

I am beginning to wonder if it's an iwl4xxx driver/firmware issue.

Also - note that using "no CA cert" with PEAP (added in the svn version, as
above) and clicking "ignore" causes a segfault. This works with TTLS.

Comment 14 John Guthrie 2007-12-04 19:33:35 UTC
I am having similar problems in my setup.  I am using Cisco 1231 APs with
multiple SSIDs.  Each SSID has its own BSSID, and all SSIDs are broadcast.  I
could not get anything to come up with NetworkManager.  I could, however get
things to come up manually with wpa_supplicant, provided that I used SSL private
keys that did not have an encryption key on them.  Every time that I try to get
wpa_supplicant to connect with a encrypted private key, I get one of those "TLS:
Failed to load private key" errors.  Of course, NetworkManager is now forcing
you to use encrypted private keys, so this makes for a slight problem in that

I have tried encrypted keys in multiple formats including PKCS#8, traditional
PEM, etc.  This is happening with the latest wpa_supplicant from Fedora,
1:0.5.7-16.fc8 as well as the latest NetworkManager, 1:0.7.0-0.6.6.svn3109.fc8.

Comment 15 Dan Williams 2007-12-04 19:36:39 UTC
John: can you paste the top bits from your PEM formatted private key?  ie, the
bits like this:

Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,5FA2D6D6242C26D0

Comment 16 John Guthrie 2007-12-04 22:42:10 UTC
Created attachment 277451 [details]
Errors from trying to load an encrypted private key into wpa_supplicant

Here is the private key header:

Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,DC59A57164B32D4D

Also, I am adding a small attachment with the precise error message that I get
when I try to use this key.  I get this same error message when I try use the
same key PKCS8 PEM-encoded format and PKCS8 DER-encoded format as well.

Comment 17 Dan Williams 2007-12-04 22:54:11 UTC
John: can you post the RPM version of wpa_supplicant you are running as returned

rpm -q wpa_supplicant


Comment 18 John Guthrie 2007-12-05 02:20:33 UTC
rpm -q wpa_supplicant returns:


By the way, I decided to see if this problem was a result of the type of
encryption that I was using for the private key.  Here is another header of a
private key that is having the same problem.  This time though, I used 3DES
instead of DES:

Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C99C537AEE381916

Comment 19 Phil Mayers 2007-12-06 11:20:09 UTC
Ok, some more info.

The following are the syslog messages from the Cisco AP. The first two lines are
a failing attempt to associate with NetworkManager. The 3rd line is a succeeding
attempt with wpa_supplicant directly:

sh-wap-4-5.net.ic.ac.uk Dec  6 111510.162 UTC %DOT11-6-ASSOC Interface
Dot11Radio0, Station   0013.e8c1.f8f9 Associated KEY_MGMT[NONE]
sh-wap-4-5.net.ic.ac.uk Dec  6 111523.909 UTC %DOT11-6-ASSOC Interface
Dot11Radio0, Station   0013.e8c1.f8f9 Associated KEY_MGMT[NONE]
sh-wap-4-3.net.ic.ac.uk Dec  6 111721.774 UTC %DOT11-6-ASSOC Interface
Dot11Radio0, Station   0013.e8c1.f8f9 Associated KEY_MGMT[WPAv2]

Note the different key management.

Is there some debugging I could do which will narrow the problem down?

Comment 20 Dan Williams 2007-12-06 11:44:07 UTC
Nope; I think I see the issue.  NM for whatever reason isn't passing the phase2
method to wpa_supplicant, which in your case is MSCHAPv2, and that's causing
wpa_supplicant to think that it should use certificates with TLS because TLS is
likely the defualt phase2 auth method.

One question though; can you do the following and _email_ me the output?  It
shouldn't expose any private keys or passwords at all:

gconftool-2 --dump /system/networking/connections


Comment 21 Phil Mayers 2007-12-06 12:07:10 UTC
Created attachment 279661 [details]
As requested, "gconftool-2 --dump /system/networking/connections" output

Comment 22 John Guthrie 2007-12-07 01:52:53 UTC
While we are on the topic of log files, when I check the logs on my AP, I'm not
seeing any different types of key management, rather all I see there is stuff
like the following:

Dec  1 00:17:05.489 EST: %DOT11-6-ASSOC: Interface Dot11Radio0, Station  
0013.02b3.1d76 Reassociated KEY_MGMT[WPAv2]
Dec  1 00:18:15.386 EST: %DOT11-6-DISASSOC: Interface Dot11Radio0,
Deauthenticating Station 0013.02b3.1d76 Reason: Previous authentication no
longer valid
Dec  1 00:18:15.650 EST: %DOT11-4-MAXRETRIES: Packet to client 0013.02b3.1d76
reached max retries, removing the client

Where I do see a difference however, is in my RADIUS logs:

Sat Dec  1 00:15:32 2007 : Auth: Login incorrect:
[guthrie.org] (from client guthrie-ap port 1662 cli
Sat Dec  1 00:16:02 2007 : Auth: Login OK: [guthrie.org]
(from client guthrie-ap port 1663 cli 0013.02b3.1d76)

The first one is from using an encrypted private key.  The second one is from
switching back to an unencrypted private key.  (Although, I don't know if this
is terribly surprising.)  I guess it does indicate that wpa_supplicant is trying
to send something even though it can't open the private key correctly.

On a different note, Phil, apparently when you create an attachment, that does
*not* automatically make the NEEDINFO status revert back to ASSIGNED.  (That is
as opposed to just making a comment.  I found this out with one of my
attachments above.)  I would change it for you, but I wasn't certain what the
edicate in that situation would be.

Comment 23 John Guthrie 2007-12-09 21:52:41 UTC

I believe that Phil provided the requested info above.  It is in an attachment
which does not seem to update the NEEDINFO status.  (Is this a bugzilla bug, and
is there a bug number for it?)

In the absense of any other action, I am checking the box that says, "I am
providing the requested information for this bug."  (Which I'm trying to do
indirectly by pointer. ;-)

Comment 24 John Guthrie 2007-12-09 22:01:22 UTC
(In reply to comment #23)
> (Is this a bugzilla bug, and
> is there a bug number for it?)

This is OT, but the answer is Bug #213941.

Comment 25 Dan Williams 2008-10-20 14:43:00 UTC
Is this still an issue with latest kernel, NM, and supplicant?  If so, please reopen.

Tested successfully against freeradius,  Cisco 1131 with WPA/WPA2 EAP-TTLS MSCHAP-v2 phase2, with kernel (ipw2200), wpa_supplicant-0.5.10-6.fc8, NM 0.7.0-0.11.svn4022.4.fc8.

Comment 26 Phil Mayers 2008-10-20 14:51:10 UTC
I've since upgraded to Fedora 9 where (with current updates) everything is working fine. I've no idea if things are working in F8, though I assume so.

Apologies for not closing the BugZilla myself.

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