On Wed, 2018-01-17 at 18:06 +0100, Beniamino Galvani wrote:
Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
supplicant didn't support them, potentially causing connection
failures. Instead, use the 'pmf' capability to detect when they can
be enabled.
Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
---
Hi,
this patch fixes regressions discovered after the merge of FILS
patches by our nightly CI that runs on CentOS where wpa_supplicant is
compiled without 802.11w support.
This patch fixes those regression. Comments welcome.
Thanks,
Beniamino
src/devices/nm-device-ethernet.c | 2 +-
src/devices/nm-device-macsec.c | 2 +-
src/devices/wifi/nm-device-wifi.c | 42 ++---------------
---
src/supplicant/nm-supplicant-config.c | 55
+++++++++++++++++++++++----
diff --git a/src/supplicant/nm-supplicant-config.c
b/src/supplicant/nm-supplicant-config.c
index a2502bd7b..14f5cac82 100644
--- a/src/supplicant/nm-supplicant-config.c
+++ b/src/supplicant/nm-supplicant-config.c
@@ -47,6 +47,8 @@ typedef struct {
guint32 ap_scan;
gboolean fast_required;
gboolean dispose_has_run;
+ gboolean support_pmf;
+ gboolean support_fils;
inside structs, could we use bool:1 bitfields?
NMSupplicantConfig *
-nm_supplicant_config_new (void)
+nm_supplicant_config_new (gboolean support_pmf, gboolean
support_fils)
{
- return g_object_new (NM_TYPE_SUPPLICANT_CONFIG, NULL);
+ NMSupplicantConfigPrivate *priv;
+ NMSupplicantConfig *self;
+
+ self = g_object_new (NM_TYPE_SUPPLICANT_CONFIG, NULL);
+ priv = NM_SUPPLICANT_CONFIG_GET_PRIVATE (self);
+
+ priv->support_pmf = support_pmf;
+ priv->support_fils = support_fils;
I always find it nice if nm_*_new() only calls g_object_new() and nothing else. But that would requie to introduce G_PARAM_CONSTRUCT_ONLY properties, to pass in the parameters. Clearly that is more hazzle then it's worth, so ok. Rest lgtm. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part