Hi,
based on the findings of Michael Biebl and Masashi Honma on this issue that
where really helpful, thank you, and thanks to Andrej Shadura for reporting,
I would like to share my insights, since wpa_supplicant 2.10 hit our openSUSE
Tumbleweed repositories, and I'm one of the people affected by this.
In short this issue affects people with old wifi hardware trying to connect
to AVM Fritzboxes, that use "WPA2 + WPA3" security (better known as WPA3
transition mode), resulting in:
wlp3s0: CTRL-EVENT-ASSOC-REJECT bssid=<mac> status_code=40
Switching the security mode to "WPA2 (CCMP)" in the Fritzbox makes it work,
but this is NOT a desired solution of course, since it will degrade security
for all devices in that wifi network.
Mine is a "Intel Centrino Advanced-N 6205 [Taylor Peak]" from my ten years
old Lenovo X1 Carbon (Gen 1), and from our bug tracking, we saw "Intel
Centrino Advanced-N 6235" is affected as well. [1]
With the change to 2.10, we got among others, full SAE (and PMF) support,
which in theory is required for proper WPA3 Personal support.
The whole story boils down to: in the unsupported case:
$ iw phy0 info | grep -A9 'Supported Ciphers'
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
while for a working config, it's:
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
* CMAC (00-0f-ac:6)
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
For PMF, these are required:
* CMAC (00-0f-ac:6)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
Some drivers contain them, the old Intel iwlwifi driver miss them obviously.
"Old" in the sense of the driver version, that is contained in Linux kernel
5.16.6, using firmware 18.168.6.1 6000g2a-6.ucode.
I was able to built a properly working wpa_supplicant package by just
reverting one hunk [2]:
>From 7a9c36722511ce4df88b76cceceb241d6c6a151e Mon Sep 17 00:00:00 2001
From: Brian Norris <briannorris@xxxxxxxxxxxx>
Date: Fri, 28 Feb 2020 15:50:47 -0800
Subject: [PATCH] DBus: Add "sae" to interface key_mgmt capabilities
This will be present when the driver supports SAE and it's included in
the wpa_supplicant build.
Signed-off-by: Brian Norris <briannorris@xxxxxxxxxxxx>
---
doc/dbus.doxygen | 2 +-
wpa_supplicant/dbus/dbus_new_handlers.c | 6 ------
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git b/wpa_supplicant/dbus/dbus_new_handlers.c a/wpa_supplicant/dbus/dbus_new_handlers.c
index c842c50e9..55c5dbc99 100644
--- b/wpa_supplicant/dbus/dbus_new_handlers.c
+++ a/wpa_supplicant/dbus/dbus_new_handlers.c
@@ -2798,12 +2798,6 @@ dbus_bool_t wpas_dbus_getter_capabilities(
goto nomem;
#endif /* CONFIG_WPS */
-#ifdef CONFIG_SAE
- if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_SAE) &&
- !wpa_dbus_dict_string_array_add_element(&iter_array, "sae"))
- goto nomem;
-#endif /* CONFIG_SAE */
-
#ifdef CONFIG_OWE
if ((capa.key_mgmt & WPA_DRIVER_CAPA_KEY_MGMT_OWE) &&
!wpa_dbus_dict_string_array_add_element(&iter_array, "owe"))
--
2.34.1
In my humble opinion, wpa_supplicant should test for sufficient ciphers,
and not even try to connect with WPA3 otherwise, in order to cope with
drivers, that simply don't have the relevant features.
Meanwhile, one of my mates noted the issue in completely different
constellations [3].
Best,
Pete
--
Life without chameleons is possible, but pointless.
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1195395
[2] https://build.opensuse.org/package/show/home:frispete:Tumbleweed/wpa_supplicant
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2050840
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
