Ubuntu
network-manager package

NM takes a long time to discover and connect to wifi after suspend/resume and roaming

Bug #1425760 reported by Steve Langasek on 2015-02-26

6

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Ubuntu)	Expired	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
ProcVersionSignature: Ubuntu 3.18.0-8.9-generic 3.18.1
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.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
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'.

Tags:

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-02-26:

#1

CRDA.txt Edit (238 bytes, text/plain; charset="utf-8")
Dependencies.txt Edit (9.2 KiB, text/plain; charset="utf-8")
IfupdownConfig.txt Edit (574 bytes, text/plain; charset="utf-8")
IpAddr.txt Edit (1.5 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (613 bytes, text/plain; charset="utf-8")
NetDevice.eth1.txt Edit (838 bytes, text/plain; charset="utf-8")
NetDevice.lo.txt Edit (190 bytes, text/plain; charset="utf-8")
NetDevice.lxcbr0.txt Edit (257 bytes, text/plain; charset="utf-8")
NetDevice.virbr0.txt Edit (257 bytes, text/plain; charset="utf-8")
NetDevice.vnet0.txt Edit (321 bytes, text/plain; charset="utf-8")
NetDevice.wlan2.txt Edit (772 bytes, text/plain; charset="utf-8")
NetworkManager.conf.txt Edit (75 bytes, text/plain; charset="utf-8")
PciNetwork.txt Edit (1.2 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (313 bytes, text/plain; charset="utf-8")
RfKill.txt Edit (128 bytes, text/plain; charset="utf-8")
nmcli-con.txt Edit (117.2 KiB, text/plain; charset="utf-8")
nmcli-dev.txt Edit (1.2 KiB, text/plain; charset="utf-8")

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-02-26:

#2

nm-slow-roaming.log Edit (31.0 KiB, text/plain)

syslog excerpts for Network Manager.

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-02-26:

#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.

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-02-27:

#4

nm-debug.log Edit (29.1 KiB, text/plain)

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 ;)

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2015-03-04:

#5

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

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-05-04:

#6

[Expired for network-manager (Ubuntu) because there has been no activity for 60 days.]

Changed in network-manager (Ubuntu):
status:	Incomplete → Expired

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.