On Tue, Nov 20, 2018 at 04:50:31PM +0100, Arnout Vandecappelle wrote: > On 19/11/2018 20:18, Jouni Malinen wrote: > > However, this patch seems to be using set_multi_ap() > > only in station mode (backhaul STA) > > Yes, my remark was about the AP side, i.e. hostapd. Patch 1/2 apparently > doesn't set 4-address mode, so I'm not sure how/if it works then. It does.. See the WLAN_STA_MULTI_AP use cases where the existing implementation for WLAN_STA_WDS is re-used. > When transmitting a local frame (i.e. with source address == the STA MAC > address), the backhaul STA may actually use 3-address mode. Fortunately, the > Multi-AP specification allows to use 4-address mode in that case as well, so > indeed a global 4ADDR is sufficient for the STA side. It would be good for the driver side to be able to receive both 3 and 4 address frames for such cases to allow for minor optimization (6 octets shorter frame). > > Agreed on the not switching this type of things during an association > > part.. I'm not familiar enough with the specific use case on how the > > netdev got added to comment on that nl80211_create_iface() part. In > > other words, can this be used with the main netdev (say, wlan0) as the > > backhaul STA or is there an expectation that a new netdev/vif is created > > when backhaul STA functionality is enabled? > > The main netdev may already be in use by an AP, so indeed it may be needed to > create a new vif. But OpenWRT at least handles that automatically already (it > always creates a new netdev, except if the main netdev is unconfigured). There's > nothing really special about that for the multi-AP case. OK. I have not really heard of any convincing need for dynamic changes for this during an association, so I'd expect this to be modified to be a more static network profile parameter that is used for wpa_supplicant to behave appropriate in the backhaul STA role. > > I'd probably agree on this, but would need to see an example sequence on > > how this is used to fully understand what needs to happen and how this > > ssid->multi_ap_enabled gets set. > > I explained this in my other mail, but here's a summary: > > Optional: start with WPS (covered by patch 999135 (wpa_supplicant) and 978101 > (hostapd). > > 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 additional Multi-AP subelement and backhaul (instead of > fronthaul) credentials. > 8. Enrollee sends Deauth. On wpa_supplicant side, this all could be initialized with "WPS_PBC any multi_ap=1" that I mentioned in an earlier email and that step 7 Credential would end up with wpa_supplicant (or external component with wps_cred_processing=1/2) generating a network profile with multi_ap=1 for the following sequence. > Now the enrollee can use the backhaul credentials to operate a backhaul STA. > From this point on, the sequence is the same whether the credentials were > received through WPS or through some other means. > > 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. OK, this should work fine with that multi_ap=1 regardless on how the network profile was added to wpa_supplicant. > > If all the callers use wpa_s->bridge_ifname here, sure, no point in > > passing that as an argument to the wrapper function. As discussed above, > > this should likely be renamed, though, to make it clearer what the > > driver operation is doing (just enabled 4-address mode in backhaul STA > > case? or something beyond that?). hostapd does have code for dynamically > > adding/removing netdevs to/from a bridge, > > Why does hostapd have that feature? That's mostly used in dynamic VLAN cases where an external RADIUS authentication server is in control of selecting which VLAN ID is used for each STA and hostapd may not initially know what is the full set of used VLAN IDs. The applicable netdevs (both WLAN and Ethernet) can be added dynamically when needed the first time and added to a bridge at that time. > There is not really any difference w.r.t. bridging in the multi-AP case. > Perhaps a router implementation would want to put a multi-AP backhaul link > automatically in the "LAN" bridge, while for a non-multi-AP link it would treat > it as a WAN with masquerading. But that's really policy which has nothing to do > with hostapd/wpa_supplicant IMO. As long as this works without having to do dynamic netdev addition, this sounds fine to me. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
