desktop-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

I managed to hack up wpa_supplicant such that it artificially adds a
hard-coded set of non-existent APs every scan.  It's not a pretty patch,
but it served the purpose of ramping up the DBus traffic generated by NM
significantly on each scan.

See: https://code.launchpad.net/~awe/wpasupplicant/add-fake-aps

I was able to get the UI ( the app switcher animation more specifically
) to freeze up for anywhere from 4-6s whenever a Wi-Fi scan occurred.  I
currently have the patched wpa_supplicant adding 125 APs to the list,
which results in a total of 175 APs in the scan results seen in my loft.

I also looked a bit more closely at the touch-specific change which
introduced NM's AccessPoint 'LastSeen' property. This was made in
response to a private bug that was reported during the development cycle
of the HERE code for the phone.   The original complaint was about
access points becoming stale in the scan results, resulting in skewed
locations.  wpa_supplicant's AccessPoint object exposes an 'age'
property, but it's not exposed by NetworkManager.   So a 'LastSeen'
property was added to NM's AccessPoint object, and it gets updated by
bss_updated_cb() in nm-device-wifi.c.   It looks like for every
scan_result, bss_updated signal is being generated for every AccessPoint
in the scan results ( note, NM doesn't even look at which property
changed... so it's hard to tell which property is triggering this on
every scan; most likely it's Strength which is randomly assigned in my
hack ).

The original HERE bug stated that it queries the available networks, so
we'll need to check if it's truly reliant on these signals or not.  It
might be possible that addition of the property to query results is
enough ).

In the meanwhile, I've built a test version of network-manager with the
property-changed notifications for 'LastSeen' removed.  It can be found
in my PPA: https://launchpad.net/~awe/+archive/ubuntu/ppa

A quick test shows that this change makes the UI stuttering much less
severe ( maybe <= 1s stutter ).

Note, NM is basically propagating the same set of signals as
wpa_supplicant sends.  In theory, this shouldn't be enough to saturate
the bus.  If it is, then we're really pushing the limits of the system.

One other theory is that we have applications and/or subsystems that are
using overly broad DBus match rules.  For more details on this, please
see:

https://www.collabora.com/about-us/blog/2014/10/06/improving-the-
security-of-d-bus/

It *might* be possible to run dbus-1.10 from wily, which includes some
debug tools which would allow us to more easily examine the match rules
currently in use on our images.

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