On Oct 13, 2015, at 11:01 PM, Patrik Flykt <patrik.fl...@linux.intel.com> wrote:
> On Tue, 2015-10-13 at 14:42 -0700, Naveen Singh wrote:
>> There is nothing that application knows that connman does not know.
>> In fact application gets to know through connman that connection did
>> not go through. The way application gets connected back is to initiate
>> a scan and hoping that one of these scan would find the AP (or
>> services) and then run autoconnect would trigger and get device
>> connected. But in this case run autoconnect would not attempt
>> connection because service state was left to failure.
> This approach won't work at all. When ConnMan receives a Scan() over
> D-Bus, it will scan immediately and reset its own autoscan timer. Which
> means that if the application issues a scan after less than ~6 minutes,
> it causes ConnMan to scan so often that wpa_s never times out its WiFi
> networks. So if the service has failed, it has failed for all eternity.
> The solution here is very simple. Get rid of the application assisted
> scan and let ConnMan handle it instead.


The solution, it turns out, is not that simple, at least for the application at 

This particular application is embedded, largely user-unattended, and sleepy 
(from a CPU perspective). It must work day-in, day-out, week-in, week-out, 
month-in, and month-out without user intervention after the user has 
interactively established the first initial connection.

Due to these constraints, the application knows best when to scan and does so 
at its discretion. Neither connman nor wpa_s autoscan infrastructure scan at 
the application-desired times. When they do scan automatically, it typically 
results in one or both of an undesirable expenditure of power or a momentary 
and inopportune move off-channel.

Absent the proposed change, per doc/overview-api.txt, with a WiFi network 
continually refreshed, there is no exit path from the Failure service state 
and, consequently, no unattended means by which the application can recover 
WiFi connectivity under these circumstances in a deterministic and 
application-controlled way.

The proposed change offers, for unattended applications that wish to avail 
themselves of it, an exit gate to effectively acknowledge a service error by 
clearing it. There is no downside or consequence to interactive applications 
that wish to continue to operate as they do today.



connman mailing list

Reply via email to