Bug 449215 - NetworkManager fails to re-connect to WPA-PEAP network after connection loss
Summary: NetworkManager fails to re-connect to WPA-PEAP network after connection loss
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 9
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On: 447620
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-31 12:16 UTC by Pavel Polischouk
Modified: 2009-02-17 17:03 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2009-02-17 17:03:07 UTC


Attachments (Terms of Use)
A good sequence in wpa_supplicant.log (915 bytes, application/octet-stream)
2008-05-31 12:25 UTC, Pavel Polischouk
no flags Details
NetworkManager info printouts of successfull connection (6.81 KB, application/octet-stream)
2008-05-31 12:32 UTC, Pavel Polischouk
no flags Details
NetworkManager info printouts when no association happens (4.10 KB, text/plain)
2008-05-31 12:40 UTC, Pavel Polischouk
no flags Details
A sequence in wpa_supplicant.log when it fails to associate (576 bytes, text/plain)
2008-05-31 12:42 UTC, Pavel Polischouk
no flags Details
A sequence in wpa_supplicant.log when it fails to authenticate (877 bytes, application/octet-stream)
2008-05-31 12:45 UTC, Pavel Polischouk
no flags Details

Description Pavel Polischouk 2008-05-31 12:16:15 UTC
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):
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386 wpa_supplicant-0.6.3-5.fc9.i386

How reproducible:
Sometimes


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.

Actual Results:
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

CTRL-EVENT-SCAN-RESULTS 
CTRL-EVENT-SCAN-RESULTS 
CTRL-EVENT-SCAN-RESULTS 
CTRL-EVENT-SCAN-RESULTS 
CTRL-EVENT-SCAN-RESULTS 
CTRL-EVENT-SCAN-RESULTS 
...

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.

Expected Results:
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.

Additional info:
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.

Comment 1 Pavel Polischouk 2008-05-31 12:20:22 UTC
Please advise if separate bugs should be opened for each failure scenario, and
this one kept as a tracker.

Comment 2 Pavel Polischouk 2008-05-31 12:25:12 UTC
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.

Comment 3 Pavel Polischouk 2008-05-31 12:32:50 UTC
Created attachment 307277 [details]
NetworkManager info printouts of successfull connection

Comment 4 Pavel Polischouk 2008-05-31 12:40:13 UTC
Created attachment 307278 [details]
NetworkManager info printouts when no association happens

The supplicant state changes 0->3->0->3... ad infinitum.

Comment 5 Pavel Polischouk 2008-05-31 12:42:30 UTC
Created attachment 307279 [details]
A sequence in wpa_supplicant.log when it fails to associate

Comment 6 Pavel Polischouk 2008-05-31 12:45:49 UTC
Created attachment 307280 [details]
A sequence in wpa_supplicant.log when it fails to authenticate

Comment 7 Dan Williams 2008-06-02 20:52:59 UTC
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.

Comment 8 Dan Williams 2009-02-17 17:03:07 UTC
Updates to fix this have been around for a long time; please re-open if latest updates don't work.  Thanks!


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