> From: Jouni Malinen <mailto:j@xxxxx> > It would seem fine to add such information into the event or some other > convenient location for fetching it (like STATUS command). However, this > commit message and the proposed changed feel a bit confusing if this is > just about reporting the value to upper layers. I prefer to keep the information in the event and not in the status, so that the upper layers can assign the appropriate VLAN immediately when the STA connects. > > For Multi-AP traffic separation requirement, wpa_supplicant parses 802.1Q Multi-AP sub-element and reports: > > - VLAN ID of the AP it connects to. > > - Multi-AP profile of the AP it connects to. > > It would be good to be clear here on why this is being added (i.e., what > the information is used for) and that this is just for reporting and not > changing some configuration parameters. I will ask our team to improve the commit message when submitting v2. > > diff --git a/wpa_supplicant/config_ssid.h b/wpa_supplicant/config_ssid.h > > @@ -1192,6 +1192,13 @@ struct wpa_ssid { > > + /** > > + * multi_ap_primary_vlanid - Multi-AP Primary VLAN ID (Multi-AP Specification v2.0) > > + * 0 = VLAN ID not set > > + * 1-4094 = VLAN ID > > + */ > > + u16 multi_ap_primary_vlanid; > > Why would this be added as a new configuration parameter for the network > profile? This does not seem to have anything to do with local > configuration, i.e., this is a value that shows up as a part of a > backhaul association. We wanted to keep the multi_ap information adjacent to the network information, since this is part of the link definition. However, as you rightly pointed out, this is retrieved dynamically from the AP, and not configured in the wpa_supplicant configuration. Reviewing the code again, perhaps this should be added directly in struct wpa_supplicant? Do you agree, or is there a more suitable location for such information to remain persistent throughout the connection? > I would prefer to extend the CTRL-EVENT-CONNECTED event to include > these new values only if the association is for Wi-Fi EasyMesh backhaul > connection. This event is used by many external programs and it is > better to try to minimize risk of confusing them in cases where the > association has nothing to do with Wi-Fi EasyMesh. Noted. I will ask that this change is applied to v2 of the commit. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
