Network manager never scanning for new access points

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

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

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.

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.

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

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

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

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

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' ).