On 3/11/21 3:06 PM, VAUTRIN Emmanuel (Canal Plus Prestataire) wrote:
The failure state may not always result from a bad connection.
For security matter, as a password renewal, the AP may disconnect the
station, and finally completely block it, after several inappropriate
retries, due to auto connection with former password.
src/service.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/service.c b/src/service.c
index a24dea729545..cd939320d3d5 100644
@@ -3447,16 +3447,22 @@ static void do_auto_connect(struct connman_service *service,
reason == CONNMAN_SERVICE_CONNECT_REASON_NONE))
+ * Only user interaction should get VPN or WIFI connected in failure
+ * state.
+ if (service->state == CONNMAN_SERVICE_STATE_FAILURE &&
+ reason != CONNMAN_SERVICE_CONNECT_REASON_USER &&
+ (service->type == CONNMAN_SERVICE_TYPE_VPN ||
+ service->type == CONNMAN_SERVICE_TYPE_WIFI))
Could this be treated in some other manner as I suspect (I haven't
tested this at all yet) that in mobile environment when AP is shut down,
lost or it simply crashes and does not get up instantly (put down for
maintenance) the service may end up in failure state? In that case user
interaction would not be required for re-connecting and autoconnect
should handle that case. But I understand your point here that
repeatedly re-connecting has its downsides as well.
We have our own implementation of the WiFi plugin and I haven't tried
with the plugin upstream has so this is just a guess/concern from my part.
So, if the WiFi plugin can in the cases I described result in failure
state this may need some re-thinking. If not, please ignore this :)
* Run service auto connect for other than VPN services. Afterwards
* start also VPN auto connect process.
if (service->type != CONNMAN_SERVICE_TYPE_VPN)
- /* Only user interaction should get VPN connected in failure state. */
- else if (service->state == CONNMAN_SERVICE_STATE_FAILURE &&
- reason != CONNMAN_SERVICE_CONNECT_REASON_USER)