On Tue, Nov 20, 2018 at 11:42:25PM +0000, Marianna Carrera wrote: > > http://patchwork.ozlabs.org/patch/978101/ > > easymesh: add backhaul BSS support for WPS M8 > > - should not need wps_cred_processing_easymesh config parameter, i.e., > > presence of easymesh_backhaul_ap_settings is sufficient to determine > > whether the feature is enabled > > was discussed, we decided to keep the same approach as extra_cred. What about we change it for: > multiap_backhaul_ap_settings: if unset the feature is disabled, if set it points to an external file (if you agree with below) If this design were to be used, yes, that would be the way I would configure it. However, .. > > - cannot use hardcoded external file to build the Credential for > > backhaul STA since MAC Address attribute depends on the Enrollee's > > MAC address and changes for each device > > * configure needed SSID/passphrase/etc. parameters instead and allow > > hostapd to build this Credential dynamically when needed > > The one concern I have with creating a config param for each attribute to be added into the Credential TLV is that as far as I understand the WSC spec is very open on what TLV can be carried inside Credential, so we'd have to come up with a very inclusive long list of params, or a short list that may require code update in the future. Why would there be changes for this? The WSC tech spec is not going to be modified much, if at all, anymore, and we are talking about a very specific provisioning case here: how to provide credentials for the Multi-AP backhaul STA. This sounds like about as static case of WPS provisioning as there can be.. > What if we have the registrar, when the feature is enabled, to build the 0x100E attribute by concatenating the enrollee's mac address attribute (0x1020) with the binary blob from the external file (so to maintain the flexibility to add any attribute the multi-ap controller would send)? Are there other attributes that cannot be known a priori and stored in the external file? This sounds unnecessarily complex to me. I don't see why we would need to configure more than the SSID and passphrase/PSK of the backhaul BSS (assuming the same passphrase/PSK is used for each backhaul STA). All the other attributes within the Credential are either hardcoded or known to Registrar: - Network Index: deprecated, hardcoded to 1 - SSID: from new configuration parameter - Authentication Type: 0x0020 (WPA2-Personal) - Encryption Type: 0x0008 (AES) - Network Key Index: deprecated; not included - Network Key: from new configuration parameter - MAC Address: Enrollee's MAC Address - and that's it; no other attribute is applicable for this use case > > http://patchwork.ozlabs.org/patch/999135/ > > easymesh: add a config option to enable EasyMesh backhaul STA > > > comments: > > - rename "easymesh" to "Multi-AP" > What about easymesh_backhaul_sta --> multiap_backhaul_sta_en ? Need to coordinate with http://patchwork.ozlabs.org/patch/999587/ which uses multi_ap_enabled as a network profile parameter. I'm fine with either name (or well, I guess "_en" and "_enabled" postfix could really be removed), but I do not want multiple different ways of configuring this. > > - the commit message talks about adding a Multi-AP IE into > > (Re)Association Request frames, but this patch does not do that > > * simply remove that comment from the commit message(?) (i.e., handle > > (Re)Association Request frame in a separate patch) > > when re-submitting we'll remove that comment, and afaiu the handling is already covered by the patch below, so we don't need to submit a new one. Correct? Correct. > As far as the high level sequence, what I had in mind when we designed the two patches we submitted is the following (looking at the case where the fronthaul and the backhaul BSS are different BSSes, cause otherwise it's trivial): > > 1. A MAP agent that is not yet configured brings up only the station interface. > --> this is for a configuration software above hostapd to take care of (like PrplMesh) Is that "the station interface" referring to a new netdev/vif being created or would that use an existing main netdev (say, wlan0) of a radio? Or that does not matter here? The key point I'm trying to understand here is in whether wpa_supplicant would need to be involved in creating a new virtual interface here or would that always be assumed to be outside the scope of wpa_supplicant functionality for this sequence? > 2. This interface adds a Vendor Specific WFA Element of type MAP in Assoc Requests and M1. > --> this is covered partially by our http://patchwork.ozlabs.org/patch/999135/ patch, and partially by http://patchwork.ozlabs.org/patch/999588/ > > 3. This interface tries to do WSC push button with the fronthaul BSS of an existing agent > --> backhaul shall not have PBC enabled, so I think no need to restrict this explicitely. > --> upper layer software like PrplMesh need to ensure that "pressing the button" results in a single fronhaul BSS going into active PBC mode (likely requires user interaction to ensure we know which of the multi frouhaul SSID shall go into pairing mode) > > 4. The existing MAP Agent provides in M8 the credentials for the backhaul SSID: wpa_supplicant learns the credentials and associates with the backhaul SSID > --> this is the standard behavior asaik > > 5. The 1905 management layer (e.g., PrplMesh) starts the MultiAP-extended 1905 AP-Autoconfig exchange with the MAP Controller (some other entity in the LAN) > - This exchange uses M1/M2 messages to provide a full multi-SSID configuration to the agent. > - The 1905 management layer (e.g., PrplMesh) validates and parses the received configuration and: > 1/ prepares the external credential file for the backhaul SSID (which can likely be copied as-is from the M2 received in 1905 frame) > 2/ for each frounhaul BSS: writes the hostapd config (ssid/pwd/enable wps), enables multiap_backhaul_ap_settings feature by setting it to the external credential file path > 3/ for each backhaul BSS: writes the hostapd config (ssid/pwd/disable wps) > --> From now on, this new agent should be able to behave as the agent I mentioned in step 4 (assuming we fixed what we discussed above wrt to mac address attribute) > > Do you have a different understanding, or would you approach this differenlty? 2-4 sounds clear. For 5, I'm not that familiar with the design, but that sounds reasonable. However, please note comments above about the viability of using external credential file (i.e., I'd replace that with preparing hostapd configuration with, say, multiap_backhaul_ssid and multiap_backhaul_psk parameters for generating backhaul STA WPS Credential within hostapd). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
