Bug 449215 - NetworkManager fails to re-connect to WPA-PEAP network after connection loss
NetworkManager fails to re-connect to WPA-PEAP network after connection loss
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On: 447620
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-31 08:16 EDT by Pavel Polischouk
Modified: 2009-02-17 12:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-17 12:03:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Pavel Polischouk 2008-05-31 08:16:15 EDT
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 08:20:22 EDT
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 08:25:12 EDT
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 08:32:50 EDT
Created attachment 307277 [details]
NetworkManager info printouts of successfull connection
Comment 4 Pavel Polischouk 2008-05-31 08:40:13 EDT
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 08:42:30 EDT
Created attachment 307279 [details]
A sequence in wpa_supplicant.log when it fails to associate
Comment 6 Pavel Polischouk 2008-05-31 08:45:49 EDT
Created attachment 307280 [details]
A sequence in wpa_supplicant.log when it fails to authenticate
Comment 7 Dan Williams 2008-06-02 16:52:59 EDT
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 12:03:07 EST
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.