NM takes a long time to discover and connect to wifi after suspend/resume and roaming
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | network-manager (Ubuntu) |
High
|
Unassigned | ||
Bug Description
Starting around the time of the upload of NM 0.9.10.0, when suspending my laptop and roaming between locations, NM has started taking a long time to find the networks in the new location and connect to known essids.
Syslog to be attached.
Note that the first essid it tries to roam to, "Google Starbucks", is not present in either the pre-suspend location or the post-resume roamed location.
ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: network-manager 0.9.10.0-4ubuntu6
ProcVersionSign
Uname: Linux 3.18.0-8-generic x86_64
ApportVersion: 2.16.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Feb 25 15:18:10 2015
InstallationDate: Installed on 2010-09-24 (1615 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
IpRoute:
default via 192.168.1.1 dev wlan2 proto static metric 1024
169.254.0.0/16 dev vnet0 scope link metric 1000
192.168.1.0/24 dev wlan2 proto kernel scope link src 192.168.1.127
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
NetworkManager.
[main]
NetworkingEnab
WirelessEnable
WWANEnabled=true
WWanEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to vivid on 2014-12-06 (81 days ago)
WifiSyslog:
nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'.
| Steve Langasek (vorlon) wrote : | #1 |
| Steve Langasek (vorlon) wrote : | #2 |
| Steve Langasek (vorlon) wrote : | #3 |
I'll also mention that 'dfsgwpa' was the pre-suspend network I was connected to, and was not in range upon resume.
The nearest Starbucks was 320 meters away upon resume (and much farther on suspend), so was also not even remotely in range.
| Steve Langasek (vorlon) wrote : | #4 |
As requested, here's the output of 'iw dev wlan2 scan dump' when the problem occurs. Note that in this case the network I'm resuming on /is/ Google Starbucks ;)
Do you remember which network you were suspending on at that point?
I see some fairly old scan results, but nothing extraordinary (4, 14, 24 seconds, which seems consistent with NM's scanning thresholds). Still, the timing is such that there may have been a scan request or an automatic scan by the driver before the command was run. Could you attach a full syslog (or at least, containing kernel, wpasupplicant and NetworkManager messages) so that we know whether wpasupplicant has received scan results and when?
For lack of better options right now, it looks like this might "just" be stale scan results from the driver, but I'm also not noticing this kind of behavior on my very similar system.
| Changed in network-manager (Ubuntu): | |
| status: | New → Incomplete |
| importance: | Undecided → High |
| Launchpad Janitor (janitor) wrote : | #6 |
[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]
| Changed in network-manager (Ubuntu): | |
| status: | Incomplete → Expired |


syslog excerpts for Network Manager.