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 Ubuntu Touch seeded packages, which is subscribed to indicator-network 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
