Wifi driver fixes for age scan
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| linux (Fedora) |
Fix Released
|
Low
|
|||
| linux (Ubuntu) |
Fix Released
|
Low
|
Tim Gardner | ||
| Jaunty |
Fix Released
|
Low
|
Tim Gardner | ||
| pm-utils (Ubuntu) |
Fix Released
|
Medium
|
Steve Langasek | ||
| Jaunty |
Fix Released
|
Medium
|
Steve Langasek | ||
Bug Description
SRU justification:
Impact: The houskeeping of the wireless stack does not account for the time spent in suspend. So after resume it will think the AP's from the last scan are still valid and tries to reconnect to the one connected to before suspended.
Fix: Account for the time spent in suspend when resuming. Patch taken from https:/
Testcase: Connect to an access point, suspend, move away and resume.
---
When you resume from suspend the wifi drivers get confused and network-manager continues to show the access points from when you suspended the laptop. Dan Williams has fixes for this.
Description of problem:
I regularly use my laptop with two wireless networks in different locations. When I suspend the laptop while it is connected to network "A," then resume it within the range of network "B," NetworkManager usually made an immediate connection to network "B."
With the latest update, NetworkManager instead attempts to connect to network "A," which is over 10 miles away. Failing at this, it will prompt me for network secrets; clicking "Cancel" in this dialog box will cause it to connect to network "B" as was previously its practice.
Version-Release number of selected component (if applicable):
NetworkManager version: 0.7.0-0.
Wireless driver: iwl3945
This isn't an issue with NM actually, but something either in the supplicant or the drivers. This bug has been around for a long time but I've traced it to layers below NM.
What's your kernel version, and what version of wpa_supplicant do you have on the machine?
kernel-
wpa_supplicant-
I am seeing this as well.
kernel-
wpa_supplicant-
iwl3945 as well.
Lately networking is disabled after returning from a suspend. Re-enabling networking seems to work.
In the past I have also seen the system restore to the previous connection (which was 20+ miles away) and continue to think it was connected until I again suspended, then return to the original location and resumed. Upon resume, NM usually had to prompt me for the network password (which was preloaded into the dialogue box) which I had to select CONNECT before it would reconnect me.
Shouldn't NM automatically restore the previous connection if it is still available?
If it helps, I've disabled HW scanning when loading the iwl3945 module as it helps me make a connection more reliably upon the initial system boot-up:
options iwl3945 disable_hw_scan=1
also chipping in here...
no supplicant but using NM and wireless, suspend to disk and upon wakeup, network manager wireless connections are disabled until I 'service restart NetworkManager'
Fedora 10, Acer Aspire One (some Intel wireless chipset)
(In reply to comment #3)
> I am seeing this as well.
>
> kernel-
> wpa_supplicant-
>
> iwl3945 as well.
>
> Lately networking is disabled after returning from a suspend. Re-enabling
> networking seems to work.
Kevin: this is a pm-utils issue caused by a dbus bug; see https:/
For the original bug where NM tries to connect to an access point that's clearly not present, that's actually a kernel bug which I traced down this week. The drivers weren't correctly aging scan results from before suspend, thus when NM woke up all the APs from before suspend looked like they had been seen less than 10 seconds ago. These patches were submitted to the kernel this past week and should get into Fedora fairly soon; though we may need to backport them to recent kernels.
http://
http://
These patches should cover most cards in use today.
I don't see a practical way to backport this (at least the cfg80211/mac80211 bits) to anything earlier than 2.6.30. The patch depends on cfg80211 PM ops support and cfg80211-based scanning. It could be rewritten, but it would require either layering violations or work-arounds, all to produce a one-off patch for an aging kernel. I just can't justify the time.
I'll do the backport for mac80211 if you like. When I looked at it I didn't think it would be that bad in mac80211, but I may have been wrong.
I'm happy for you to do that if you are interested.
The way I read it, you'd need to backport "cfg80211: add PM hooks" (which is trivial), then either backport all the cfg80211 scanning (yuk!) or add something to cfg80211_ops to notify mac80211 of suspend/resume events. Given the later, then you'll need to reformulate our aging changes around bss->last_update.
Of course, YMMV...maybe you see something I missed! :-)
Created attachment 333269
patch against 2.6.27.15 from F-9 updates as of 2009年02月25日
Created attachment 333270
patch against 2.6.28.2 from F-9 package CVS as of 2009年02月25日
Created attachment 333271
patch against 2.6.29-rc6 from F-10 package CVS as of 2009年02月25日
I hope the 2.6.29-rc6 patch that I did against the F-10 package CVS kernel will work for devel too; looks like Rawhide is using 2.6.29-rc6 as well. Let me know if you find issues; I tested the patches using ath5k and suspend-to-disk.
Created attachment 333273
patch against 2.6.29-rc6 from F-10 package CVS as of 2009年02月25日
remove some debugging stuff that got left in the previous version of this patch
If these look OK I'll do the ipw2x00 patches too.
Created attachment 333319
ipw2x00 scan age patch against 2.6.28.2 from F-9 package CVS
Created attachment 333320
ipw2x00 scan age patch against 2.6.29-rc6 from F-10 package CVS
Hey, looks great. I've pushed them into the current stable of Fedora kernels...thanks!
with my NM head on, I nominate this for jaunty with beta target. Its really a long standing issue, which causes lots of complains about NM's bad scan behaviour. Thanks for taking this to our kernel.
s/head/hat/ ;)
This bug was fixed in the package linux - 2.6.28-8.27
---------------
linux (2.6.28-8.27) jaunty; urgency=low
[ Amit Kucheria ]
* Updating configs (arm:ixp4xx)
[ Andy Whitcroft ]
* SAUCE: enable Intel HDMI output
[ Manoj Iyer ]
* SAUCE: Added quirk for Linksys WUSB600N USB wifi-n networking adapter
- LP: #323473
[ Steve Beattie ]
* fix apparmor memory leak on unlinked file ops
- LP: #329489
[ Tim Gardner ]
* SAUCE: Dell XPS710 reboot quirk
- LP: #323592
* SAUCE: (drop after 2.6.28) ieee80211: Add infrastructure to obsolete
scan results
- LP: #336055
* Add modules.order to the linux-image package.
[ Upstream Kernel Changes ]
* iwlwifi: fix time interval misuse in iwl_poll_
* x86: only scan the root bus in early PCI quirks
- LP: #267295
* ALSA: hda - Intel HDMI audio support
* ALSA: hda - Fix unused function in patch_intelhdmi.c
* ALSA: handle SiI1392 HDMI codec in patch_intelhdmi.c
* ALSA: hda-intel: reorder HDMI audio enabling sequence
* ALSA: introduce snd_print_
* ALSA: create hda_eld.c for ELD routines and proc interface
* ALSA: ELD proc interface for HDMI sinks
* ALSA: hda: make standalone hdmi_fill_
* ALSA: hda: make global snd_print_
* ALSA: hda: HDMI channel allocations for audio infoframe
* ALSA: hda: HDMI channel mapping cleanups
* ALSA: hda: minor code cleanups
* ALSA: hda: rename sink_eld to hdmi_eld
* ALSA: hda - Release ELD proc file
* ALSA: hda - minor HDMI code cleanups
* ALSA: hda - report selected CA index for Audio InfoFrame
* ALSA: hda - Add Intel vendor id string
-- Tim Gardner <email address hidden> 2009年2月25日 14:23:46 -0700
kernel-
http://
kernel-
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
Running kernel 2.6.28-11-generic with the iwlwifi driver with a 5350 card. This problem still exists now, from a fresh beta install with updates as of March 31. Network manager still tries to connect to a ghost network (that I last was connected to before suspending).
kernel-
Steve Langasek proposed that we could work around this with a pm-utils resume.d script which attempts to do an "iwlist scan iwlan0". This sounds fairly harmless to me, and should help the common case.
Since there seems to be some doubt in the kernel team about whether this bug still exists, I confirm that it's consistently reproducible with 2.6.28-11.38 and iwl3945.
I have an implementation of this for pm-utils that does what's intended; however, what I find is that even though a rescan is forced from userspace, the ESSID that the system was associated to before suspend is not cleared from the list. So this is only a partial fix: the correct post-resume ESSIDs are listed and can be selected immediately from nm-applet, but NM won't automatically roam to them because it sees the previous ESSID is still available.
This bug was fixed in the package pm-utils - 1.2.2.4-0ubuntu4
---------------
pm-utils (1.2.2.4-0ubuntu4) jaunty; urgency=low
* debian/45iwlist: force a rescan of essids on all wireless networks on
resume, to work around the kernel's wrong idea of the age of networks
detected prior to suspend. LP: #336055.
-- Steve Langasek <email address hidden> 2009年4月03日 10:10:54 -0700
Hi,
what about integrating https:/
oops - reverted because its an ABI bumper. I'll re-apply at a more convenient time.
- Network_Manager_suspend_jaunty_test.ogv Edit (5.2 MiB, video/ogg)
@Tim
When do you plan to put this fix into the so it tested out with our kernel?
@Steve
While yours does kick off a rescan the card still tries to connect to the old AP.
I notice this in dmesg:
[4253.476743] wlan0: direct probe to AP 00:21:55:b1:d9:01 try 1
[ 4253.676061] wlan0: direct probe to AP 00:21:55:b1:d9:01 try 2
[ 4253.876089] wlan0: direct probe to AP 00:21:55:b1:d9:01 try 3
[ 4254.077545] wlan0: direct probe to AP 00:21:55:b1:d9:01 timed out
Where it is trying to probe for the AP that is not there anymore.
I also created a video of the situation. I created on my Lenovo x301 with Intel 5350 card. But really it's on anything using iwl driver.
@Jerone - I'll re-apply this patch after release as an SRU.
I built the jaunty kernel tree git head with this patch patches included. Can confirm things now work now, and it no longer looks for the older wifi ap after resume from suspend.
This patch was already upstream in the first Karmic upload.
linux (2.6.30-1.1) karmic; urgency=low
* Initial release after rebasing against v2.6.30-rc3
-- Tim Gardner <email address hidden> 2009年3月12日 19:16:07 -0600
SRU Justification:
Impact: Scan results are not obsoleted after suspend/resume. leaving possibly old Access Points in the scan list
Patch Description: Add suspend/resume infrastructure to mac802_11 and obsolete scan results after resume.
Test Case: See bug description
Accepted linux into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
This bug was fixed in the package linux - 2.6.28-13.44
---------------
linux (2.6.28-13.44) jaunty-proposed; urgency=low
[ Stefan Bader ]
* Revert "SAUCE: [jaunty] ALSA: Add retry for Intel8x0 clock measurement"
* Revert "SAUCE: [jaunty] ALSA: Fix clock and buffer calculations for
Intel8x0"
* Revert "SAUCE: [jaunty] ALSA: Fix buffer positions and checks"
linux (2.6.28-12.43) jaunty-proposed; urgency=low
[ Amit Kucheria ]
* Enable SYN_COOKIES for iop32x and versatile flavours
- LP: #361687
* SAUCE: Quirk for BT USB device on MacbookPro to be reset before use
- LP: #332443
[ Brad Figg ]
* [jaunty] Add missing mvsas (Marvel SAS 6440) module configuration.
- LP: #352336
[ Chuck Short ]
* SAUCE: [USB] Unusual Device support for Gold MP3 Player Energy
- LP: #125250
[ Daniel T Chen ]
* SAUCE: [jaunty] ALSA: Fix buffer positions and checks
- LP: #345627
* SAUCE: [jaunty] ALSA: Fix clock and buffer calculations for Intel8x0
- LP: #345627
* SAUCE: [jaunty] ALSA: Add retry for Intel8x0 clock measurement
- LP: #345627
[ Luke Yelavich ]
* disable CONFIG_
- LP: #331589
[ Makito SHIOKAWA ]
* [ARM] 5404/1: Fix condition in arm_elf_
READ_
- LP: #364358
[ Manoj Iyer ]
* SAUCE: Added quirk to fix key release for Samsung NC20
- LP: #360247
[ Oleg Nesterov ]
* posix timers: fix RLIMIT_CPU && fork()
- LP: #361508
[ Scott James Remnant ]
* [Config] Disable libusual and the ub driver
- LP: #364538
[ Stefan Bader ]
* Disable unwanted staging builds
- LP: #366144
* Remove prism2_usb driver from ubuntu and use the one from staging
- LP: #325366
* SAUCE: Make rtl8187se depend on WIRELESS_EXT
- LP: #366144
* Disable CONFIG_RTL8187SE for armel.versatile
- LP: #366144
[ Tejun Heo ]
* libata: handle SEMB signature better
- LP: #257790
[ Tim Gardner ]
* Set USB_SERIAL=m for i386/amd64
- LP: #345002
* SAUCE: Jaunty - aic79xx - set reset delay to 5 seconds, down from 15.
- LP: #79542
* SAUCE: (drop after 2.6.28) Wifi suspend/resume scan timeout fixes
- LP: #336055
* Sony laptop: Sony Vaio laptops do not enable wwan power by default.
- LP: #364678
[ Tyler Hicks ]
* SAUCE: (drop after 2.6.28) eCryptfs: Larger buffer for encrypted
symlink targets
- LP: #357345
[ Upstream Kernel Changes ]
* V4L/DVB (9999): gspca - zc3xx: Webcam 046d:089d added.
- LP: #326674
* V4L/DVB (10044): gspca - pac7311: Webcam 093a:2620 added.
- LP: #363195
* hwmon: (it87) Add support for the ITE IT8720F
- LP: #357766
* vgacon: Return the upper half of 512 character fonts
- LP: #355057
* drm/i915: add support for G41 chipset
- LP: #365958
-- Stefan Bader <email address hidden> 2009年5月25日 17:30:40 +0200
This was working for me in Jaunty, but this bug is occurring in my fresh 64 bit Karmic install.
I use the wl wireless driver for my Broadcom BCM4328 802.11a/b/g/n card.
When I resume from suspend in a new location, it tries to connect to the access point from the old location. Manually switching to access points in the new location fails, until the attempt to connect to the old access point times out.
rmmod wl; modprobe wl - This will reload the driver and make it work, but I consistently get a kernel panic minutes after unloading and loading this module.