| Message ID | 20190122083612.261747-1-lkundrak@v3.sk |
|---|---|
| State | Accepted |
| Headers | show |
| Series | dbus: Expose support of SAE key management | expand |
On Tue, Jan 22, 2019 at 09:36:12AM +0100, Lubomir Rintel wrote:
> This is going to be useful for NetworkManager and likely others.
Thanks, applied with an additional change to increase the key_mgmt[]
array size to avoid buffer overflows.
On Wed, 2019-01-23 at 01:36 +0200, Jouni Malinen wrote: > On Tue, Jan 22, 2019 at 09:36:12AM +0100, Lubomir Rintel wrote: > > This is going to be useful for NetworkManager and likely others. > > Thanks, applied with an additional change to increase the key_mgmt[] > array size to avoid buffer overflows. Thank you and sorry for the ommission. Seems like I've ommitted one more thing, the documentation update, which I'll follow up with shortly. A side note: at NetworkManager side, a couple of times before we've found ourselves in a suituation where we couldn't tell whether some new feature is supported because there was no indication on D-Bus. I'm wondering whether a way could be find to ensure new supplicant capabilities always end up exposed on D-Bus? I guess we really should just participate in the reviews, but perhaps a technical solution could be found? Lubo
On Wed, Jan 23, 2019 at 10:20:23AM +0100, Lubomir Rintel wrote: > A side note: at NetworkManager side, a couple of times before we've > found ourselves in a suituation where we couldn't tell whether some new > feature is supported because there was no indication on D-Bus. I'm > wondering whether a way could be find to ensure new supplicant > capabilities always end up exposed on D-Bus? I guess we really should > just participate in the reviews, but perhaps a technical solution could > be found? I don't think there would be a technical solution for this since most new features require some extensions to the configuration or operations used to manage them. In other words, someone needs to be interested enough to use them over D-Bus to implement the needed interface changes. I don't use the D-Bus interface in any use cases where I work with the upper layer component (well, apart from the hwsim test scripts), so this is not something that I would focus on adding just in case someone might want to use it over D-Bus.
diff --git a/wpa_supplicant/dbus/dbus_new_handlers.c b/wpa_supplicant/dbus/dbus_new_handlers.c index c3dc8854c..06769e174 100644 --- a/wpa_supplicant/dbus/dbus_new_handlers.c +++ b/wpa_supplicant/dbus/dbus_new_handlers.c @@ -4539,6 +4539,12 @@ static dbus_bool_t wpas_dbus_get_bss_security_prop( if (ie_data->key_mgmt & WPA_KEY_MGMT_FT_FILS_SHA384) key_mgmt[n++] = "wpa-ft-fils-sha384"; #endif /* CONFIG_FILS */ +#ifdef CONFIG_SAE + if (ie_data->key_mgmt & WPA_KEY_MGMT_SAE) + key_mgmt[n++] = "sae"; + if (ie_data->key_mgmt & WPA_KEY_MGMT_FT_SAE) + key_mgmt[n++] = "ft-sae"; +#endif /* CONFIG_SAE */ if (ie_data->key_mgmt & WPA_KEY_MGMT_NONE) key_mgmt[n++] = "wpa-none";
This is going to be useful for NetworkManager and likely others. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> --- wpa_supplicant/dbus/dbus_new_handlers.c | 6 ++++++ 1 file changed, 6 insertions(+)