[PATCH] P2P: Fix inconsistency in displaying wps pin

[Jithu Jance]

Hi Jouni,


>> > p2p_connect 02:90:4c:12:34:56 pin display join
>> 78292024 <<<<<<<<<<<<<<<<<<<<<<<<<<<<< PIN Generated in the connect context
>> <3>P2P-PROV-DISC-SHOW-PIN 02:90:4c:12:34:56 23612945?<<<<<<<< Show Pin event.

> In this particular sequence, I don't really see much point in even
> displaying the P2P-PROV-DISC-SHOW-PIN event. In fact, it does not
> necessarily even get shown if the Provision Discovery Response is not
> received (there is no strict requirement on waiting for it in the case
> of p2p_connect join). As such, it could be better to just make this
> event conditional in a way that it is not indicated for p2p_connect join
> sequence.

Sorry that I didn't understand the above context properly. UI Application listens?
on P2P-PROV-DISC-SHOW-PIN ctrl event to?display the pin to user and the peer
uses this pin to activate wps pin session on his device. So without SHOW-PIN ctrl event, 
is there a?way to let the application know the about wps_pin to be displayed?

Do you mean that the pin returned by "p2p_connect pin display join" command should be used 
instead of waiting for SHOW-PIN event?? 
But this approach is inconsistent with the explicit provision discovery req - resp sequence used when the peer
is using keypad. In this case local device should display the pin and this display is done on SHOW-PIN event.

> (there is no strict requirement on waiting for it in the case
> of p2p_connect join). 

I understand that strict waiting for provision disc resp is not done during "p2p_connect join". This waiting is not necessary
when local device uses keypad/pbc option. But consider a scenario where local device chooses pin display 
method where the peer is expected to enter the PIN which local device displays., Here local device requires some event to
let the application know about the PIN it uses. Does it make sense to mandate pd response if the local device uses display
method??


>>?The attached patch doesn't generate PIN,
>> if the pin is already generated in the p2p_connect context.

> This is a bit problematic since wpa_s->p2p_pin does not get cleared and
> the same PIN would be used in number of operations where it was not
> supposed to be used.
?
Would the patch make sense, if the p2p_pin is cleared properly after?
wpas_start_wps_enrollee.???




- Jithu Jance


-----Original Message-----
From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
Sent: Saturday, December 10, 2011 3:47 PM
To: hostap at lists.shmoo.com
Subject: Re: [PATCH] P2P: Fix inconsistency in displaying wps pin

On Fri, Dec 09, 2011 at 03:28:35AM -0800, Jithu Jance wrote:
> When "p2p_connect <devaddr> pin display join" command is issued, the pin generated in the p2p_connect context and the SHOW-PIN event are 
> different. The PIN generated in the p2p_connect context is the one in use. The provision discovery response pin generation is useful when explicit
> provision discovery is done and then the generated PIN is entered via the subsequent p2p_connect command. The attached patch doesn't generate PIN,
> if the pin is already generated in the p2p_connect context. Kindly see whether the patch is okay.

This is a bit problematic since wpa_s->p2p_pin does not get cleared and
the same PIN would be used in number of operations where it was not
supposed to be used.

> > p2p_connect 02:90:4c:12:34:56 pin display join
> 78292024 <<<<<<<<<<<<<<<<<<<<<<<<<<<<< PIN Generated in the connect context
> <3>P2P-PROV-DISC-SHOW-PIN 02:90:4c:12:34:56 23612945 <<<<<<<< Show Pin event.

In this particular sequence, I don't really see much point in even
displaying the P2P-PROV-DISC-SHOW-PIN event. In fact, it does not
necessarily even get shown if the Provision Discovery Response is not
received (there is no strict requirement on waiting for it in the case
of p2p_connect join). As such, it could be better to just make this
event conditional in a way that it is not indicated for p2p_connect join
sequence.

> In case the below copy is whitespace damaged, please use the attached patch file.

The inline version was fine - thanks.

-- 
Jouni Malinen                                            PGP id EFC895FA
_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap