Hi Jouni,<div><br></div><div><br></div><div>> I implemented this a bit differently in commit<br>> c19316354ed46e688704c1ebcf1c7efe816ddf31 by skipping the > PD Response notifications in PD-before-join case regardless of</div>
<div>> what config method was requested. This looks like the most</div><div>> consistent and cleanest approach here.<br>> This will also require another commit for some cases where the </div><div>> PD Response could have been processed after having already </div>
<div>> started the scan for the join operation. Commit </div><div>> f63b8542156496ba88ef9f161e5931122d7319b9<br>> makes wpa_supplicant wait for the PD Response prior to </div><div>> continuing the join with the scan-for-connection step. <br>
<div><br></div><div>Your commits looks good to me and addresses my requirements. Thanks!! :)</div><div><br></div><div><br></div><div><br></div><div><br></div><div>- Jithu Jance<br><div><br></div><div><br><div class="gmail_quote">
On Mon, Feb 6, 2012 at 12:32 AM, Jouni Malinen <span dir="ltr"><<a href="mailto:j@w1.fi">j@w1.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Dec 26, 2011 at 09:23:54PM -0800, Jithu Jance wrote:<br>
> Sounds like for "p2p_connect <devaddr> pin display join" command, suppressing Prov Disc SHOW-PIN would be a better<br>
> approach.<br>
<br>
Agreed.<br>
<br>
> I would also like to confirm about the handling of wpas_notify_p2p_provision_discovery<br>
> in this particular scenario. Is it okay to invoke the function with generated_pin = 0 value (the below patch uses this approach)<br>
> or should I suppress the invocation of wpas_notify_p2p_provision_discovery when wpas->p2p_pin is populated??<br>
<br>
I think it is better to skip this call completely. Actually, these<br>
provision discovery response notifications should really be skipped<br>
completely in the automatic PD-before-join case since those were not<br>
explicitly requested by any external program and they do not really<br>
provide any additional information.<br>
<br>
> diff --git a/wpa_supplicant/p2p_supplicant.c b/wpa_supplicant/p2p_supplicant.c<br>
> @@ -1785,8 +1785,7 @@ void wpas_prov_disc_req(void *ctx, const u8 *peer, u16 config_methods,<br>
> -<br>
> - if (config_methods & WPS_CONFIG_DISPLAY) {<br>
> + if ((config_methods & WPS_CONFIG_DISPLAY) && (wpa_s->p2p_pin[0] == '\0')) {<br>
> generated_pin = wps_generate_pin();<br>
<br>
Why would we need to modify prov_disc_req callback? This is not used on<br>
the P2P device that will be joining a group as a P2P client.<br>
<br>
> @@ -1809,7 +1808,7 @@ void wpas_prov_disc_resp(void *ctx, const u8 *peer, u16 config_methods)<br>
> if (config_methods & WPS_CONFIG_DISPLAY)<br>
> wpas_prov_disc_local_keypad(wpa_s, peer, "");<br>
> - else if (config_methods & WPS_CONFIG_KEYPAD) {<br>
> + else if ((config_methods & WPS_CONFIG_KEYPAD) && (wpa_s->p2p_pin[0] == '\0')) {<br>
> generated_pin = wps_generate_pin();<br>
> wpas_prov_disc_local_display(wpa_s, peer, "", generated_pin);<br>
> } else if (config_methods & WPS_CONFIG_PUSHBUTTON)<br>
<br>
While this could be fine for most cases, I don't really want to depend<br>
on wpa_s->p2p_pin getting cleared in all cases. I guess this could<br>
potentially skip an event message for Provision Discovery that is done<br>
in other contexts.<br>
<br>
I implemented this a bit differently in commit<br>
c19316354ed46e688704c1ebcf1c7efe816ddf31 by skipping the PD Response<br>
notifications in PD-before-join case regardless of what config method<br>
was requested. This looks like the most consistent and cleanest approach<br>
here.<br>
<br>
This will also require another commit for some cases where the PD<br>
Response could have been processed after having already started the scan<br>
for the join operation. Commit f63b8542156496ba88ef9f161e5931122d7319b9<br>
makes wpa_supplicant wait for the PD Response prior to continuing the<br>
join with the scan-for-connection step. This is also cleaning up the<br>
sequence of driver operations in the join step and can make it somewhat<br>
easier for some drivers to handle the remain-on-channel/offchannel TX<br>
and scan.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Jouni Malinen PGP id EFC895FA<br>
_______________________________________________<br>
HostAP mailing list<br>
<a href="mailto:HostAP@lists.shmoo.com">HostAP@lists.shmoo.com</a><br>
<a href="http://lists.shmoo.com/mailman/listinfo/hostap" target="_blank">http://lists.shmoo.com/mailman/listinfo/hostap</a><br>
</font></span></blockquote></div><br></div></div></div>