Hi Jouni, thanks a lot for reviewing the patches. > http://patchwork.ozlabs.org/patch/978101/ > easymesh: add backhaul BSS support for WPS M8 > - rename "easymesh" to "Multi-AP" > - 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) > - 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. 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? > 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 ? > - wps_build_vendor_ext_m1_wfa() adds a new WFA vendor extension into M1 > even though wps_build_wfa_ext() has already done that for the other > WFA vendor extensions; this does not look correct, i.e., there should > be only a single WFA vendor extension attribute that would include the > existing extensions (e.g., Version2) and the Multi-AP extension; > wps_build_wfa_ext() would need to be extended instead of adding a new > function We'll change and resubmit. > - 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? > - would be good to review high level sequence of backhaul STA addition > and the needed driver configuration steps; including how the dynamic > multi_ap_enabled config parameter changes are used (and if they are > really needed) > - Multi-AP IE parsing needs to be aware of multiple possible subelements > - should not break non-Multi-AP case in association event processing > - should use a single helper function to build all different cases of > Multi-AP IE contents 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) 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? Best, --Marianna Carrera _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
