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.
Patrik, The solution, it turns out, is not that simple, at least for the application at hand. 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. Best, Grant _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
