© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
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:/
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:/
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:/
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.