desktop-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

And more detail...

So looks like the double wpa_supplicant signals are harmless ( other
than wasting bandwidth ) as the NM's supplicant manager uses the correct
'org.freedesktop.DBus.Properties' interface when it creates the proxy
for each new BSS.

It looks like a change introduced by the patch '0002-wifi-cull-the-scan-
list-before-signalling-ScanDone-b' may be the culprit at the NM level.
The intention was to ensure that the 'last-seen' property was updated
for all APs in the scan list before the 'ScanDone' signal is generated.
So, in nm-device-wifi.c::scan_done_cb(), a schedule_scanlist_call() was
turned into a direct call to cull_scan_list().  Also, the
cull_scan_list() function was changed to update last_seen for every AP
in the current list.

There are a few other places though that trigger update_last_seen()
calls.   Both bss_new_cb() and bss_updated_cb() call
schedule_scanlist_cull() before returning.  Also bss_updated_cb() also
calls update_last_seen() directly!

schedule_scanlist_cull() guards against duplicate scheduling, and uses a
4s timer to schedule the next call to cull_scan_list().

Note, update_last_seen() was modified to guard against setting the
property if the value hasn't changed.

So... the original code would get a scan_done_cb() and schedule a
scan_list cull.   Next it would get a series of new and/or updated bss
callbacks which each would schedule their own cull.  You see where I'm
going with this...  In theory, all of these would just result in a
single scan_list cull which didn't even touch the last_seen ( it was
only updated by bss_updated ).  With the current code, at least two
calls to scan_list_cull() occur after a scan.  Also, it's possible that
a direct modification of last-seen in bss_updated_cb () could also
contribute some extra signals depending on timing...

I *think*, the correct thing to do is to leave scan_done_cb() as the
sole place that updates last_seen.  This will prevent duplicate signals
for the time being.

It still remains to be seen whether we can get rid 'last-seen'
altogether.

-- 
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/1480877

Title:
  Access points' "PropertiesChanged" dbus signals freeze UI on mobile
  devices

Status in Canonical System Image:
  Confirmed
Status in indicator-network package in Ubuntu:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Krillin, rc-proposed, r83

  
  DESCRIPTION:
  I've been trying to track down the cause of the occasional UI freezes on my Krillin device, and I noticed that whenever the UI freezes for 2-4 seconds, I get a burst of "PropertiesChanged" signals in dbus-monitor

  Here's a log of what's shown in dbus-monitor:
  http://pastebin.ubuntu.com/11992322/

  I'd guess the problem is in the code that actually catches the signals
  and acts accordingly.

  HOW TO REPRODUCE: 
  1) Move to a place where many wifi hotspots are available
  2) Connect the device via USB and run "phablet-shell" and then "dbus-monitor"
  3) Use the device while keeping an eye on dbus-monitor output

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