Hi, I personally think it is strange behavior to depend on wpa_supplicant to remove the network, for connman to auto connect to a network again. And this will not work if, for some reason, a periodic scan occurs within 2 minutes. But ok... this is the case at this moment.
This however does not solve the following problem: When the network times out within wpa_supplicant, the service is indeed removed. However not all knowledge is removed because the settings are stored in /var/lib/connman/.../settings, including Failure=invalid-key. (As mentioned below, the invalid-key can occur during reconnection even though the key is correct). Now when the network appears again after a new scan, the data from /var/lib/connman/.../settings is loaded, including the Failure=invalid-key. This prevents connman from automatically reconnecting to this service. So connman will never reconnect to the network without intervention from an application. Is it perhaps an idea to have some form of configurable timeout that removes the failure (and invalid-key error) from the service, after which it re-evaluates the services list for auto connecting? This would relax the strain on picky networks, yet still allows reconnections without any interactions from other applications and without depending on the scan and flush behavior of wpa_supplicant? Regards, Thiemo -----Original Message----- From: connman [mailto:connman-boun...@connman.net] On Behalf Of Patrik Flykt Sent: 18 September 2014 15:24 To: connman@connman.net Subject: Re: Connman behavior with marginally stabe wifi Hi, On Thu, 2014-09-18 at 08:57 +0000, Thiemo van Engelen wrote: > We however have problems with the wifi connection, especially when it > is installed such that the wifi connection is marginally stable (and > there is no ethernet connection) What we see is that when the > connection is dropped (due to bad reception for example), connman > tries to reconnect which can fail, in which case connman goes into the > "failure" state with one of 2 errors: > "connect-failed" or "invalid-key". This depends on what wpa_supplicant actually reports back to ConnMan. My guess is that the connection was broken in the middle of the key exchange or similar in the second case. > What we also see is that connman does not try to reconnect, once it is > in the failure state. I would say that this is not the behaviour you > would want from an embedded device, as connman would need some > "attention" to come out of the failure state and retry. The other side of the coin is that if we do not disable retries to a failed network, we'd end up constantly banging on the network whenever we have a wrong passphrase or bad reception as in your case. This will lock out ConnMan from certain set of networks that allow only a limited amount of connection attempts. And since those access points put the ConnMan device on hold for quite a few hours before allowing further (re)connects, it's quite a mess. > When I look at my (android) phone, it retries to connect to my home > WIFI for example, even when I am at the edge of the router range. I > certainly never have to go into the WIFI menu because it is in some > failure state. > What is the reasoning behind this "failure" behaviour of connman and > can it perhaps be adjusted via the configuration? > Or is this typically solved in the controlling application on embedded > devices and if this is the case, does anyone have some pointers and > what and what not to do to get it going again without user > interaction? It is solved if the network is timed out by wpa_supplicant. At that point all temporary knowledge of the network and its state is cleared from ConnMan. Once it re-appears, it won't have any previous failed state associated with it and can be retried. When there is at least some form of UI, the user can always mitigate the issue by forcefully connecting to the failed network. Cheers, Patrik _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
