On Mon, Jan 07, 2019 at 03:56:24PM +0100, Arnout Vandecappelle wrote: > On 20/12/2018 11:19, Jouni Malinen wrote: > > that it would be better to indicate this as a parameter > > specific to each instance of WPS provisioning, i.e., as a new optional > > argument to the WPS_PBC control interface command. > > That makes sense. > > > In other words, > > wpas_wps_start_pbc() should get this from the caller > > So an extra argument to wpas_wps_start_pbc, right? Yes. > I guess then it should be added also to: > > * wpa_cli; wpa_cli is already accepting arbitrary number of arguments to WPS_PBC. > * new D-Bus interface; If we expect this functionality to be used over D-Bus, sure. > * (for OpenWrt only: ubus interface); Sounds reasonable. > but not to: > > * old D-Bus interfae; > * p2p enrollment. Agreed. > And I'm not sure what to do with EVENT_WPS_BUTTON_PUSHED. But the only caller > of that is apparently some atheros driver. I'd ignore that for this, i.e., that wpas_wps_start_pbc() call should just note that there was no request for Multi-AP. > > and > > wpa_supplicant_wps_cred() should get this from a new field added into > > struct wps_credential. > > Wouldn't struct wps_data be more appropriate? It's not very clear to me where > that gets initialized though... But actually, the same goes for wps_credential. wpa_supplicant_wps_cred() gets called with information parsed from M8, so this should be filled based on what the Registrar told us. I don't see why struct wps_data would be involved in that part (i.e., processing of a received Credential). > Is it possible that both of these only get initialized after > wpas_wps_start_pbc() has already returned? Yes and not only possible, but that will happen in practice every time. > Maybe the best way to pass it on would be through the phase1 config string? > Although it feels like a bit of a hack to me, it looks like that is the way to > pass down context information into EAP, right? So this is a bit different direction, i.e., configuration of the local WPS Enrollee behavior for the request information while the comment about wpa_supplicant_wps_cred() was on how to process the response information. Anyway, yes, this is a bit complex due to the way the EAP peer implementation is kept as a separate module between core wpa_supplicant and WPS module. I did not consider details for that part, but yes, a new parameter within the phase1 config string seems to make most sense for getting information about the new optional WPS_PBC argument to the actual WPS Enrollee implementation which needs to generate the WSC messages with some additional information. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
