Network manager never scanning for new access points

[Ricardo Salveti]

While trying to reproduce another bug related with the last seen value from the access points, I noticed that network manager is never really scanning for new access points on my desktop, not even when not connected.

$ sudo nmcli g logging level debug domains wifi_scan

Then powered an access point, but was never really able to see it. From syslog, noticed that there is never really a scan, which explains why the ap never goes away and why it is not able to find it in the first place.

If I force a scan via cmdline it works as expected (and I noticed a scan also happens when changing connections).

Was also able to reproduce this issue on mako, with the following image:
phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 173
device name: mako
channel: ubuntu-touch/devel-proposed
alias: ubuntu-touch/vivid-proposed
last update: 2015-04-16 14:58:58
version version: 173
version ubuntu: 20150416
version device: 20150210
version custom: 20150416

In the mako case, I booted with a known connection in place, it connected successfully but it never really scans for other access points. Scan works fine after disconnecting though.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: network-manager 0.9.10.0-4ubuntu14
ProcVersionSignature: Ubuntu 3.19.0-14.14-generic 3.19.3
Uname: Linux 3.19.0-14-generic x86_64
ApportVersion: 2.17.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Apr 16 14:21:42 2015
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-10-29 (534 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
IpRoute:
 default via 192.168.1.1 dev wlan0 proto static metric 1024
 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
 169.254.0.0/16 dev lxcbr0 scope link metric 1000
 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.16
SourcePackage: network-manager
UpgradeStatus: Upgraded to vivid on 2013-10-31 (532 days ago)
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2013-11-04T02:19:36.923463
nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ivo Wever (ivo-wever)]

I'm seeing this as well: after upgrading to 15.04, I sometimes don't get automatically connected to my default network, because it hasn't been found yet. A manual 'sudo iwlist scan' is needed to get it to find the network, upon which it does automatically connect.

I installed a fresh copy of 15.04, retaining my home partition. /etc is entirely fresh

[Iain Lane (laney)]

I think I saw this bug on my laptop the other day. I did something like this.

