desktop-packages team mailing list archive

[Tony Espy <1425172@xxxxxxxxxxxxxxxxxx>]

Re-tested OTA5 images on arale, mako, and krillin.

Two scenarios:

1. Device connected to an AP
   - Android hotspot enabled, wait till it shows in the scan list
   - hotspot disabled, timer started
   - note time when hotspot disappears from scan list

2. Device ! connected to an AP; same steps as above.

I ran the scenarios three times each on all of the devices.  The results
looks to be pretty similar across all devices.  For the most part, it
takes ~6:30m for the hotspot to disappear from the list of APs exported
by NM.  In one case ( mako / connected ), the AP was never removed ( I
waited more than 15m ).  If I can reproduce this again, it'll require
some more investigation.

That said, I also discovered that the reason for the all the devices
having the same approximate time till the AP gets removed.  The
NMDeviceWiFi class is responsible for aging out access points.  It uses
a routine called cull_scan_list, which is invoked when a scan completes,
or NM gets notified of a BSS updated ( signal strength ) or a BSS
removed.  This routine will only remove an AP from the list when it's
last-seen time is >= 3 * MAX_SCAN_INTERVAL ( 2m ).  This is contrary to
Mathieu's assertion in comment #5.  When a bss_removed signal is
received from wpa_supplicant, a WPAS_REMOVED property is set on the
GObject, but the AP is *not* removed from the AP list till the
prune_interval ( 6m ) is exceeded.

I was able to verify this by running wpa_supplicant's command line tool
( 'wpa_cli scan_results | grep Android' ) in addition to nmcli.  After
2m, the AP disappears from wpa_supplicant's scan results, but not NM's.

I didn't actually verify the receipt of the 'bss_removed' signal in NM,
and will do so this afternoon.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1425172

Title:
  Network indicator lists the non-exist AP (timeout for the AP to be
  removed is too big, ~6min)

Status in Canonical System Image:
  Confirmed
Status in indicator-network package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed
Status in ubuntu-system-settings package in Ubuntu:
  Incomplete
Status in network-manager package in Ubuntu RTM:
  Invalid

Bug description:
  Summary: Network indicator lists the non-exist AP
  Steps to reproduce:
  1. Boot to system
  2. Scroll down the Network indicator
  3. It lists about 10 AP (In Taipei office)
  4. Go to another place and check network indicator again

  Expected Result:
  It should not list non-exist AP and only show available AP

  Actual Result:
  It shows about 12 AP on the screen but only two are real AP for connecting, and others 10 are from last list.

  This is reproducible on mako/krillin on both RTM and vivid.

  The main issue is that the timeout for the AP to be removed from the
  known AP list is too big when comparing with other phones.

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1425172/+subscriptions