After resume, NM tries to connect to previous, now non-available Wi-Fi network -- happens with wl and not with ath9k
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NetworkManager |
Unknown
|
Medium
|
|||
linux (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: network-manager
On Ubuntu Karmic Beta + the latest updates as of this morning ( EDT time ), I run into the following issue, which is very similar to bug #379201.
If I'm connected to my home AP, then suspend my machine and wake it up somewhere else, NM tries to re-connect to my home network, even though it's not available in scans. It eventually times out, and I get prompted for a key / passphrase again.
Note, this happens on my new Macbook, which happens to use the Broadcom STA ( 'wl' ) driver. I've tried reproducing on my Macbook Pro which has an ath9k card and haven't been able to reproduce it yet.
ProblemType: Bug
Architecture: i386
CRDA: Error: [Errno 2] No such file or directory
Date: Thu Oct 15 17:46:04 2009
DistroRelease: Ubuntu 9.10
IfupdownConfig:
auto lo
iface lo inet loopback
IpRoute:
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.106 metric 1
169.254.0.0/16 dev eth0 scope link metric 1000
default via 192.168.1.1 dev eth0 proto static
NonfreeKernelMo
Package: network-manager 0.8~a~git.
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSign
RfKill:
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
SourcePackage: network-manager
Uname: Linux 2.6.31-14-generic i686
summary: |
- After Resume, NM tries to connect to previous, non-available Wi-Fi - network + [Broadcom wl]: After Resume, NM tries to connect to previous, non- + available Wi-Fi network |
description: | updated |
Changed in network-manager: | |
importance: | Unknown → Medium |
summary: |
- [Broadcom wl]: After Resume, NM tries to connect to previous, non- - available Wi-Fi network + After resume, NM tries to connect to previous, now non-available Wi-Fi + network -- happens with wl and not with ath9k |
Also, I tried killing NM and the applet, and reproducing it using 'iwlist scan'.
In my loft, I was able to run 'iwlist scan eth1' and see my home AP. I suspended, and went down to the lobby in my building, where I resumed, and ran 'iwlist scan eth1' again... this time I didn't see my home AP.
The only thing I can think of is that I may not be quick enough to see the scan results on resume due to the fact that I have 'check pw' enabled on my screensaver. More work is required to pin this down to the 'wl' driver.