diff options
Diffstat (limited to 'package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch')
| -rw-r--r-- | package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch b/package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch new file mode 100644 index 0000000000..b8526b8b71 --- /dev/null +++ b/package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch @@ -0,0 +1,181 @@ +From bd733055a22c8ca3bcd7648bf716da2713b3d9f1 Mon Sep 17 00:00:00 2001 +From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> +Date: Mon, 21 Jan 2019 16:44:06 +0100 +Subject: [PATCH] hostapd: add README-MULTI-AP + +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> +--- +v4: wps_pbc has multi_ap as a parameter instead of config option. +--- + hostapd/README-MULTI-AP | 160 ++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 160 insertions(+) + create mode 100644 hostapd/README-MULTI-AP + +--- /dev/null ++++ b/hostapd/README-MULTI-AP +@@ -0,0 +1,160 @@ ++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-)Association 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 ++callback. ++ ++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 ++that. ++ ++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. ++ ++To enable the Multi-AP backhaul STA feature when it performs WPS, a new ++parameter has been introduced to the WPS_PBC control interface call. ++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=1 option is given in the wps_pbc call on the STA side, and 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. ++ ++ ++References ++---------- ++ ++[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) |