This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 432167 - Fails to associate with WPA2/TTLS wifi [NEEDINFO]
Fails to associate with WPA2/TTLS wifi
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
10
All Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: FedoraMini/Mobility
  Show dependency treegraph
 
Reported: 2008-02-09 05:52 EST by Enrico Scholz
Modified: 2009-12-18 01:03 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:03:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
dcbw: needinfo? (rh-bugzilla)


Attachments (Terms of Use)
/var/log/wpa_supplicant.log (26.50 KB, text/plain)
2008-02-09 05:55 EST, Enrico Scholz
no flags Details
NetworkManager log (32.55 KB, text/plain)
2008-11-14 11:21 EST, Dominik 'Rathann' Mierzejewski
no flags Details
a working wpa_supplicant.conf (424 bytes, text/plain)
2008-11-14 11:22 EST, Dominik 'Rathann' Mierzejewski
no flags Details
current NetworkManager log (15.34 KB, text/plain)
2009-02-11 03:45 EST, Dominik 'Rathann' Mierzejewski
no flags Details
wpa_supplicant.log (21.16 KB, application/x-gzip)
2009-02-13 09:26 EST, Dominik 'Rathann' Mierzejewski
no flags Details

  None (edit)
Description Enrico Scholz 2008-02-09 05:52:20 EST
Description of problem:

Having a wpa_supplicant.conf like

| ctrl_interface=/var/run/wpa_supplicant
| 
| network={
|         ssid="..."
|         proto=WPA2
|         key_mgmt=WPA-EAP
|         eap=TTLS
|         anonymous_identity="wifi"
|         identity="sheridan/wifi"
|         password="..."
|         ca_cert="/etc/pki/ensc/chains/server.pem"
|         phase2="auth=PAP"
| }

makes me connect to my wifi network.  Trying to do the same (to avoid
the plaintext password in the configuration file) with NetworkManager
just fails.  Syslog entries are

| Feb  9 11:07:10 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
| Feb  9 11:07:13 sheridan kernel: iwl4965: Error sending REPLY_RXON_ASSOC: Already sending a host command
| Feb  9 11:07:13 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 4
| Feb  9 11:07:13 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0/wireless): connection 'Auto ...' has security, and secrets exist.  No new secrets needed.
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'ssid' value '...'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-EAP'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'password' value '<omitted>'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'eap' value 'TTLS'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'proto' value 'WPA RSN WPA RSN'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'pairwise' value 'TKIP CCMP TKIP CCMP'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'group' value 'WEP40 WEP104 TKIP CCMP WEP40 WEP104 TKIP CCMP'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'fragment_size' value '1300'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'phase2' value 'auth=PAP'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'ca_cert' value 'blob://-org-freedesktop-NetworkManagerSettings-6-ca_cert'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: added 'identity' value 'ensc'
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
| Feb  9 11:07:20 sheridan NetworkManager: <info>  Config: set interface ap_scan to 1
| Feb  9 11:07:20 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 0 -> 2
| Feb  9 11:07:23 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 2 -> 3
| Feb  9 11:07:23 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 3 -> 4
| Feb  9 11:07:45 sheridan NetworkManager: <info>  Activation (wlan0/wireless): association took too long, asking for new key.
| Feb  9 11:07:45 sheridan NetworkManager: <info>  (wlan0) Supplicant interface state change: 4 -> 0

I suspect that authentication takes longer than 25 seconds which seems to be an hardcoded timeout in NetworkManager.


Hardware:
* T61 with
  03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
  03:00.0 0280: 8086:4230 (rev 61)
* Accesspoint: LinkSys WRT54GL with OpenWrt Kamikaze 7.0.9



Btw, NetworkManager has an horrible userinterface. The window which is
popping up does not remember previously entered values for

* anonymous identity
* the CA certificate
* the passphrase

and I have to fill them in again and again for each try.  Pressing
ENTER to start connecting does not work; instead of, I have to use the
mouse to press the CONNECT button.


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

NetworkManager-0.7.0-0.6.7.svn3235.fc8
wpa_supplicant-0.5.7-21.fc8
iwl4965-firmware-4.44.1.20-1


