Bug 399631

Summary: NetworkManager can't assoc/auth with network; wpa_supplicant/wpa_gui can
Product: [Fedora] Fedora Reporter: Phil Mayers <p.mayers>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 8CC: dcbw, mathguthrie, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-20 14:43:00 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 Flags
basic wpa_supplicant config that does work
none
/var/log/messages for a failing attempt
none
/var/log/wpa_supplicant.log for a (different) failing attempt
none
Errors from trying to load an encrypted private key into wpa_supplicant
none
As requested, "gconftool-2 --dump /system/networking/connections" output none

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):

wpa_supplicant-0.5.7-16.fc8
NetworkManager-0.7.0-0.5.svn3030.fc8
iwl4965-firmware-4.44.1.18-2
kernel-2.6.23.1-49.fc8

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:

Fails

Expected results:

Associates, authenticates and gets an IP

Additional info:

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

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:

NetworkManager-0.7.0-0.6.5.svn3096.fc8

...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
now.

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
respect.

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:

-----BEGIN RSA PRIVATE KEY-----
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:

-----BEGIN RSA PRIVATE KEY-----
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
from:

rpm -q wpa_supplicant

Thanks.

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

wpa_supplicant-0.5.7-16.fc8

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:

-----BEGIN RSA PRIVATE KEY-----
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

Thanks.

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
0013.02b3.1d76)
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
Dan,

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 2.6.26.5-28.fc8 (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.