On 20/12/2018 11:19, Jouni Malinen wrote: > On Wed, Dec 05, 2018 at 11:24:00AM +0100, Arnout Vandecappelle (Essensium/Mind) wrote: >> Introduce a new, global configuration option multi_ap_backhaul_sta to >> enable this feature. It has to be separate from the per-SSID >> multi_ap_backhaul_sta option since no SSID exists yet when WPS is >> performed. multi_ap_backhaul_sta is set to 1 in the automatically >> created SSID. Thus, if the AP does not support Multi-AP, association >> will fail and WPS will be terminated. > > Why would this configuration parameter be needed? I thought I already > suggested I either missed that or misinterpreted it. > 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? I guess then it should be added also to: * wpa_cli; * new D-Bus interface; * (for OpenWrt only: ubus interface); but not to: * old D-Bus interfae; * p2p enrollment. And I'm not sure what to do with EVENT_WPS_BUTTON_PUSHED. But the only caller of that is apparently some atheros driver. > 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. Is it possible that both of these only get initialized after wpas_wps_start_pbc() has already returned? 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? Regards, Arnout _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
