Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: Connmanctl not able to connect via WPS_PIN entry
      (Jose Blanquicet)
   2. Re: Connmanctl not able to connect via WPS_PIN entry
      (Denis Kenzior)
   3. Re: Connmanctl not able to connect via WPS_PIN entry
      (Jose Blanquicet)


----------------------------------------------------------------------

Message: 1
Date: Thu, 17 Nov 2016 14:19:26 +0000
From: Jose Blanquicet <[email protected]>
To: [email protected], [email protected]
Cc: "[email protected]" <[email protected]>, SACHIN DEV SHARMA
        <[email protected]>
Subject: Re: Connmanctl not able to connect via WPS_PIN entry
Message-ID:
        <cafc8ijluu_hdfbrftffp4ycbrmhbj_0p6wunbmw_9ayh0hx...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

> > I am trying to use connmanctl to connect via WPS_PIN entry. Latest git code 
> > is not able to connect. ( pushbutton works though)
>
>
> > Logs:
> > connmanctl> agent on
> > Agent registered
> > connmanctl> connect wifi_0016ea684dcc_496e7370697265_managed_psk
> > Agent RequestInput wifi_0016ea684dcc_496e7370697265_managed_psk
> >   Passphrase = [ Type=psk, Requirement=mandatory, Alternates=[ WPS ] ]
> >   WPS = [ Type=wpspin, Requirement=alternate ]
> > Passphrase?
> > WPS PIN (empty line for pushbutton)? 12345678
>
> WPS PIN is checked for valid checksum in WPA Supplicant. So you can't use
>
> anything as WPS PIN. You can check wps_generate_pin() function to generate
>
> valid WPS PIN.

I agree that any 8-digit number cannot be used as PIN but
wpa_supplicant does not perform the checksum verification when it
receives the request from ConnMan to start WPS-PIN session, however
most of the common APs do perform such a verification. Therefore, in
Harish's case, the external AP is probably who is refusing the
connection because of the invalid PIN.

Just to make a quick example, in an scenario with a devices acting as
AP by means of wpa_supplicant and another one acting as STA using
wpa_supplicant + ConnMan, you will WRONGLY be able to get them
connected using the same toy PIN 12345678. All of this, because of
wpa_supplicant does not perform any verification on the PIN.

> > Agent ReportError wifi_0016ea684dcc_496e7370697265_managed_psk
> >   connect-failed
> > Agent request cancelled by ConnMan
> > Error /net/connman/service/wifi_0016ea684dcc_496e7370697265_managed_psk: 
> > Operation aborted
> > connmanctl>
>
>
> > Can anyone please inform if this is not yet implemented properly in connman?

Yes, it is already implemented and it works. However, current
implementation is not compliant with WFA WPS Technical Specifications,
we have been working on a new implementation to make it compliant and
we will send new version hopefully soon.

Regards,

Jose Blanquicet


------------------------------

Message: 2
Date: Thu, 17 Nov 2016 10:05:42 -0600
From: Denis Kenzior <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Connmanctl not able to connect via WPS_PIN entry
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi Jose,

 > Just to make a quick example, in an scenario with a devices acting as
> AP by means of wpa_supplicant and another one acting as STA using
> wpa_supplicant + ConnMan, you will WRONGLY be able to get them
> connected using the same toy PIN 12345678. All of this, because of
> wpa_supplicant does not perform any verification on the PIN.
>

Curious.  The WPS 2.0.5 spec does mention that checksum verification 
depends on the device password ID (DPID).  It is only verified when DPID 
is 'Default' and 8 characters long.

Does wpa_s use DPID of 'Default' and expects the UI to send a valid, 
checksum-correct PIN?

Regards,
-Denis





------------------------------

Message: 3
Date: Thu, 17 Nov 2016 20:34:17 +0100
From: Jose Blanquicet <[email protected]>
To: Denis Kenzior <[email protected]>, [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: Connmanctl not able to connect via WPS_PIN entry
Message-ID:
        <CAFC8iJ+Q-2K5=8oewsmbiqxeuqmcq06k1s4fydqp+cdcnwk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Denis,

>> Just to make a quick example, in an scenario with a devices acting as
>>
>> AP by means of wpa_supplicant and another one acting as STA using
>> wpa_supplicant + ConnMan, you will WRONGLY be able to get them
>> connected using the same toy PIN 12345678. All of this, because of
>> wpa_supplicant does not perform any verification on the PIN.
>>
>
> Curious.  The WPS 2.0.5 spec does mention that checksum verification depends
> on the device password ID (DPID).  It is only verified when DPID is
> 'Default' and 8 characters long.

You just pointed out something really important that I missed, PIN
must be ONLY verified in case DPID is 'Default' (PIN not manually
entered by users) and both Harish scenario and my example are not
'Default'; they are actually 'User-specified' thus PIN should no be
verified in any of those two cases. This behaviour has completely
sense because final users are not expected to compute checksums for
PIN they choose.

According to the previous clarification, in Harish's case what is
wrong is that wpa_supplicant sends a PIN (Which was chosen by the
user) with 'Default' as DPID, this causes that the AP checks the PIN
and replies error because 12345678 does not pass checksum validation,
at least the APs compliant with WPS specifications will follow this
procedure. To solve this, wpa_supplicant should use 'User-specified'
as DPID then the AP will not check the checksum and the connection
will success. On the other hand, in my example, the connection is
successful because both sides are using wpa_supplicant, and AP side is
not checking the PIN is valid, even if the DPID is 'Default'.

Do everybody agree? However, in my opinion this is not a ConnMan's
issue thus this discussion should move to wpa_supplicant mailing-list.

Regards,

Jose Blanquicet


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 13, Issue 26
***************************************

Reply via email to