aboutsummaryrefslogtreecommitdiffstats
path: root/package/network/services/hostapd/patches/558-hostapd-add-README-MULTI-AP.patch
blob: b8526b8b71f43695c0b7a93ebf5873484bb206c5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
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)