On Wed, Nov 21, 2018 at 04:47:47PM +0000, Marianna Carrera wrote: > What about we resubmit http://patchwork.ozlabs.org/patch/978101/ with three config params (last two being mutually exclusive): > multiap_backhaul_bss_ssid > multiap_backhaul_bss_wpa_psk > multiap_backhaul_bss_wpa_passphrase Yes, that makes sense to me. > > > > http://patchwork.ozlabs.org/patch/999135/ > > > > easymesh: add a config option to enable EasyMesh backhaul STA > > > > > > > comments: > > > > - rename "easymesh" to "Multi-AP" > > > What about easymesh_backhaul_sta --> multiap_backhaul_sta_en ? > > > > Need to coordinate with http://patchwork.ozlabs.org/patch/999587/ which > > uses multi_ap_enabled as a network profile parameter. I'm fine with > > either name (or well, I guess "_en" and "_enabled" postfix could really > > be removed), but I do not want multiple different ways of configuring > > this. > > I'd rather go for independent configs for multiap_backhaul / multiap_fronthaul (in hostapd.conf) and multiap_backhaul_sta (in wpa_supplicant.conf), rather than one catch all "multi_ap_enabled". As Arnout pointed out in that thread it is possible for a BSS to be both or either fronthaul and backhaul so I think the config should make as little assumptions as possible. I agree that the AP vs. STA side are different, but I do not want to see two different wpa_supplicant configuration items for practically the same thing (nor two different hostapd configuration items). For hostapd.conf, it might make more sense to have a single multi_ap integer parameter that takes various values based on what the BSS is configured to do. In other words, I like the approach in http://patchwork.ozlabs.org/patch/999588/ for AP configuration: #Enable Multi-AP functionality. #0:default #1:Enable Multi-AP as BACKHAUL_BSS #2:Enable Multi-AP as FRONTHAUL_BSS #3:Enable Multi-AP as BACKHAUL_BSS and FRONTHAUL_BSS #multi_ap_enabled=0 (with that unnecessary "_enabled" removed from the name, though) As far as wpa_supplicant is concerned, I'm starting to think following approach would be cleanest: - add a per-network profile parameter multi_ap to indicate that the profile (struct wpa_ssid) is used for Multi-AP backhaul STA functionality (this parameter will make wpa_supplicant add the Multi-AP IE into (Re)AssocReq and set 4-addr mode) (i.e., be pretty similar to http://patchwork.ozlabs.org/patch/999587/) - handle WPS provisioning for backhaul STA Credential using a per-WPS operation parameter instead of a global config parameter (e.g., "WPS_PBC any multiap=1") (i.e., modify http://patchwork.ozlabs.org/patch/999135/ to not introduce a new struct wpa_config pararameter, but instead, extend wpa_supplicant_ctrl_iface_wps_pbc() and wpas_wps_start_pbc() to be able to pass this information about Multi-AP specific provisioning case to WPS implementation); the WPS-generated network profile would then be marked with that multi_ap=1 item mentioned in the previous item > Note that the config above (multiap_backhaul_bss_ssid/psk/passphrase) are only valid for a bss with multiap_fronthaul=1 and multiap_backhaul=0. Sure, those WPS Credential values would only be used in the context where WPS is enabled. > I haven't heard from Venkateswara, if nothing comes up, we can resubmit our patch in a couple of weeks using multiap_backhaul_sta name. > For the error checking on multiap_backhaul_bss_ssid/psk/passphrase we probably need to wait for http://patchwork.ozlabs.org/patch/999587/ to stabilize. I think he was on vacation, but should be back now and will take a look at the patches. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
