Bug 407311 - NM asks for key to connect to wireless after resuming from suspend
Summary: NM asks for key to connect to wireless after resuming from suspend
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager   
(Show other bugs)
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-01 14:58 UTC by Orion Poplawski
Modified: 2008-10-20 15:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-20 15:45:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages (20.96 KB, text/plain)
2007-12-01 14:58 UTC, Orion Poplawski
no flags Details

Description Orion Poplawski 2007-12-01 14:58:16 UTC
Description of problem:

I have NM configured to automatically connect to my wireless network and my key
is in my keyring.  Works fine normally.  However, after coming out of suspend NM
keeps asking for the wireless key.  If I restart NM it connects automatically again.

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

How reproducible:
every time

I've attached /var/log/messages showing the suspend/resume, fail to reconnect,
and NM restart -> connect.

Comment 1 Orion Poplawski 2007-12-01 14:58:16 UTC
Created attachment 274701 [details]

Comment 2 Dan Williams 2007-12-03 15:11:03 UTC
The log indicates that your driver can't connect to the AP after resume.  This
is b43, right?  Can you report your kernel version?  I've had problems with
iwl4965, for example, that just craps itself out after resume (or after toggling
the rfkill switch a few times) and at that point you need to unload/reload the
module.  One thing to try when it gets in this state before killing NM like you
did in that log.  After you've cancelled, try to rmmod the b43 module, modprobe
it again, then choose your AP from the menu again.

Comment 3 Orion Poplawski 2007-12-03 15:49:35 UTC
Yes, b43.  kernel

It actually just survived a resume, but I had lots of trouble recently with it
just cutting out.  That could be any number of causes, but what seems wrong it
NM asking me for a key and sometimes not reconnecting until it gets restarted. 
I'll try the modprobe next time.

Comment 4 Dan Williams 2007-12-03 16:18:35 UTC
Ok, let me know about the modprobe.  After that we'll need to start getting
debugging info from the driver.  It's usually a driver problem when, after
suspend/resume, the driver won't connect successfully.

Comment 5 Alexei Podtelezhnikov 2007-12-04 23:27:07 UTC
This is a *regression* from the Fedora 8 original NetworkManager.
That one never dropped the connection and never annoyed me with WEP keys.

Please revert or fix as soon as possible. Next time go through the 
update-testing, which you skipped this time. This is not funnny.

Comment 6 Dan Williams 2007-12-05 15:16:56 UTC
@alexei; 3109 _did_ go through updates-testing.  It was there for at least a few
days during which time at least 3 people said it fixed their bugs, and when the
update gets a karma of 3 or greater, it gets automatically pushed to stable.

Comment 7 Orion Poplawski 2007-12-05 15:38:57 UTC
Today it seems that I need to kill and restart nm-applet to get it to reconnect
to the network.   rmmod/modprobe didn't do it.

Comment 8 Alexei Podtelezhnikov 2007-12-05 20:22:29 UTC
If NM went through updates-testing, wouldn't that be reflected in
fedora-test-list archives? I cannot find this reflection. 

Comment 9 Dan Williams 2007-12-05 20:37:03 UTC
bodhi - 2007-11-29 01:44:07
This update has been pushed to testing
cra - 2007-11-29 15:56:12
EAP-TLS works for me now.
lmacken - 2007-11-29 21:04:06
libbe - 2007-11-30 15:15:00
nm-applet doesn't crash anymore for me.
bodhi - 2007-12-03 05:35:37
This update has been pushed to stable 

so 4 days + 4 hours.

Comment 10 Alexei Podtelezhnikov 2007-12-05 23:54:40 UTC
Just tested 3138 from koji. Connections are still less stable than they used to
be. It is possible that this is in the kernel, which is also updated in the last
few days.

This is a typical warning:
wlan0: authentication frame received from 00:11:11:11:11:11, but not in
authenticate state - ignored

Comment 11 Alexei Podtelezhnikov 2007-12-06 00:09:52 UTC
This is how connection gets reset. No, I am not moving around the house at all.
The signal is at 66-80%

wlan0: association frame received from 00:11:11:11:11:11, but not in associate
state - ignored
wlan0: No ProbeResp from current AP 00:11:11:11:11:11 - assume out of range
wlan0: No STA entry for own AP 00:11:11:11:11:11
wlan0: No STA entry for own AP 00:11:11:11:11:11
b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac:

Comment 12 Dan Williams 2007-12-06 10:45:47 UTC
this definitely sounds like a driver problem.

Comment 13 Alexei Podtelezhnikov 2007-12-11 00:56:40 UTC
see bug 412861 for more b43 problems yet to be fixed

Comment 14 Michael Buesch 2007-12-12 23:27:57 UTC
suspend/resume doesn't work for b43.
In fact, I think that suspend/resume do not work for _ANY_ mac80211 based
driver, as the mac80211 subsystem doesn't know about suspend/resume, yet.
Essential things like re-upload of the encryption key data and reassociation to
the AP is not triggered.

Comment 15 Dan Williams 2007-12-13 14:39:06 UTC
Michael; from userspace we don't care so much about the 802.11 setup after the
machine comes back, since it's quite possible that the machine is in a
completely different location and the old settings aren't usable anymore.  We
can't say with any certainty that the old settings pre-suspend are valid.

Ideal situation: driver/wpa_supplicant tries to reassociate with the previous AP
right after resume.  If that succeeds, NM tries to renew DHCP if the lease is
past it's REBIND interval, otherwise does a full DHCP cycle, or sets up static
IP or whatever.

Current situation: the devices get torn down _completely_ on suspend, set
!IFF_UP (to turn off the radio), and NM forgets about them.  On resume, NM does
device discovery through HAL again, scans for a known AP, and begins to activate
that AP all over again.

Right now there are too many variables to handle to try to preserve state across
suspend/resume.  So while it would be nice for mac80211 to try to reassociate
when it comes back, it's not really worth spending a ton of time on right now
from my perspective.

What we do need is for the _hardware_/driver to come back in a usable state so
that they can be driven again, and not go off into the weeds like iwl4965
sometimes does these days.

Comment 16 Michael Buesch 2007-12-13 15:08:22 UTC
(In reply to comment #15)
> What we do need is for the _hardware_/driver to come back in a usable state so
> that they can be driven again, and not go off into the weeds like iwl4965
> sometimes does these days.

So what exactly doesn't come back in the b43 case?
suspend/resume calls the same routines as a start/stop from mac80211 does.

Comment 17 Dan Williams 2008-10-20 15:45:27 UTC
If this is still an issue with latest F8 updates ( or later), NM (svn4022.4 or later), and wpa_supplicant (0.5.10-6.fc8 or later), please re-open this issue.  The kernel updates since 2007 would have the largest impact.

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