Bug 12880

Summary: iwl3945 regression in suspend or BSS mode
Product: Drivers Reporter: Daniel Huhardeaux (devel)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: linville, marcus, reinette.chatre
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.29-rc7 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Dmesg file
lspci -vv

Description Daniel Huhardeaux 2009-03-15 10:18:49 UTC
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
Comment 1 Daniel Huhardeaux 2009-03-15 10:23:40 UTC
Created attachment 20531 [details]
Dmesg file
Comment 2 Daniel Huhardeaux 2009-03-15 10:24:13 UTC
Created attachment 20532 [details]
lspci -vv
Comment 3 John W. Linville 2009-03-15 11:39:02 UTC
Are you using NetworkManager and/or wpa_supplicant to manage your wireless connections?
Comment 4 Daniel Huhardeaux 2009-03-15 11:50:47 UTC
wep security in manual mode by using /etc/network/interfaces and wireless-tools
Comment 5 John W. Linville 2009-03-15 14:24:20 UTC
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.
Comment 6 Daniel Huhardeaux 2009-03-15 14:37:34 UTC
Well, but this doesn't explain why recovering from s2disk doesn't work anymore.
Comment 7 John W. Linville 2009-03-15 19:27:59 UTC
Perhaps I don't understand what you mean...?  What happens if you don't do the modprobe stuff?
Comment 8 Daniel Huhardeaux 2009-03-16 07:08:54 UTC
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.
Comment 9 John W. Linville 2009-03-16 08:21:43 UTC
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?
Comment 10 Daniel Huhardeaux 2009-03-16 09:51:37 UTC
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.
Comment 11 John W. Linville 2009-03-16 11:11:05 UTC
If modprobe sequence is required after suspend, that seems wrong.
Comment 12 Daniel Huhardeaux 2009-03-28 10:52:16 UTC
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.
Comment 13 Reinette Chatre 2009-03-30 17:18:17 UTC
The roaming should be handled by wpa_supplicant, not the driver.
Comment 14 Daniel Huhardeaux 2009-03-30 17:51:08 UTC
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.
Comment 15 Reinette Chatre 2009-04-10 21:52:18 UTC
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
Comment 16 Daniel Huhardeaux 2009-04-15 12:07:33 UTC
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
Comment 17 Reinette Chatre 2009-04-15 17:22:04 UTC
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