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.11.svn4022.4.fc9.x86_64 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-2.6.26.5-45.fc9.x86_64 wpa_supplicant-0.6.3-6.fc9.x86_64
I am seeing this as well. kernel-2.6.27.9-73.fc9.x86_64 wpa_supplicant-0.6.4-2.fc9.x86_64 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-2.6.27.9-73.fc9.x86_64 > wpa_supplicant-0.6.4-2.fc9.x86_64 > > 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://bugzilla.redhat.com/show_bug.cgi?id=477964 .
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://marc.info/?l=linux-wireless&m=123439060131140&w=2 (mac80211-based cards) http://marc.info/?l=linux-wireless&m=123437688107698&w=2 (ipw2100 & ipw2200) 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 [details] patch against 2.6.27.15 from F-9 updates as of 2009-02-25
Created attachment 333270 [details] patch against 2.6.28.2 from F-9 package CVS as of 2009-02-25
Created attachment 333271 [details] 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 [details] 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 [details] ipw2x00 scan age patch against 2.6.28.2 from F-9 package CVS
Created attachment 333320 [details] 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!
kernel-2.6.27.21-78.2.41.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kernel-2.6.27.21-78.2.41.fc9
kernel-2.6.27.21-78.2.41.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2989
kernel-2.6.27.21-78.2.41.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.