Bug 407311

Created attachment 274701 [details]
/var/log/messages

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.

Yes, b43.  kernel 2.6.23.8-63.fc8.

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.

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.

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.

@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.

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.

If NM went through updates-testing, wouldn't that be reflected in
fedora-test-list archives? I cannot find this reflection. 

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.

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

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:
ff:ff:ff:ff:ff:ff

this definitely sounds like a driver problem.

see bug 412861 for more b43 problems yet to be fixed

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.

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.

(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.

If this is still an issue with latest F8 updates (2.6.26.5-28.fc8 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.