How reproducible:
100%
Comment 1 Enrico Scholz 2008-02-09 05:55:13 EST
Created attachment 294460 [details]
/var/log/wpa_supplicant.log

wpa_supplicant logfile of a successful association (without
NetworkManager).  cmdline options were

| wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -B -K -u -f
-dt -d
Comment 2 Dominik 'Rathann' Mierzejewski 2008-10-20 07:47:40 EDT
Same thing happens to me on rawhide (pre-F10), although admittedly the NetworkManager user interface has improved and remembers the entered values now.
Comment 3 Dominik 'Rathann' Mierzejewski 2008-10-20 07:48:20 EDT
Is there any way to increase NetworkManager timeout values?
Comment 4 Dan Williams 2008-10-20 11:35:42 EDT
Dominik, what exactly is your network configuration, and can you paste in both the logs from /var/log/messages for an NM attempt, and a working wpa_supplicant config file if you can the supplicant to connect after stopping NM like Enrico has done?
Comment 5 Dominik 'Rathann' Mierzejewski 2008-10-31 14:30:39 EDT
Sorry, I've been busy at work and didn't have time to look into this. My network configuration is WPA/TKIP and WPA2/AES (both are supported) with a radius server.
I'll try to get you some logs early next week.
Comment 6 Dominik 'Rathann' Mierzejewski 2008-11-14 11:21:37 EST
Created attachment 323594 [details]
NetworkManager log

Here's my NM log. I made all devices NM-manageable (in ifcfg-* files), stopped network, stopped wpa_supplicant and started NetworkManager.
As you can see, it did succeed to connect for a split second, then disconnected immediately and never succeeded again.
I tried (unsuccessfully) to log in using a certificate in one attempt (hence TLS instead of TTLS for one attempt).

$ rpm -q wpa_supplicant NetworkManager
wpa_supplicant-0.6.4-2.fc10.i386
NetworkManager-0.7.0-0.11.svn4229.fc10.i386
Comment 7 Dominik 'Rathann' Mierzejewski 2008-11-14 11:22:50 EST
Created attachment 323595 [details]
a working wpa_supplicant.conf

And here's a working wpa_supplicant.conf.
Comment 8 Bug Zapper 2008-11-26 04:45:06 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Bug Zapper 2009-01-09 00:57:26 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 10 Dominik 'Rathann' Mierzejewski 2009-01-09 14:10:48 EST
This was reported against F-10 as well.
Comment 11 Dan Williams 2009-02-04 19:11:45 EST
(In reply to comment #7)
> Created an attachment (id=323595) [details]
> a working wpa_supplicant.conf
> 
> And here's a working wpa_supplicant.conf.

Is the eapol_version=2 necessary in your config?

Do recent versions of NetworkManager work better here?
Comment 12 Dominik 'Rathann' Mierzejewski 2009-02-11 03:36:19 EST
(In reply to comment #11)
> (In reply to comment #7)
> > Created an attachment (id=323595) [details] [details]
> > a working wpa_supplicant.conf
> > 
> > And here's a working wpa_supplicant.conf.
> 
> Is the eapol_version=2 necessary in your config?

No, vanilla wpa_supplicant works without it just fine, too.

> Do recent versions of NetworkManager work better here?

No, I'm running NetworkManager-0.7.0-1.git20090102.fc10 and it's still exhibiting the timeout problem.
Comment 13 Dominik 'Rathann' Mierzejewski 2009-02-11 03:45:20 EST
Created attachment 331532 [details]
current NetworkManager log

I've retried with 0.7.0-2.git20090207.fc10 from updates-testing, but there was no change. Fresh log attached.
Comment 14 Dan Williams 2009-02-12 11:28:13 EST
(In reply to comment #13)
> Created an attachment (id=331532) [details]
> current NetworkManager log
> 
> I've retried with 0.7.0-2.git20090207.fc10 from updates-testing, but there was
> no change. Fresh log attached.

Thanks; I notice you're using the ralink drivers, which aren't in-kernel drivers, and thus may not work well.  However, if it's an easy fix maybe we can at least identify the issue.

Nothing looks wrong from the NM side.  Could you:

1) add "-dddt" to the end of the "Exec=" line in /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service

2) killall -TERM wpa_supplicant

3) try to connect to the AP again

4) grab /var/log/wpa_supplicant.conf and attach it to this issue

