On 9/17/15, 5:42 AM, "connman on behalf of Patrik Flykt"
<[email protected] on behalf of [email protected]>
wrote:
>
> 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.
This only happens occasionally. I don¹t know what the underlying cause of
the first connect-failed was - I guess something got through since I
didn't get an out-of-range error. I¹ll get some better logs and find out.
The patch doesnt guarantee that Connman will to connect the next time, as
the poor conditions still exist, just that it won¹t be performing any
futile subsequent attempts with a bad password.
>
>> ---
>> 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
>[email protected]
>https://lists.connman.net/mailman/listinfo/connman
Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential and
are intended solely for the addressee. The information may also be legally
privileged. This transmission is sent in trust, and the sole purpose of
delivery to the intended recipient. If you have received this transmission in
error, any use, reproduction or dissemination of this transmission is strictly
prohibited. If you are not the intended recipient, please immediately notify
the sender by reply e-mail or at 508.683.2500 and delete this message and its
attachments, if any.
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
