Bug 249322 - wpa_supplicant fails to/incorrectly re-associates after S3 suspend
wpa_supplicant fails to/incorrectly re-associates after S3 suspend
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: wpa_supplicant (Show other bugs)
6
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-23 14:37 EDT by Carl Roth
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 15:43:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Carl Roth 2007-07-23 14:37:57 EDT
Description of problem:

I'm running a laptop with WiFi and wpa_supplicant, connecting to a AP with WPA
encryption.  After resuming from suspend, the wireless adapter connects to the
first available (unencrypted) access point and ignores the AP it was using
before it suspended.  In particular, the new AP that it connects to is not
listed in the wpa_supplicant.conf, and would not have been a valid connection at
boot time.

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

wpa_supplicant-0.4.9-1.fc6
kernel-2.6.20-1.2962.fc6
ipw3945d-1.7.22-4
ipw3945-firmware-1.14.2-1

How reproducible:
Most of the time.

Steps to Reproduce:
1. associate with an AP using WPA via wpa_supplicant
2. suspend, then resume
3. note the new AP that the machine connects to.  If there's an unencrypted AP
close enough, the WiFi adapter will associate with it first.
  
Actual results:


Expected results:
The wireless adapter should only associate with the AP's listed in
wpa_supplicant.conf.

Additional info:
I should also point out that this is a security issue.  The Wifi adapter should
not be associating with foreign APs unless the user specifically authorizes it.
 I'm not sure whose unencrypted "linksys" AP I was connecting to when the laptop
resumed, but I'm sure neither of would approve...

One workaround is to take the interface down before the computer is suspended;
this is kind of a hack and I've also noticed that it doesn't always work --
wpa_supplicant will sometimes still connect to the foreign AP.
Comment 1 George N. White III 2007-11-24 08:59:38 EST
Fedora Core 8

Associate with a configured SSID.  If the connection fails, 
NetworkManager associates with a "randon" open AP.  Documentation
states that NM will only associate if the AP has been selected.
Since the list of AP's gets updated, it is not hard to accidentally
select the wrong one by mistake, so there needs to be a way to 
clear the list of AP's to be used, and/or an option to use only
those in wpa_supplicant.conf.

Comment 2 Dan Williams 2007-12-03 11:24:26 EST
"I should also point out that this is a security issue.  The Wifi adapter should
not be associating with foreign APs unless the user specifically authorizes it."

This ^^^ is a kernel driver issue, and not something easy to control.  Many
cards firmware will actively attempt to associate with an AP until it's told to
associate with some other AP explicitly.  This behavior is not related to, or
under the control of, wpa_supplicant in any way.  Some drivers have module
options (iwlwifi and ipw do) to disable this behavior.

@george: can you be more specific?  NM itself will _never_ tell wpa_supplicant
to associate with an AP that you haven't chosen yourself at some point from the
menu.  The card and driver may associate with random APs due to firmware or
driver decisions, which could be a security issue, although if the device does
not have an IP address the risk is mitigated.

What do you mean when you say "clear the list of APs to be used?"  You mean
clear the list of APs that NetworkManager will allow the machine to associate
with?  This bug is also about wpa_supplicant, so if you have a specific
NetworkManager bug, please file a separate bug targetted at the NetworkManager
component.
Comment 3 Bug Zapper 2008-04-04 03:29:01 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 4 Bug Zapper 2008-05-06 15:43:08 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus 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.