On 21/11/2018 17:47, Marianna Carrera wrote: > Hi Jouni, Arnout, > >>> This sounds unnecessarily complex to me. I don't see why we would need >>> to configure more than the SSID and passphrase/PSK of the backhaul BSS >>> (assuming the same passphrase/PSK is used for each backhaul STA). All >>> the other attributes within the Credential are either hardcoded or known >>> to Registrar: >>> - Network Index: deprecated, hardcoded to 1 >>> - SSID: from new configuration parameter >>> - Authentication Type: 0x0020 (WPA2-Personal) >>> - Encryption Type: 0x0008 (AES) >>> - Network Key Index: deprecated; not included >>> - Network Key: from new configuration parameter >>> - MAC Address: Enrollee's MAC Address >>> - and that's it; no other attribute is applicable for this use case >> >> Table 36 of the WSC specification already enumerates 5 additional optional >> attributes: EAP Type, EAP Identity, Key Provided Automatically, 802.1X Enabled, >> Network Key Shareable. In addition, Multi-AP R2 might require an additional >> credential attribute (as a vendor extension, most likely). Marianna, do you >> expect that to be the case? > > Not in most cases, but that's indeed the reason I wanted to keep it generic, not for changes in the WSC spec, but for the possibility that some MAP Controllers will want to use the MAP protocol to configure less common parameters. > However, I agree that MAP today is not really targeted to anything else than home networks which usually do not use anything else than WPA2-Personal. I don't like the idea of hardcoding Authentication Type and Encryption Type, but I agree that SSID and PSK is likely all we need in 99% of the cases. In fact, Multi-AP R1 specifies: "A Multi-AP Controller shall set the Authentication Type attribute in M2 to indicate WPA2-Personal or Open System Authentication." - which kind of implies that both fronthaul and backhaul BSSes *must* be WPA2-Personal (or open). I guess (hope!) R2 will add WPA3 as an option though... > 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 > > > >> Now, even in that situation, we're going to need to patch wpa_supplicant to >> handle that additional attribute, so we could just as well patch hostapd at the >> same time to include it. > > I don't understand this point. wpa_supplicant is only involved in the M1-M8 exchange and that is not changed. > Above we're talking about credentials that are shared over 1905 frames in M2 and that will have to be stored into hostapd config in some form. Where do the patch to wpa_supplicant comes in? But the credentials for a backhaul BSS are used in the M8 that is sent to a bSTA enrollee. And these will be parsed by wpa_supplicant on the enrollee. Of course, wpa_supplicant can still be configured with wps_cred_processing=1 or 2 to handle additional attributes. >> And regardless, you can always use extra_cred to pass additional attributes >> (they won't be part of the ATTR_CRED then, but they will be encrypted). > > But now I do wonder whether this would work. Same comment as yours hereafter: > >>>>> - cannot use hardcoded external file to build the Credential for >>>>> backhaul STA since MAC Address attribute depends on the Enrollee's >>>>> MAC address and changes for each device >> >> Hm, I realize now: what was proposed here is the same situation as >> skip_cred_build=1 and extra_cred=some-file. That couldn't possibly work either >> then, right? > >>>> 1. A MAP agent that is not yet configured brings up only the station interface. >>>> --> this is for a configuration software above hostapd to take care of (like PrplMesh) >>> >>> Is that "the station interface" referring to a new netdev/vif being >>> created or would that use an existing main netdev (say, wlan0) of a >>> radio? Or that does not matter here? The key point I'm trying to >>> understand here is in whether wpa_supplicant would need to be involved >>> in creating a new virtual interface here or would that always be assumed >>> to be outside the scope of wpa_supplicant functionality for this >>> sequence? >> There is no difference with normal WPS: the upper layer (e.g. OpenWRT) is >> responsible for creating the vif if needed (small caveat: AFAIK OpenWRT doesn't >> currently support WPS for stations). > > Jouni, I see your point now. I agree with Arnout, I would let upper layers deal with creating/configuring interfaces. > > > > >>>> 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. > > 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. I don't think there's a need for hostapd to check that, however. It's up to the user to create a conformant config file. Regards, Arnout > 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. > > Best, > Marianna > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
