[PATCH] Add an option to suppress provision discovery during P2P Join

[Jithu Jance]

Hi Jouni,

I may not have understood the functionality correctly. Please Correct me, if I am wrong. 
Consider a scenario where a P2P client wants to Join P2P GO whose wps config method is
advertised as DISPLAY.

In this case, I think we have to use explicit provision discovery before issuing 
p2p_connect. The explicit discovery is used to retreive the PIN from GO side. 
Below mentioned are the commands that i have used. is there any other way to achieve this??


  Device A (P2P Client)					Device B (P2P GO with PIN DISPLAY)
-------------------------------------------------------------------------------------------
p2p_find

P2p_prov_disc <GO_DEV_ADDRESS> display           

                    			      PROV_DISC_SHOW_PIN EVENT >>> DISPLAY GO's PIN																			

   p2p_connect <GO_DEV_ADDR> <GO_PIN> join
   [since we have already done the PD, I think we shouldn't repeat it. 
    Otherwise the GO may regenerate the PIN on receipt of prov disc request.]

> How are you sending the Provision Discovery
> Request prior to p2p_connect join command? Please note that the Group ID
> attribute is added only in the p2p_connect join case and as such, a
> separate p2p_prov_disc command prior to p2p_connect would not actually
> send correct Provision Discovery Request frame.
The command that I have used is p2p_prov_disc <go_dev_addr> <req_config_method>
The prov disc req is sent from Client's p2p_device address interface. The group id
will only be created on the subsequent p2p_connect command. Is group id really 
required in this scenario??. Correct me, if my understanding is wrong.


> I see no point in having a global configuration option for doing this. It would
> be way too easy to result in non-compliant behavior with this.
> If this Provision Discovery Request needs to be skipped, the decision to
> do show better be conditional on a prior operation. In other words, this
> could either be done automatically based on an earlier Provision
> Discovery operation having been executed recently with the target GO or
> at least based on a parameter to p2p_connect.

Agree with you. The sending of provision discovery should be based on the availablity of provisioning info. 
But, if we store the provisioning info, when should it be cleared/reset?? Is it safe to assume that the 
provisioning info received for a particular GO will hold good till there is a change in advertised Config methods
or till DEVICE_LOST event??






- Jithu Jance

-----Original Message-----
From: hostap-bounces at lists.shmoo.com [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
Sent: Monday, November 21, 2011 10:20 PM
To: hostap at lists.shmoo.com
Subject: Re: [PATCH] Add an option to suppress provision discovery during P2P Join

On Mon, Nov 21, 2011 at 02:54:27AM -0800, Jithu Jance wrote:
> This patch adds an option to suppress provision discovery req during P2P Join. This is required in scenarios where a P2P client is connecting to a P2P GO that supports only PIN DISPLAY option. 
> The client side has to use the PIN displayed by the GO and we can't issue a p2p_connect on the client side till the PIN is known(since pin has to be entered along with p2p_connect command).
> 
> so in this case, we have to issue an explicit Provision Discovery before issuing connect command so that the GO can display its PIN and we can use the displayed pin in the subsequent p2p_connect command. 
> Since we have already done the PD, the "p2p_connect join" command shouldn't initiate another provision discovery.

This looks somewhat problematic and would likely not comply with the P2P
specification requirements. How are you sending the Provision Discovery
Request prior to p2p_connect join command? Please note that the Group ID
attribute is added only in the p2p_connect join case and as such, a
separate p2p_prov_disc command prior to p2p_connect would not actually
send correct Provision Discovery Request frame.

> Also, Please share your thoughts on adding an extra "no_pd" argument to p2p_connect command. 

That approach would be quite a bit easier to understand while I have
problems figuring out why this patch is adding a new configuration
parameter for unconditionally dropping the Provision Discovery prior to
joining a group.

I think this functionality would likely require an extension to
p2p_prov_disc command to allow it to specify which group is being used
(without this, Provision Discovery Request is for the purpose of forming
a new group; not for joining an existing group). With that added, it
should be easy to handle the rest automatically, i.e., p2p_connect join
should figure out whether to send Provision Discovery Request based on
whether p2p_prov_disc was used prior to it with the new parameter to
indicate which P2P group to target with the Provision Discovery Request.

> diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c
> @@ -763,6 +763,7 @@ static void wpas_p2p_clone_config(struct wpa_supplicant *dst,
> @@ -2503,6 +2504,17 @@ static void wpas_p2p_scan_res_join(struct wpa_supplicant *wpa_s,
>  			break;
>  		}
>  
> +		if (wpa_s->conf->p2p_suppress_pd) {
> +			/* If Provision Discovery is suppressed,
> +			 * Start join operation immediately. The Provision
> +			 * discovery in this case would have been explicitly
> +			 * initiated before the p2p_connect command.
> +			 */
> +			wpa_printf(MSG_DEBUG, "P2P: Provision "
> +				"Discovery Request from Join context suppressed");
> +			goto start;
> +		}

This does not look correct. P2P specification requires the Provision
Discovery Request to be sent prior to joining a running group. I see no
point in having a global configuration option for doing this. It would
be way too easy to result in non-compliant behavior with this.

If this Provision Discovery Request needs to be skipped, the decision to
do show better be conditional on a prior operation. In other words, this
could either be done automatically based on an earlier Provision
Discovery operation having been executed recently with the target GO or
at least based on a parameter to p2p_connect.

As a side note, this place to skip the p2p_prov_disc_req() call does not
look correct. pending_pd_before_join should not be set in that case (nor
is there much point in printing the debug message claiming that the
Provision Discovery Request is to be sent if that part is skipped).

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