Hi all, Ying Lu, Venkateswara, please note the call to action below. On 20/11/2018 00:23, Jouni Malinen wrote: [snip] > Based on my review, quite a few changes beyond merging these together is > going to be needed, I agree. In fact, it's likely that a few iterations will be needed. > so it would probably be better if someone else (or > multiple people with some coordination) would volunteer to propose > updated patches with changes to address the comments. OK. Ying Lu and Venkateswara, is there any chance that either of you could combine these patches and integrate the comments? > Other than the > configuration details, most of the changes look straightforward and also > the four patches are mostly independent in core functionality in areas > beyond those configuration parameters. > > I would like to finally get version 2.7 released, so my main focus in > the near term is to go through the pending contributions and to merge in > clear bug fixes while leaving new functionality (like this Multi-AP) to > be post-2.7 items. Indeed, this doesn't look mature enough to be integrated in 2.7. > If there are any issues in getting these Multi-AP > patch updates coordinated, I may try to find time to work on them myself > after that release, but that should really be considered a backup plan > rather than something that would result in getting these in any time > soon.. OK. > I'm including my notes from going through the four patches below. Excellent, thank you for summarizing this! > Please > let me know if you have any other comments or different views on the > comments/proposed changes listed below. > > > http://patchwork.ozlabs.org/patch/978101/ > easymesh: add backhaul BSS support for WPS M8 > > functionality: > - adds hostapd configuration to use an externally generated file as a > WPS Credential for backhaul BSS; this is added to WPS M8 conditionally > - parsing and processing of of Multi-AP extension from WPS M1 > > comments: > - 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 > - 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 Actually that's not true: the MAC address attribute in M8's credentials is the BSSID, not the enrollee MAC address. At least, that's how I understand it. > * configure needed SSID/passphrase/etc. parameters instead and allow > hostapd to build this Credential dynamically when needed > > http://patchwork.ozlabs.org/patch/999135/ > easymesh: add a config option to enable EasyMesh backhaul STA > > functionality: > - add Multi-AP extension into WPS M1 > - adds global wpa_supplicant config parameter easymesh_backhaul_sta=0/1 > > comments: > - rename "easymesh" to "Multi-AP" > - 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 > - 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) That bit is actually done by patch 999587. > > http://patchwork.ozlabs.org/patch/999588/ > hostapd: Add Multi-AP protocol support > > functionality: > - adds hostapd configuration parameter multi_ap_enabled > (disabled, backhaul-BSS, fronthaul-BSS, both backhaul and > fronthaul-BSS) > - adds Multi-AP IE into (Re)Association Response frames > - checks Multi-AP IE in (Re)Association Request frames > - configures STA for 4-address WDS mode based on Multi-AP capability > > comments: > - struct multi_ap_ie is hardcoded to include a single Multi-AP Extension > subelement > * this is not ideal for subelement design > * not acceptable for parsing received Multi-AP IE since there could > be other subelements > - hostapd_validate_multi_ap_ie() does not check anything about the > Multi-AP IE payload (i.e., would not handle unexpected subelement > before the Multi-AP extension and does not check that the extension > has an acceptable value); WLAN_STA_MULTI_AP flag should be added only > if the contents is appropriate for backhaul STA > > http://patchwork.ozlabs.org/patch/999587/ > wpa_supplicant: Add Multi-AP protocol support to supplicant > > functionality: > - set_multi_ap() driver wrapper to configure backhaul STA interface into > 4-address mode (including nl80211 interface implementation) > - multi_ap_enabled network profile parameter in wpa_supplicant > - add Multi-AP IE into (Re)Association Request frames > - validate Multi-AP IE in (Re)Association Response frames > > comments: > - should consider renaming set_multi_ap() > - 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 What is clearly also missing is documentation of how it should all work. I think there should be a README-MULTI-AP somewhere that explains it all. Here is a start. Marianna, Wouter, Daniel, Jouni, please comment on it. Jouni, please let me know if this clarifies sufficiently how the multi-ap support is supposed to be used. Regards, Arnout -------------------------------------------------------------------------------- The Multi-AP Specification is the technical specification for Wi-Fi CERTIFIED EasyMesh(TM) [1], the Wi-Fi Alliance® certification program for Multi-AP. It defines control protocols between Wi-Fi® access points (APs) to join them into a network with centralized control and operation. It is targeted only at routers (repeaters, gateways, ...), not at clients. Clients are not involved at all in the protocols. Most of the Multi-AP specification falls outside of the scope of hostapd/wpa_supplicant. hostapd/wpa_supplicant is only involved for the items summarized below. The rest of the protocol must be implemented by a separate daemon, e.g. prplMesh [2]. The text below refers to "Multi-AP Specification v1.0" [3]. In a Multi-AP network, the central controller can configure the SSIDs on the devices that are joined into the network. These are called fronthaul SSIDs. From the point of view of hostapd, there is nothing special about these fronthaul SSIDs. In addition to fronthaul SSIDs, the controller can also configure backhaul links. A backhaul link is a link between two access point devices, giving internet access to access point devices that don't have a wired link. The Multi-AP specification doesn't dictate this, but typically the backhaul link will be bridged into a LAN together with (one of) the fronthaul SSID(s). A backhaul link must be treated specially by hostapd and wpa_supplicant. One side of the backhaul link is configured by the Multi-AP protocol as the "backhaul STA", i.e. the client side of the link. This is handled by wpa_supplicant, but it must send an additional information element in each (Re-)Association Request ([3], section 5.2, paragraph 4). In addition, it must use 4-address mode for all frames sent over this link ([3], section 14). [Insert here how to configure wpa_supplicant as a backhaul link.] The AP side of the backhaul link is called a "backhaul SSID". Such an SSID must be handled specially by hostapd, because it must add an additional information element in each (Re-)Association Response, but only to stations that have identified themselves as backhaul stations ([3], section 5.2, paragraph 5-6). This is important because it is possible to use the same BSS and SSID for fronthaul and backhaul at the same time. The additional information element must only be used for frames sent to a backhaul STA, not to a normal STA. Also, frames sent to a backhaul STA must use 4-address mode, while frames sent to a normal STA must use 3-address mode. [Insert here how to configure hostapd with a backhaul SSID, a fronthaul SSID, and a backhaul+fronthaul SSID if that is actually supported.] WPS requires more special handling. WPS must only be advertised on fronthaul SSIDs, not on backhaul SSIDs, so WPS should not be enabled on the backhaul SSID in hostapd.conf. The WPS configuration purely works on the fronthaul SSID. When a WPS M1 message has an additional subelement that indicates a request for a multi-AP backhaul link, hostapd must not respond with the normal fronthaul SSID credentials; instead, it responds with the (potentially different) backhaul SSID credentials. [Insert here how to configure this.] In addition to supplying the backhaul SSID credentials, hostapd will also add an additional information element to confirm that this is for a multi-AP backhaul link. When wpa_supplicant initiates WPS, it can add the multi-AP backhaul subelement in the M1 message. [Insert here how to configure wpa_supplicant to add the IE in WPS.] If it then receives the M8 response with the multi-AP backhaul subelement, it must treat the received credentials as a backhaul link, i.e. it must add the additional information element in (Re-)Association Request frames and it must 4-address mode. [Insert here how wpa_supplicant saves the information.] If it doesn't receive the multi-AP backhaul subelement in the WPS M8 response, it treats the link as a normal link, without additional information elements. [1] https://www.wi-fi.org/discover-wi-fi/wi-fi-easymesh [2] https://github.com/prplfoundation/prplMesh [3] https://www.wi-fi.org/file/multi-ap-specification-v10 (requires registration) _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
