Latest working kernel version: 2.6.26 Earliest failing kernel version: 2.6.28 Distribution: Debian SID Hardware Environment: Notebook Dell Inspiron 6400 Software Environment: Problem Description: When coming back from s2disk I have to: . ifdown wlan0 . rmmod iwl3945 . modprobe iwl3945 . ifup wlan0 In the mean time, I use my notebook in a BSS environment. As soon as the notebook is out of the range of the AP on which he is connected, he looses the wireless connection instead of switching to another AP in his area. I made the same test with an eeePC (Lenny) and a Nokia E65 phone, they work correctly meaning that they switch to the other AP. I hadn't -at least the s2disk one- those problems with a 2.6.26 kernel. Steps to reproduce: always
Created attachment 20531 [details] Dmesg file
Created attachment 20532 [details] lspci -vv
Are you using NetworkManager and/or wpa_supplicant to manage your wireless connections?
wep security in manual mode by using /etc/network/interfaces and wireless-tools
I see...well unfortunately mac80211-based drivers don't automatically re-establish connections (and never have done so). If you want that functionality (as one understandably would) then I recommend using wpa_supplicant (even with WEP or open networks). It is smart enough to perform the roaming functions.
Well, but this doesn't explain why recovering from s2disk doesn't work anymore.
Perhaps I don't understand what you mean...? What happens if you don't do the modprobe stuff?
Coming out from s2disk I have no more network (dhcp client), even by running manually the dhclient command. This doesn't matter if the access point on which I try to connect when coming back from suspend is the original one (the one on which I was connected before entering suspend mode) or another one.
The modprobes shouldn't be necessary. My guess would be that the ifdown and ifup combination would suffice. This is really no different than the AP out of range situation. The wireless connection is lost and needs to be reestablished. Running the dhcp client is insufficient, as it is equivalent to running it on a wired network when the cable has been unplugged. Again, I would recommend using wpa_supplicant as it is smart enough to do the requisite work for you. Otherwise, upon resume you will need to execute the requisite set of ifconfig/iwconfig/dhclient/etc commands either manually or by means of your ifup script. Does this resolve the issue?
Sure is that ifdown/ifup doesn't work. With a 2.6.26 it's ok, that's why I opened this bug. Will give a try to the wpa_supplicant stuff and let you know.
If modprobe sequence is required after suspend, that seems wrong.
With 2.6.29 and wpa_supplicant I can resume from s2ram (s2disk doesn't work in this version in SID) and then ifdown/ifup give me the network back. No modprobe sequence required anymore. Couldn't test the BSS stuff.
The roaming should be handled by wpa_supplicant, not the driver.
Yes. But remember that the original message said "I have to rmmod/modprobe" the driver to get an after suspend session to be able to connect again to the network. Since my last message from 28/03/2009 I had again the case -one time- where I had to rmmod/modprobe the iwl3945 driver. And yes, I'm using wpa_supplicant. So there is still something wrong when coming back from suspend mode.
Could you please provide more information about the environment when you come back from suspend mode? What is output of: - iwconfig wlanX - ifconfig wlanX Are you still running with wpa_supplicant? Do you still need to unload the module and reload the module? If so, please compile driver with debug support and run the following before you suspend: echo 0x43fff > /sys/class/net/wlan0/device/debug_level
As told in my message from 30/03/09: - I use wpa_supplicant - I can't test the suspend from s2disk mode, it's broken in Debian/SID - with s2ram it's OK - since last kernel update from SID (build 04/04/09) I hadn't anymore to remove the driver - I hadn't possibility to test roaming, but as told by you, it's to wpa_supplicant to handle it. You can close this bug, it's solved with latest kernel 2.6.29-2 and other is wpa_supplicant stuff. Thanks for your time and help. -- Daniel
Daniel, You are the reporter of this bug and thus one who decide whether it is fixed or not. I am not able to change the state of the bug - could you please mark it as fixed. Thanks