Hi,
On Fri, 2013-12-20 at 17:41 +0800, Chengyi Zhao wrote:
> @@ -1425,6 +1426,21 @@ static int network_disconnect(struct connman_network
> *network)
> if (!wifi || !wifi->interface)
> return -ENODEV;
>
> + if (connman_network_get_associating(network) == TRUE)
As Tomasz commented, network_disconnect() is called only when the user
manually disconnects from the network. So the association check works
only when the user gets tired of waiting for the network to connect, it
has no relevance for any other use case.
> - if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY)
> + if (service->error == CONNMAN_SERVICE_ERROR_INVALID_KEY ||
> + (service->favorite == FALSE &&
> + service->error == CONNMAN_SERVICE_ERROR_CONNECT_FAILED))
> __connman_service_set_passphrase(service, NULL);
This does not work as expected. If a service error is
CONNMAN_SERVICE_ERROR_CONNECT_FAILED, it may be caused by a too long
distance to the AP. If the device is close enough, it *will* succeed in
connecting with an invalid passphrase, wait for an IP address and claim
it's connected successfully since WEP does not report authentication
errors by design. Once configured with an IPv4 address, static or link
local in this particualar case, favorite is set for the service and this
test will stop working. In general it's not a good idea to blindly wipe
out passphrases as WPA will know if that was the problem.
I don't remember how fast an link-local IPv4 address gets generated, but
I'd suspect it is, or, in the worst case for this patch, will be fixed
to happen too quickly for the patch to make any difference.
No, I'm not applying this patch upstream.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