We need to see what the supplicant is actually doing and if there are errors causing it to fail.  I suspect the driver because out-of-kernel (even -staging) drivers are usually crap when it comes to wpa_supplicant/WEXT compatibility.
Comment 15 Dominik 'Rathann' Mierzejewski 2009-02-13 09:26:19 EST
Created attachment 331829 [details]
wpa_supplicant.log

Yes, I'm using kmod-rt2860 because my wifi chip is not supported by Fedora kernel. I made the changes you requested and here's the result.
Comment 16 Dan Williams 2009-02-13 11:53:28 EST
The EAP failures in that log are apparently due to any number of issues; for example wrong Phase2 authentication (looks like you're using PAP), wrong username or incorrect password.  Are you *sure* the values you've entered into nm-applet's config dialog are correct?  Any idea what EAP method your adminstrators have set up?  Most places usually use MSCHAPv2 or CHAP.
Comment 17 Dominik 'Rathann' Mierzejewski 2009-02-13 13:12:49 EST
I think you wanted my reply (I'm not the reporter, just Cc'd and having the same problem). Yes, I'm sure I've entered the correct authentication credentials. The same setting work fine when entered into /etc/wpa_supplicant/wpa_supplicant.conf with wpa_supplicant called directly. The EAP method is TTLS, as you can see in the working wpa_supplicant.conf file I posted earlier (also, I *am* one of the administrator of this wireless network :)).
Comment 18 Dan Williams 2009-02-13 13:44:10 EST
But are you sure the *inner* (ie, phase2) eap method is allowed to be PAP?
Comment 19 Dominik 'Rathann' Mierzejewski 2009-02-15 08:17:19 EST
(In reply to comment #18)
> But are you sure the *inner* (ie, phase2) eap method is allowed to be PAP?

With TTLS, yes.
Comment 20 Dominik 'Rathann' Mierzejewski 2009-03-23 18:22:58 EDT
*ping*

Is there any reason why you can't simply add an option to configure the association timeout? That seems to be the main reason it fails. IOW: wpa_supplicant often takes over 20s to associate.
Comment 21 Dan Williams 2009-03-23 18:34:39 EDT
Becuase there's no reason it should take that long to associate.  If it does, something is seriously broken with that network.  The issues in the stack and supplicant (if any) that make connections so slow should be *fixed* not hacked around and forgotten about by adding a user-defined connection timeout.

Furthermore, how would anyone know what to put into that field?  There are so many reasons why connections fail that its impossible for you or anyone else to know that a connection timeout would make things work.  So you're stuck in a position of "oh, it failed, maybe I'll just try to increase the connection timeout", without *really* trying to figure out why the darn thing failed in the first place, and fixing that problem.
Comment 22 Dominik 'Rathann' Mierzejewski 2009-03-25 17:59:52 EDT
I'm all for fixing the underlying problem. I've answered all your questions so far. Is there anything else I can do to help debug this?

Still, I'd like a working NetworkManager now and the workaround is simple. I guess I'll just stop arguing with you, patch it myself and roll my own package since you're obviously not going to even consider the idea of a temporary workaround.
Comment 23 Peter Robinson 2009-05-14 11:09:06 EDT
I have the same issue with th rt2860 driver. If I reconfigure my AP to use WPA it works fine. It just doesn't work with WPA2. I think this is a driver issue as opposed to a NM issue. I used my AP on WPA2 support fine with 3-4 other wifi cards (intel, ath5k and others) that have worked fine with the WPA2 on my AP. When I got my eeePC 910 with the rt2860 I had to reconfigure my AP to be WPA1 for it to connect.
Comment 24 Dan Williams 2009-05-14 14:32:09 EDT
rt2860 isn't an upstream kernel driver either, so all bets are off there.  If it's not in the kernel (and staging drivers don't count, that's why they set TAINT_CRAP), then we can't really do too much about it.  The reason drivers are accepted into the kernel in the first place is becuase they have a responsive maintainer who understands the code, and they meet some level of quality, and they conform to the existing kernel interfaces WRT userland app interaction.

Back to the original bug though; we'd need to figure out why the driver is taking that long to associate.
Comment 25 Gavin Burris 2009-07-21 09:53:32 EDT
I am having the same problem in Fedora 11, with an Intel wireless 5300 card.  Manually running wpa_supplicant and dhclient work, but NetworkManager fails.

Here is my working wpa_supplicant.conf sans userid/password:
# wpa_supplicant -i wlan0 -c wpa_supplicant.conf -Dwext -d
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
eapol_version=2
ap_scan=1
network={
priority=1
ssid="AirPennNet"
key_mgmt=IEEE8021X
eap=TTLS
phase2="auth=PAP"
identity="XXXXXXXX"
password="XXXXXXXX"
ca_cert="/etc/pki/tls/cert.pem"
}
Comment 26 Dan Williams 2009-10-16 19:10:34 EDT
How many certs does /etc/pki/ensc/chains/server.pem have in it?  This could be the CA cert chain issue which is fixed in 0.8/F12. In the mean time I think it can be worked around with a GConf key if you use the standard certificate chain path (/etc/pki/tls/cert.pem).  Setting the "system-ca-certs" item in GConf in the '802-1x' directory for that connection to the boolean "true" value will make NM just tell the supplicant to use /etc/pki/tls/cert.pem.  Until 0.8 and F12, that's the best we can do here.
Comment 27 Gavin Burris 2009-10-19 09:06:21 EDT
I cannot locate a file named server.pem.  I opened gconf-editor and there was no "system-ca-certs" item for that connection, so I created one and set it true.  I still cannot connect with NetworkManager.
Comment 28 Dan Williams 2009-11-10 18:52:37 EST
(In reply to comment #27)
> I cannot locate a file named server.pem.  I opened gconf-editor and there was
> no "system-ca-certs" item for that connection, so I created one and set it
> true.  I still cannot connect with NetworkManager.  

I think I got the key wrong, try "ca-path" as a string with the value "/etc/pki/tls/certs" in the 802-1x setting in GConf.  So if your connection is at /system/networking/connections/1, create the new "ca-path" key in /system/networking/connections/1/802-1x/.
Comment 29 Gavin Burris 2009-11-11 14:44:21 EST
(In reply to comment #28)
> (In reply to comment #27)
> > I cannot locate a file named server.pem.  I opened gconf-editor and there was
> > no "system-ca-certs" item for that connection, so I created one and set it
> > true.  I still cannot connect with NetworkManager.  
> 
> I think I got the key wrong, try "ca-path" as a string with the value
> "/etc/pki/tls/certs" in the 802-1x setting in GConf.  So if your connection is
> at /system/networking/connections/1, create the new "ca-path" key in
> /system/networking/connections/1/802-1x/.  

Still no good.  I can't connect.
Comment 30 Dan Williams 2009-11-13 18:37:12 EST
Can you grab some logs from /var/log/messages for a failed connect?  I'm curious what NM is sending down to the supplicant.  Should look something like this (though mine is for WPA-PSK):

Nov  9 12:26:38 localhost NetworkManager: <info>  Activation (wlan6/wireless): connection 'Auto foobar' has security, and secrets exist.  No new secrets needed.
Nov  9 12:26:38 localhost NetworkManager: <info>  Config: added 'ssid' value 'foobar'
Nov  9 12:26:38 localhost NetworkManager: <info>  Config: added 'scan_ssid' value '1'
Nov  9 12:26:38 localhost NetworkManager: <info>  Config: added 'key_mgmt' value 'WPA-PSK'
Nov  9 12:26:38 localhost NetworkManager: <info>  Config: added 'psk' value '<omitted>'
Nov  9 12:26:38 localhost NetworkManager: <info>  Activation (wlan6) Stage 2 of 5 (Device Configure) complete.
Comment 31 Bug Zapper 2009-11-18 07:25:44 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Bug Zapper 2009-12-18 01:03:54 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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