On 08/01/2019 12:04, Jouni Malinen wrote: > On Mon, Jan 07, 2019 at 03:56:24PM +0100, Arnout Vandecappelle wrote: >> On 20/12/2018 11:19, Jouni Malinen wrote: [snip] >>> 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. Unfortunately, the registrar doesn't tell us anything. The M8 does NOT contain the Multi-AP IE. However, wpa_supplicant_wps_cred has access to the current_ssid which has the multi_ap setting. In fact, this bit of the patch: + if (wpa_s->conf->multi_ap_backhaul_sta) + ssid->multi_ap_backhaul_sta = 1; + else + ssid->multi_ap_backhaul_sta = 0; is probably (I should check) redundant because the multi_ap_backhaul_sta bit is already set in wpas_wps_start_pbc(). I notice now, however, that the multi_ap_backhaul_sta option is missing from wpa_config_write_network(). > 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. Indeed I was mixing those two. > 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. OK, thanks. Regards, Arnout _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap