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
[email protected]
https://lists.connman.net/mailman/listinfo/connman