1. Turn it on, log in
2. Look at the wireless list
3. Ah, there's no wifi here, I'll tether. Turn on the AP on my phone.
4. Wait for it to appear in NM so I can connect to it (or it auto connects if I've seen it before)

I waited about 5 minutes and the AP was never seen. Ended up restarting NM (sudo systemctl restart network-manager) and the AP was then seen and associated with. I didn't test comment #3's solution.

[Tony Espy (awe)]

It looks like this bug was introduced in Ubuntu when the rebase to NM 0.9.10.0 occurred.

The function supplicant_iface_scan_done_cb is missing a call to schedule_scan() which exists in the 0.9.8.x version of NM in utopic. It looks to me like the patch cull_aps_on_scan_done_signal.patch got mangled and lost its call to schedule_scan(). Furthermore, when this patch got re-worked and copied into the patch 0002-wifi-cull-the-scan-list-before-signalling-ScanDone-b.patch, the same mistake was carried over. I checked and all of the upstream releases of NM still have a schedule_scan() present in this function.

Here's a diff of the cull_aps_on_scan_done_signal.patch from NM 0.9.10.0 to the older 0.9.8.X version:

espy@shrike:% diff cull_aps_on_scan_done_signal.patch ~/dev/nm/nm-utopic-save/debian/patches/
10,14c10
< ---
< src/devices/wifi/nm-device-wifi.c | 29 ++++++++++++++++++++++++-----
< 1 file changed, 24 insertions(+), 5 deletions(-)
<
< Index: b/src/devices/wifi/nm-device-wifi.c
---
> Index: network-manager-0.9.8.8/src/nm-device-wifi.c
16,18c12,14
< --- a/src/devices/wifi/nm-device-wifi.c
< +++ b/src/devices/wifi/nm-device-wifi.c
< @@ -183,6 +183,10 @@ static void supplicant_iface_notify_scan
---
> --- network-manager-0.9.8.8.orig/src/nm-device-wifi.c
> +++ network-manager-0.9.8.8/src/nm-device-wifi.c
> @@ -200,6 +200,10 @@ static void supplicant_iface_notify_scan
29c25
< @@ -1609,14 +1613,20 @@ supplicant_iface_scan_done_cb (NMSupplic
---
> @@ -1810,14 +1814,22 @@ supplicant_iface_scan_done_cb (NMSupplic
50a47,50
> +
> + schedule_scan (self, success);
> }
>
52,54c52
< if (priv->requested_scan) {
< priv->requested_scan = FALSE;
< @@ -1836,13 +1846,22 @@ cull_scan_list (NMDeviceWifi *self)
---
> @@ -2005,13 +2017,22 @@ cull_scan_list (NMDeviceWifi *self)

I'll rebuild with the line restored and report results.

[Tony Espy (awe)]

Note, I've confirmed the behavior on arale, krilin and mako running the latest stable ( OTA5 ) images.

I've also confirmed on my desktop, a Thinkpad 410s with Intel WiFi ( driver=iwlwifi ).

The behavior can be see by running wpa_cli ( as root ). Initially after boot, scan_results will return a list of APs, but after time, it will start returning an empty list ( unless associated, in which case the current AP will be returned ). Also on a system running 0.9.8.X ( <= 14.10 ), you'll see periodic scan events reported by wpa_cli:

<3>CTRL-EVENT-SCAN-STARTED
<3>CTRL-EVENT-SCAN-RESULTS

[Tony Espy (awe)]

Just verified that restoring the call to schedule_scan in supplicant_iface_scan_done function of NMDeviceWiFi does the trick and re-establishes periodic WiFi scanning. Tested on a krillin running the latest stable ( OTA5 ) image. More testing required, but looks like this is a simple one-line fix...

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 0.9.10.0-4ubuntu19

---------------
network-manager (0.9.10.0-4ubuntu19) wily; urgency=medium

  [ Tony Espy ]
  * debian/patches/add_ofono_settings_support.patch: remove code
    that added APN, USERNAME and PASSWORD to NM_SETTING_GSM object.
    NM doesn't actually need access to these settings, and USERNAME/
    PASSWORD can cause issues with NM's secrets needed logic.
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1461593-add-nm-settings-connection-reset-retries-methods.patch,
    debian/patches/add_ofono_settings_support.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: More changes
    to NMModemOfono's modem_state handling. Added get/set_reset_retries_timeout
    methods to NMSettingsConnection, and use the set method to lower the timeout for
    ofono connections to 30s. Finally added a 5s delay to NM_POLICY's activation
    logic triggered when a modem device is disconnected. This allows modem time to
    settle and NM to process the resulting DBus state changes. (LP: #1461593)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/lp1445080-modify-device-modem-avail.patch,
    debian/patches/lp1445080-nm-modem-check-for-set-mm-enabled-func.patch,
    debian/patches/lp1461593-add-modem-reconnect-delay-to-policy.patch: These
    changes collectively fix flight-mode on arale ( and other devices ), due to
    some fundemental race conditions in the ofono logic. (LP: #1445080, #1440917)
  * debian/patches/0001-wwan-add-support-for-using-oFono-as-a-modem-manager.patch,
    debian/patches/add_ofono_settings_support.patch: Add support for the ofono
    gprs-context 'Preferred' property. (LP: #1361864)

  [ Mathieu Trudel-Lapierre ]
  * d/p/0002-wifi-cull-the-scan-list-before-signalling-ScanDone-b.patch:
    Re-add schedule_scan() call after we get the ScanDone signal from the
    supplicant. Otherwise we'd do one scan on startup and never scan again.
    (LP: #1445134)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 05 Aug 2015 12:17:28 -0400

[Tony Espy (awe)]

FixReleased as version 0.9.10.0-4ubuntu15.1.7 to ppa:ci-train-ppa-service/stable-phone-overlay.

[Tony Espy (awe)]

Changing Canonical System Image task to FixCommitted as 0.9.10.0-4ubuntu15.1.7 has landed in the latest rc-proposed images ( confirmed on krillin / rc-proposed / #102 which contains ubuntu version '20150818.1' ).