On 06-01-17 18:57, Dan Williams wrote: > On Thu, 2017-01-05 at 16:06 +0100, Stijn Tintel wrote: >> Signed-off-by: Stijn Tintel <stijn@xxxxxxxxxxxxx> >> --- >> wpa_supplicant/dbus/dbus_new_handlers.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c >> b/wpa_supplicant/dbus/dbus_new_handlers.c >> index b25afc8..eac9ab4 100644 >> --- a/wpa_supplicant/dbus/dbus_new_handlers.c >> +++ b/wpa_supplicant/dbus/dbus_new_handlers.c >> @@ -991,6 +991,9 @@ dbus_bool_t wpas_dbus_getter_global_capabilities( >> #ifdef CONFIG_INTERWORKING >> capabilities[num_items++] = "interworking"; >> #endif /* CONFIG_INTERWORKING */ >> +#ifdef CONFIG_IEEE80211W >> + capabilities[num_items++] = "pmf"; >> +#endif /* CONFIG_IEEE80211W */ >> >> return wpas_dbus_simple_array_property_getter(iter, Hi Dan, thanks for reviewing the patches. > This looks OK, but this is only for the supplicant as a whole. > > What about each individual interface? We also typically have > corresponding properties in the interface properties itself, since just > because the supplicant is compiled with 11W or AP support doesn't mean > the driver and hardware can actually do it. For example, if you have > to use the WEXT driver, the only in-kernel driver that supports > IW_AUTH_MFP_REQUIRED is orinoco. In the support ticket for NM to add 802.11w support [1], we agree that enabling it optionally (pmf=1) when wpa_supplicant 802.11w support is detected is the easiest way forward. It should not matter if the driver supports it or not, as wpa_supplicant can already handle that [2]. In my opinion it does not make much sense to duplicate that logic in NM? Stijn [1] https://bugzilla.gnome.org/show_bug.cgi?id=748367 [2] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=117875db331f3c858fbfe23e0db415dd9fcb2a6d#n5991 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
