Bug#1003907: fails to successfully associate

Mon Feb 7 12:11:34 PST 2022

Hello, Hans-Peter Jansen.

According to your wpa_supplicant.log, your are using FRITZ!Box 7590.
Is it true ?
-----
1643725737.260915: wlan1: SME: Trying to authenticate with
2c:91:ab:e0:30:35 (SSID='FRITZ!Box 7590 TC' freq=5180 MHz)
-----
If so, please send more verbose wpa_supplicant.log by trailing step.
Because I suspect that it has the same bug as FRITZ!Box 7490.

1) Edit /etc/systemd/system/multi-user.target.wants/wpa_supplicant.service to
add -dddddddddd option like this.

ExecStart=/sbin/wpa_supplicant -u -s -dddddddddd -O /run/wpa_supplicant

2) Reboot wpa_supplicant.
$ sudo systemctl daemon-reload

3) Enable NetworkManager logging
$ sudo nmcli general logging level DEBUG domains ALL

4) Get logs
$ journalctl -u NetworkManager -b

Regards,
Masashi Honma.

2022年2月7日(月) 23:39 Hans-Peter Jansen <hpj at urpla.net>:
>
> 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 at chromium.org>
> 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 at chromium.org>
> ---
>  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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap