Re: [PATCH v3 10/12] wpa_supplicant: support Multi-AP backhaul STA onboarding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux