Sorry for the delayed reply
>> So the problem is that autoconnect is faster than
> 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
>> 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
The thing is service_connect() is called from a bunch of places
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
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
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