Hi,

On Tue, 2015-09-15 at 17:19 -0700, Adam Moore wrote:
> Poor RF environments can cause connect-failed regardless
> of password correctness.  When performing a manual connection,
> the correctness of the password has not been proved. Clear the
> credentials in this case so they have an opportunity to be
> corrected if necessary.

Interesting. So wpa_s always reports that the network connect has failed
and never that a key is wrong in this situation? But is this due to the
RF environment beeing so poor that nothing goes through or is wpa_s
sending the wrong reason repeatedly when operating in bad RF conditions?

After applying this patch, ConnMan managed to connect in the same RF
conditions? If yes, wpa_s is a bit broken for this use case.

> ---
>  src/service.c | 40 ++++++++++++++++++++++++++--------------
>  1 file changed, 26 insertions(+), 14 deletions(-)
> 
> diff --git a/src/service.c b/src/service.c
> index 196f6b5..568300c 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -4048,6 +4048,24 @@ static DBusMessage *disconnect_service(DBusConnection 
> *conn,
>         return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
>  }
> 
> +static void clear_credentials(struct connman_service *service)
> +{
> +       g_free(service->passphrase);
> +       service->passphrase = NULL;
> +
> +       g_free(service->identity);
> +       service->identity = NULL;
> +
> +       g_free(service->anonymous_identity);
> +       service->anonymous_identity = NULL;
> +
> +       g_free(service->agent_identity);
> +       service->agent_identity = NULL;
> +
> +       g_free(service->eap);
> +       service->eap = NULL;
> +}
> +
>  bool __connman_service_remove(struct connman_service *service)
>  {
>         if (service->type == CONNMAN_SERVICE_TYPE_ETHERNET ||
> @@ -4064,20 +4082,7 @@ bool __connman_service_remove(struct connman_service 
> *service)
> 
>         __connman_service_disconnect(service);
> 
> -       g_free(service->passphrase);
> -       service->passphrase = NULL;
> -
> -       g_free(service->identity);
> -       service->identity = NULL;
> -
> -       g_free(service->anonymous_identity);
> -       service->anonymous_identity = NULL;
> -
> -       g_free(service->agent_identity);
> -       service->agent_identity = NULL;
> -
> -       g_free(service->eap);
> -       service->eap = NULL;
> +       clear_credentials(service);
> 
>         service->error = CONNMAN_SERVICE_ERROR_UNKNOWN;
> 
> @@ -5500,6 +5505,13 @@ int __connman_service_indicate_error(struct 
> connman_service *service,
>         __connman_service_ipconfig_indicate_state(service,
>                                                 CONNMAN_SERVICE_STATE_FAILURE,
>                                                 CONNMAN_IPCONFIG_TYPE_IPV6);
> +
> +       if (!service->favorite) {
> +               if (error == CONNMAN_SERVICE_ERROR_CONNECT_FAILED) {
> +                       clear_credentials(service);
> +               }
> +       }
> +

Here I rather like to have the error forcefully set to authentication
failed, as the code nowadays treats an authentication error identical to
an unset passphrase. This so that there is less confusion about special
cases where passphrases are cleared.

The poor RF conditions must also hit an already saved service. In the
patch above the idea seems to be that wpa_s will then report the error
properly, as it is known that the service was saved only if the
passphrase was correct. Unfortunately there seems to be a corner case
with this one also, in poor RF conditions when trying to connect to an
access point away from home with an identical SSID and security setup
but different passphrase (as it's a different network altogether),
ConnMan is now unable to connect as wpa_s always reports the connection
attempt having failed and not authentication error as it should...

I have to re-read the previous shortish mail thread again with this in
mind and think about how to minimize any brokenness. Ideas welcome!

Cheers,

        Patrik

_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Reply via email to