Bug 432167

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

Same thing happens to me on rawhide (pre-F10), although admittedly the NetworkManager user interface has improved and remembers the entered values now.

Is there any way to increase NetworkManager timeout values?

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?

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.

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

Created attachment 323595 [details]
a working wpa_supplicant.conf

And here's a working wpa_supplicant.conf.

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

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.

This was reported against F-10 as well.

(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?

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

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.

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

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.

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.

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

But are you sure the *inner* (ie, phase2) eap method is allowed to be PAP?

(In reply to comment #18)
> But are you sure the *inner* (ie, phase2) eap method is allowed to be PAP?

With TTLS, yes.

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

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.

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.

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.

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.

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"
}

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.

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.

(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/.

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

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.

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

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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days