Hi Patrik,

2014/1/3 Patrik Flykt <[email protected]>

>
>         Hi,
>
> On Thu, 2014-01-02 at 15:31 +0800, Chengyi Zhao wrote:
> > From: Chengyi Zhao <[email protected]>
> >
> > The WEP mode is specified, and has not 4way-handshake,
> > so wpa_supplicant does not provide any "invalid key message".
>
> The "missing" invalid key error for WEP has nothing to do with WEP not
> implementing 4 way handshake. WEP protocol is specified such that there
> is no indication of a wrong key.
>
> The approximately only way of detecting an invalid WEP key is to notice
> that traffic for this SSID cannot be decrypted. If this persists for
> some time, it is very likely that the WEP passphrase is incorrect.
>
> > For using the user passphrase, when user connectes the WEP mode AP
> > ConnMan need to requst the passphrase from the Agent.
> >
> > And this commit can fix the following issue:
> > Unable to connect with the WEP mode AP again with correct passphrase
> > if connecting the AP with wrong passphrase before.
> > ---
> >  src/service.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/service.c b/src/service.c
> > index 33cce14..c0ea7c5 100644
> > --- a/src/service.c
> > +++ b/src/service.c
> > @@ -5120,6 +5120,7 @@ static void request_input_cb(struct
> connman_service *service,
> >               /* We forget any previous error. */
> >               set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
> >
> > +             service->userconnect = FALSE;
>
> Userconnect set to false simply means ConnMan is autoconnecting by
> itself and no input is ever asked from an Agent. Should some input be
> needed with userconnect set to false, the service is set into an
> appropriate error state instead.
>
> So this change nukes our only knowledge of the connection being
> requested by an external entity, i.e. a user.
>

Thanks, I agree with you.


>
> >               __connman_service_connect(service);
> >
> >       } else if (err == -ENOKEY) {
> > @@ -5923,7 +5924,11 @@ int __connman_service_connect(struct
> connman_service *service)
> >               if (!is_ipconfig_usable(service))
> >                       return -ENOLINK;
> >
> > -             err = service_connect(service);
> > +             if (service->userconnect &&
> > +                     service->security == CONNMAN_SERVICE_SECURITY_WEP)
> {
> > +                             err = -ENOKEY;
>
> So if a user connects the service, the intention is suddenly to always
> (re-)ask for the WEP passphrase?
>

Maybe the saved WEP passphrase before that is wrong ,
so user connection when calling the function "connect_service" must
(re-)ask for the WEP passhprase.

>
> > +             } else
> > +                     err = service_connect(service);
> >       }
> >
> >       if (err >= 0) {
>
> Combined with the change above, err = service_connect() is run as
> before, but no Agent will ever be asked for any passphrases. I don't
> think this was intended.
>
> Another easy solution could be that the UI should just removes a WEP
> encrypted WiFi network instead of disconnecting it if the user tries to
> do so manually.
>
> Yes, user shouldn't connect a WEP encrypted WiFi network, and this is a
ConnMan's design practice,
it is very good, but the downstream product need to support the user case
which user connects a WEP encrypted AP.

So I will modify this patch, add a new flag to request the WEP passphrase,
and only merge it to the downstream product.

Thanks a lot.

Cheers,
Chengyi
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman

Reply via email to