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, 0 insertions, 181 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 deleted file mode 100644 index b8526b8b71..0000000000 --- a/package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch +++ /dev/null @@ -1,181 +0,0 @@ -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) |