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): NetworkManager-0.7.0-0.6.6.svn3109.fc8 How reproducible: every time I've attached /var/log/messages showing the suspend/resume, fail to reconnect, and NM restart -> connect.
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.