From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Description of problem:
This problem happens most often when the connection quality is poor.
The initial connection (e.g. from login to an account, after stopping and restarting both NetworkManager AND wpa_supplicant, etc.) is usually OK. After the wireless network looses connection, NetworkManager is often unable to reconnect.
Kernel module used: ipw2200.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Establish a connection to a faraway access point, using WPA-PEAP.
2. Let it disconnect. For some reason, re-starting nm-applet produces the same effect - can be used to debug the problem without much wait.
10% of the time, connection re-establishes normally.
There are 3 scenarios of reconnection failure:
1. wpa_supplicant doesn't even try to associate with an access point. wpa_supplicant.log only contains the lines
Applet GUI shows 'connection in progress spinner', but supplicant seems idle. No GUI action (clicking "Connect" in a dialog asking to re-enter credentials, selecting the proper SSID from nm-applet menu) changes the situation.
To work-around this problem, the following command must be executed as root:
$ iwconfig eth1 essid <ESSID> key 0
After that, the supplicant starts to associate, and can even establish a connection, but more likely one of the other two scenarios happens.
2. Association/connection times out. NetworkManager has a very short connection timeout (20-30 seconds or so), which is too short to establish a connection over a poor link in some cases. This might also be a wpa_supplicant or kernel module issue. Restarting wpa_supplicant usually helps.
3. Authentication fails. Once it failed once, re-trying the connection always fails. The workaround is to restart both wpa_supplicant and NetworkManager daemons (applet can keep running), OR uncheck "Enable Networking" box in applet menu, then check it back again.
NM should be able to reconnect with the same pass/fail ratio as initial connection. Connection timeout should be either longer by default, or configurable. Ideally, NM shouldn't even ask for credentials to re-attempt failed connection (see bug 447620), only giving a warning status to the user.
It seems that wpa_supplicant state machine and NM state machine are becoming out of sync. One hint at this is that ESSID is lost - looks like wpa_supplicant drops ESSID, while NM thinks that ESSID has already been sent and doesn't re-send it.
Sections of wpa_supplicant.log and NM debug printouts for good and bad conditions will be attached.
Please advise if separate bugs should be opened for each failure scenario, and
this one kept as a tracker.
Created attachment 307274 [details]
A good sequence in wpa_supplicant.log
Note that 'trying to associate' happens twice. In bad wireless weather it can
happen many more times before the connection is established, so
increased/configurable timeout will help.
Created attachment 307277 [details]
NetworkManager info printouts of successfull connection
Created attachment 307278 [details]
NetworkManager info printouts when no association happens
The supplicant state changes 0->3->0->3... ad infinitum.
Created attachment 307279 [details]
A sequence in wpa_supplicant.log when it fails to associate
Created attachment 307280 [details]
A sequence in wpa_supplicant.log when it fails to authenticate
sounds like the supplicant either can't find the network or can't reconnect to
it; as you've discovered the supplicant direct scan patches and the ipw2200
direct scan patches should help. Let me know how they work when you've had a
chance to apply the ipw2200 direct scan patch.
Updates to fix this have been around for a long time; please re-open if latest updates don't work. Thanks!