Hi Daniel,
Sorry for the delayed reply
>> So the problem is that autoconnect is faster than
scan,connect operation?
> Yes, autoconnect is scheduled just after old service is disconnected, scanning
> new service is taking around 3secs at my setup, so autoconnect is faster
> than scan,connect operation.
Okay, good we are the same page :)
>> I am very reluctant to move the for() loop down from
connect_service()
>> to service_connect() because it is not clear to me what the impact of it
>> is. If I read it correctly D-Bus initiates connection attempts wouldn't
>> change because the filter is just deeper down in the call change. Is it
>> really only the calls from autoconnect which will be blocked?
> Yes, with this patch only calls from autoconnect will be blocked because old
> service will never be disconnected until connection is initiated for new hidden
> AP.
The thing is service_connect() is called from a bunch of places
inside
ConnMan. Currently it will just do what the names says, it connects the
service. With your change it will suddenly start to filter commands.
That is what I do not like about it. For example we have the Session
plugin API which allows to write your own autoconnect if need to. With
the filter at service_connect() we change the behavior of the API. I
would like to understand what this change means.
>> Maybe you should try to teach autoconnect not to call
>> __connman_service_connect() when we try to connect to a hidden AP? In my
>> eyes it makes more sense to teach autoconnect not to do stupid stuff
>> instead of blocking it somewhere else.
> This patch gives me flexibility that old service is not disconnected until new
> hidden service is found in scan list. There is a scenario when user enters wrong
> AP name for hidden AP or WPA Supplicant/Driver fails to scan hidden AP then also
> currently old service will be disconnected before initiating scan for hidden AP.
I am not saying your use case is not correct or invalid.
> This patch will allow old service to remain in connected state
for more time(time
> when we are only scanning hidden AP to find if it is available) and would only
> disconnect when required(hidden AP is found in scan).
But we still disconnect before we connect the hidden service which
can
fail too. So you just keep the current connection open a bit longer
before trying to connect to the hidden AP.
I would say we have two different things here:
1) try to stay connected as long as possible
2) autoconnect faster than hidden AP scan/connect operation
If we leave out 1) for a minute, I still think autoconnect should
not
attempt to connect a service when we have a connect request from the
user. This is not special to wifi come to think of it. I would really
like to see if you can come up with something which makes autoconnect a
bit smarter about this scenario?
I've now blocked autoconnect for wifi when we have hidden connect request
from user. Updated patch can be found at
https://lists.01.org/pipermail/connman/2016-November/021116.html
Thanks,
Saurav