7:17 p.m.
Hi Jose,
> On Aug 27, 2017, at 10:48 AM, Jose Blanquicet
<blanquicet(a)gmail.com <mailto:blanquicet@gmail.com>> wrote:
>
> In my initial idea I proposed to perform passive scan, no matter the
> BackgroundScanning value, when user performs a Scan() D-Bus call to
> ensure all networks are found. However, while trying to implement it
> and due to the reasons I explained before, I realized that it could
> also increase the auto-connection procedure with the default ConnMan's
> configuration, i.e. BackgroundScanning enabled. Therefore, I am now
> limiting this change to users who manually disabled
> BackgroundScanning.
>
> Patrik, Daniel, what do you think?
>
> Jonah, please test this patch:
>
Thanks for your efforts thinking through the code, and getting the patch put together!
I tested the patch you provided, and it does appear to solve the problem as described.
I'll promote that patch into my dev fleet, and let you know if I notice any other bad
behaviors.
I tested the patch you posted. While I never saw any dbus-requested scans failing, I did
notice an increase in the number of my dev units falling offline after a reboot. In each
case I've tested, as soon as dbus Scan() was initiated, the previously associated
network was seen and joined. While I haven't looked for exactly where, I am guessing
that there is some hole in the connman startup logic where it needs to request a wpa_s
Passive scan as well.
Perhaps it would be best to always follow an active scan with a passive one? Or perhaps
BackgroundScanning should just be forced to 'true'?
It seems that connman may be depending too much on somewhat undocumented behaviors of
wpa_supplicant and the cfg80211 driver layers, and it's being exposed to these bugs.
I'm curious for your thoughts! For now, I'm reverting to BackgroundScanning =
true.
Best,
Jonah