[v3,12/12] hostapd: add README-MULTI-AP

Message ID 20181205102401.17810-13-arnout@mind.be
State New
Headers show
  • [v3,01/12] hostapd: Add Multi-AP protocol support
Related show

Commit Message

Arnout Vandecappelle Dec. 5, 2018, 10:24 a.m.
Document what hostapd and wpa_supplicant do for Multi-AP.

This is only included in hostapd, since a Multi-AP device is always an
access point so it should have hostapd.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 hostapd/README-MULTI-AP | 159 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 159 insertions(+)
 create mode 100644 hostapd/README-MULTI-AP


diff --git a/hostapd/README-MULTI-AP b/hostapd/README-MULTI-AP
new file mode 100644
index 000000000..a6d0186de
--- /dev/null
+++ b/hostapd/README-MULTI-AP
@@ -0,0 +1,159 @@ 
+hostapd, wpa_supplicant and the Multi-AP Specification
+This document describes how hostapd and wpa_supplicant can be configured to
+support the Multi-AP Specification.
+Introduction to Multi-AP
+The Wi-Fi Alliance 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]. That daemon also needs to communicate with hostapd,
+e.g. to get a list of associated clients, but this can be done using the normal
+hostapd interfaces.
+hostapd/wpa_supplicant needs to be configured specifically to support:
+- the WPS onboarding process;
+- configuring backhaul links.
+The text below refers to "Multi-AP Specification v1.0" [3].
+Fronthaul and backhaul links
+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) and the
+wired Ethernet ports.
+A backhaul link must be treated specially by hostapd and wpa_supplicant. One
+side of the backhaul link is configured through the Multi-AP protocol as the
+"backhaul STA", i.e. the client side of the link. A backhaul STA is like any
+station and is handled appropriately by wpa_supplicant, but two additional
+features are required. 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).
+Therefore, wpa_supplicant must be configured explicitly as the backhaul STA
+role, by setting 'multi_ap_backhaul_sta=1' in the network configuration block
+or when configuring the SSID through the client socket. When
+'multi_ap_backhaul_sta=1', wpa_supplicant includes the Multi-AP IE in
+(Re-)Assocation Request messages and verifies that it is included in the
+(Re-)Association Response. If it is not, association fails. If it is,
+wpa_supplicant sets 4-address mode for this interface through a driver
+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 (fronthaul, when it's a fronthaul and backhaul SSID) must use
+3-address mode.
+An SSID is configured in Multi-AP mode in hostapd by setting the 'multi_ap'
+configuration option to 1 (backhaul SSID), 2 (fronthaul SSID) or 3
+(simultaneous backhaul and fronthaul SSID). If this option is set, hostapd
+parses the Multi-AP information element in the Association Request. If the
+station is a backhaul STA and the SSID is configured as a backhaul SSID,
+hostapd sets up 4-address mode. Since there may be multiple stations connected
+simultaneously, and each of them has a different RA (receiver address), a VLAN
+is created for each backhaul STA and it is automatically added to a bridge.
+This is the same behavior as for WDS, and the relevant option ('bridge' or
+'wds_bridge') applies here as well.
+If 'multi_ap' is 1 (backhaul SSID only), any station that tries to associate
+without the Multi-AP information element will be denied.
+If 'multi_ap' is 2 (fronthaul SSID only), any station that tries to associate
+with the Multi-AP information element will be denied. That is also the only
+difference with 'multi_ap' set to 0: in the latter case, the Multi-AP
+information element is simply ignored.
+In summary, this is the end-to-end behaviour for a backhaul BSS (i.e.,
+multi_ap_backhaul_sta=1 in wpa_supplicant on STA, and multi_ap=1 or 3 in
+hostapd on AP). Note that point 1 means that hostapd must not be configured
+with WPS support on the backhaul BSS (multi_ap=1). hostapd does not check for
+1. Backhaul BSS beacons do not advertise WPS support (other than that, nothing
+   multi-ap specific).
+2. STA sends authentication req (nothing multi-ap specific).
+3. AP sends authentication resp (nothing multi-ap specific).
+4. STA sends association req with Multi-AP IE.
+5. AP send association resp with Multi-AP IE.
+6. STA and AP both use 4-address mode for data.
+WPS support
+WPS requires more special handling. WPS must only be advertised on fronthaul
+SSIDs, not on backhaul SSIDs, so WPS should not be enabled on a backhaul-only
+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 should respond with the (potentially different)
+backhaul SSID credentials.
+To support this, hostapd has the 'multi_ap_backhaul_ssid',
+'multi_ap_backhaul_wpa_psk' and 'multi_ap_backhaul_wpa_passphrase' options.
+When these are set on an SSID with WPS, they are used instead of the normal
+credentials when hostapd receives a WPS M1 message with the Multi-AP IE. Only
+WPA2 Personal is supported in the Multi-AP specification, so there is no need
+to specify authentication or encryption options. For the backhaul credentials,
+per-device PSK is not supported.
+If the SSID is a simultaneous backhaul and fronthaul SSID, there is no need to
+specify the backhaul credentials, since the backhaul and fronthaul credentials
+are identical.
+wpa_supplicant has a global multi_ap_backhaul_sta option to enable the Multi-AP
+backhaul STA feature when it performs WPS. When this option is set, it adds the
+multi-AP backhaul subelement to the association and M1 messages. It then
+configures the new SSID with 'multi_ap_backhaul_sta=1'. Note that this means
+that if the AP does not follow the Multi-AP specification, wpa_supplicant will
+fail to associate.
+In summary, this is the end-to-end behaviour for WPS of a backhaul link (i.e.,
+multi_ap_backhaul_sta=1 in wpa_supplicant on enrollee STA, multi_ap=2 and
+multi_ap_backhaul_ssid and either multi_ap_backhaul_wpa_psk or
+multi_ap_backhaul_wpa_passphrase are set to the credentials of a backhaul SSID
+in hostapd on registrar AP).
+1. Fronthaul BSS beacons advertise WPS support (nothing multi-ap specific).
+2. Enrollee sends authentication req (nothing multi-ap specific).
+3. AP sends authentication resp (nothing multi-ap specific).
+4. Enrollee sends association req with Multi-AP IE.
+5. AP send association resp with Multi-AP IE.
+6. Enrollee sends M1 with additional Multi-AP subelement
+7. AP sends M8 with backhaul instead of fronthaul credentials.
+8. Enrollee sends Deauth.
+[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)