Comment 37 for bug 1480877

I installed bustle on my krillin this afternoon to try and glean some more information from the system DBus. I few observations...

1. The top signal on the system bus is:

org.freedesktop.NetworkManager.AccessPoint.PropertiesChanged

2. Most of these seem to be for a specific AP ( instance 0 ), which I'm pretty sure is the current connected AP. The associated property is 'Strength'. This makes sense, as NM constantly reports the varying signal strength of the AP. These are happening all the time, and I typically see them in bursts of two or three signals.

3. As scans typically occur anywhere from 20s to 2m, when they do occur, we see a flurry of AccessPoint.PropertiesChanged signals representing the changing signals strengths of each access point. There also are AccessPoint.PropertiesChanged signals for the 'LastSeen' property. I'm pretty sure this property was added specifically for the LocationService. Note, ideally this signal would be bundled with the associated 'Strength' signal, however due to the way NM's underlying object/property system was architected, this doesn't seem to be an easy change at first glance. Note, these LastSeen signals are consumed by the LocationService's 'connectivity API' ( which I'm pretty sure uses dbus-cpp ).

So... we still need to quantify how many APs trigger the problem, and if it's being triggered whenever scans occur. In comment #29, Pat mentioned that it happened when he initially arrived in Bluefin, but went away once he connected to an AP. As background scanning had recently been restored in NM, I would've assumed he would continue to see the issue each time a scan was occurred, even when connected.

It also would be interesting to see whether disabling location service has any effect on the problem ( if we can reproduce reliably of course ).

Perhaps I can dummy up wpa_supplicant to push an artificial number of APs to NM and see if I can trigger the problem locally.