RE: Connman behavior with marginally stabe wifi
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 +, 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
Re: Connman behavior with marginally stabe wifi
Hi Thiemo, 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. ConnMan does not manage any real wifi core logic, wpa_supplicant does: if a scan does not find a network (thus its BSS(s)), there is just no point telling it's still here. 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? Could be yes. It could even be implemented as a plugin I think. Also, having a retry limit would be nice, so you won't end up trying and trying a network for which you really don't have the right psk anymore. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Connman behavior with marginally stabe wifi
Hello all, We have a an embedded linux device that contains wpa_supplicant 2.2 and connman 1.25 to handle ethernet and wifi connections. This device is typically setup once and then gets very little attention and is often even hard to reach. 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. My first question is if this is known behaviour that it can fail with both of these errors? I would only expect connect-failed when the passphrase is correct. 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. 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? Thanks in advance. Regards, Thiemo van Engelen ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman behavior with marginally stabe wifi
Hi, On Thu, 2014-09-18 at 08:57 +, 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
Re: Connman behavior with marginally stabe wifi
On to, 2014-09-18 at 08:57 +, Thiemo van Engelen wrote: Hello all, 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? The controlling application can use the ConnMan session API to create the connections. See API description at http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/session-api.txt Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
