Jose Blanquicet <blanquicet(a)gmail.com> writes:
On Mon, Sep 4, 2017 at 9:31 AM, Daniel Wagner <wagi(a)monom.org>
> On 08/27/2017 04:48 PM, Jose Blanquicet wrote:
>> On Thu, Aug 24, 2017 at 7:33 PM, Jonah Petri <jonah(a)sense.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
>> Patrik, Daniel, what do you think?
> This behavior is wpa_s specific, right? IIRC, iwd handles all this stuff on
> its own.
Yes, it is. And yes, AFAIK iwd does; in fact the wifi plugin is the
only one who implements scan function, that's why I could modify its
parameters without affecting any other plugin. Maybe we should avoid
to modify the connman_device_driver and keep this modifications inside
wifi plugin which makes the patch simpler and we must mention in
documentation that by disabling this feature it could increase the
auto-connection time by very few seconds (because active scanning
method will not be use). I am not sure whether we should include the
last part within parenthesis or not.
Agree, those wpa_s specific changes should not leak into the common code
> Anyway it's sound reasonably to me with the assumption that
> BackgroundScanning is enabled on most system.
Yes, but unfortunately I have to say that this is not the "ideal"
solution (Which would be much more complex). To do so, we should let
the current management of active and passive scanning as it is and
launch a delayed passive scan after the active one when user asks for
scanning. The rough steps would be:
1. User asks for scanning through a Technology.Scan() D-Bus call
2. ConnMan performs an active scan looking for the knwon-services read
3. Give enough time to ConnMan in order to start auto-connect
procedure in case any of the knwon-services it was looking for is in
range. This step is the most important one because if we launch a new
scan right after then the previous scan is useless because its aim is
to perform a fast scan looking specifically for those knwon-services
and speed up the reconnection.
4. Otherwise, if ConnMan does not get connected (Any known-service is
in rage) then launch a passive scan.
6. Do not launch any additional scan until step (1) occurs again.
What do you suggest?
It is a bit confusing with all the different strategies. Your
suggenstion makes sense since it should fix the initial bug report. The
tricky part will be step 3. How long is 'enough time' :)