Denied association with wpasupplicant 2:2.10-2

[Patrick Beckmann]

When I upgraded my computer to Ubuntu 22.04 with "wpasupplicant" version 2:2.10-2, it would no longer connect to my WiFi, but instead tries multiple times without success. The WiFi card is a "Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)", the WiFi access point is a AVM FritzBox 7530 with the current firmware 07.29. The WiFi security is set PSK/personal mode with "WPA 2 + WPA 3". Please see below for Syslog messages. Downgrading to version 2:2.9.0-21build1 makes WiFi connectivity work again.

This sound a lot like the following problem to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907

It might not be a bug in package wpasupplicant itself, but it seems to effectively prevent networking and should probably be circumvented.

Syslog excerpt with wpasupplicant 2.10:

Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='xxxxxx' freq=5180 MHz)
Apr 3 19:32:49 intel2400 kernel: [22688.198598] wlan0: authenticate with xx:xx:xx:xx:xx:xx
Apr 3 19:32:49 intel2400 NetworkManager[849]: <info> [1649007169.4799] device (wlan0): supplicant interface state: disconnected -> authenticating
Apr 3 19:32:49 intel2400 kernel: [22688.201456] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: SME: Trying to authenticate with xx:xx:xx:xx:xx:xx (SSID='xxxxxx' freq=5180 MHz)
Apr 3 19:32:49 intel2400 kernel: [22688.403926] wlan0: authenticate with xx:xx:xx:xx:xx:xx
Apr 3 19:32:49 intel2400 kernel: [22688.403938] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: PMKSA-CACHE-ADDED xx:xx:xx:xx:xx:xx 0
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: Trying to associate with xx:xx:xx:xx:xx:xx (SSID='xxxxxx' freq=5180 MHz)
Apr 3 19:32:49 intel2400 NetworkManager[849]: <info> [1649007169.7386] device (wlan0): supplicant interface state: authenticating -> associating
Apr 3 19:32:49 intel2400 kernel: [22688.461401] wlan0: authenticated
Apr 3 19:32:49 intel2400 kernel: [22688.465084] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
Apr 3 19:32:49 intel2400 kernel: [22688.467925] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x1511 status=40 aid=0)
Apr 3 19:32:49 intel2400 kernel: [22688.467956] wlan0: xx:xx:xx:xx:xx:xx denied association (code=40)
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=xx:xx:xx:xx:xx:xx status_code=40
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: wlan0: SME: Deauth request to the driver failed
Apr 3 19:32:49 intel2400 wpa_supplicant[11655]: BSSID xx:xx:xx:xx:xx:xx ignore list count incremented to 2, ignoring for 10 seconds
Apr 3 19:32:49 intel2400 NetworkManager[849]: <info> [1649007169.7705] device (wlan0): supplicant interface state: associating -> disconnected
Apr 3 19:32:49 intel2400 NetworkManager[849]: <info> [1649007169.8706] device (wlan0): supplicant interface state: disconnected -> scanning
[after that it would repeat]

[Reiokorn (reiokorn)]

Created attachment 855766
log file of wpa_supplicant

Hello,
after the recent update to Tumbleweed, and the wpa_supplicant to version 2.10, I'm no longer able to connect to my home WLAN with my laptop.

I've included the wpa_supplicant.log file for diagnosis.

[Andreas Stieger (andreasstieger)]

This came from https://build.opensuse.org/request/show/948420

[Dmueller-4 (dmueller-4)]

*** Bug 1195312 has been marked as a duplicate of this bug. ***

[Dmueller-4 (dmueller-4)]

I submitted a followup there that will hopefully fix this (I can not reproduce it here for some weird reason): https://build.opensuse.org/request/show/950290

[Dmueller-4 (dmueller-4)]

Marcus, since you can apparently reproduce this issue, can you test the submission in comment 3?

[Meissner-i (meissner-i)]

Created attachment 855771
wpa_supplicant.log with dirks fixes

i tried your version in home:dirkmueller:Factory wpa_supplicant

but no change.
i attached the logfile resulting from this

[Meissner-i (meissner-i)]

Created attachment 855773
wpa_supplicant.log with dirks fixes

did not work for me

[Dmueller-4 (dmueller-4)]

are you all using networkmanager?

[Reiokorn (reiokorn)]

(In reply to Dirk Mueller from comment #7)
> are you all using networkmanager?

Yes, is it related?

[Reiokorn (reiokorn)]

Created attachment 855774
journalctl -b

[Dmueller-4 (dmueller-4)]

(In reply to B from comment #8)
> > are you all using networkmanager?
> Yes, is it related?

I'm using wicked where everything seems to be working. in another mail discussion it became clear that switching to wicked fixed the issue for others. just trying to understand if there is one problem or more than one.

[Dmueller-4 (dmueller-4)]

thanks for the traces. so I switched to networkmanager as well, and it still works here just fine.

however, I found this which describes the same issue, also with status_code=0x40 rejection:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907

it looks like a defect on the fritzbox side according to the analysis there, where WPA2+WPA3 transitional mode is not working as the AP is not indicating it needs 11W, while it refused to connect without it.

[Dmueller-4 (dmueller-4)]

Please retest with wpa_supplicant from here:

https://download.opensuse.org/repositories/home:/dirkmueller:/Factory/standard/x86_64/

it has SAE (WPA3) disabled, so that should bypass this issue.

[Reiokorn (reiokorn)]

(In reply to Dirk Mueller from comment #11)
> thanks for the traces. so I switched to networkmanager as well, and it still
> works here just fine.
>
> however, I found this which describes the same issue, also with
> status_code=0x40 rejection:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
>
>
> it looks like a defect on the fritzbox side according to the analysis there,
> where WPA2+WPA3 transitional mode is not working as the AP is not indicating
> it needs 11W, while it refused to connect without it.

I would like to note that the previous version did not cause any problems, even with the WPA2+WPA3 transition mode.

[Reiokorn (reiokorn)]

(In reply to Dirk Mueller from comment #12)
> Please retest with wpa_supplicant from here:
>
>
> https://download.opensuse.org/repositories/home:/dirkmueller:/Factory/
> standard/x86_64/
>
> it has SAE (WPA3) disabled, so that should bypass this issue.

OK, I tried your modified version, but it didn't fix the issue. Still can't connect.

[Reiokorn (reiokorn)]

(In reply to Dirk Mueller from comment #11)
> thanks for the traces. so I switched to networkmanager as well, and it still
> works here just fine.
>
> however, I found this which describes the same issue, also with
> status_code=0x40 rejection:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
>
>
> it looks like a defect on the fritzbox side according to the analysis there,
> where WPA2+WPA3 transitional mode is not working as the AP is not indicating
> it needs 11W, while it refused to connect without it.

I've switched to wicked service instead of networkmanager and the problem is gone even with the 2.10 (standard version) wpa_supplicant

Issue in Networkmanager instead?

[Dmueller-4 (dmueller-4)]

(In reply to B from comment #15)
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
> I've switched to wicked service instead of networkmanager and the problem is
> gone even with the 2.10 (standard version) wpa_supplicant

Good news!

> Issue in Networkmanager instead?

unlikely, the logs show wpa_supplicant failing to connect though. I think this is confirmed by the finding in the debian BTS. when they reverted the patch that implements the SAE dbus interface that networkmanager is using, the connection worked.

I'm not 100% confident that wicked can use WPA3, so wicked working might mean you're actually connecting via WPA2.

if you have control over your wpa_supplicant.conf, please try whether adding pmf=2 or pmf=1 at the beginning of the file changes the situation.

My current guess is that pmf=2 would make you able to connect again.

[Dmueller-4 (dmueller-4)]

(In reply to Dirk Mueller from comment #16)
> My current guess is that pmf=2 would make you able to connect again.

it appears that in the protocol handshake, the AP (fritzbox) is declaring to not require protected management frames. which is sort of true, it doesn't require it in WPA2 mode. However by specification WPA3 is always with PMF enabled, and it appears wpa_supplicant would have to ignore the AP advice and connect in SAE mode with PMF enabled.

pmf=2 forces PMF even if the AP says it doesn't require it.

[Meissner-i (meissner-i)]

FWIW I also have a wireless card in my workstation, managed by wicked. this one works on the same FritzBox AP , same wpa_supplicant from Factory.

- Laptop Lenovo X200s with Intel Pro Wireless 5100 AGN SHiloh and NetworkManager: does not work
- Workstation with RTL8188EE Wireless Network Adapter (rev 01) with wicked: works

[Dmueller-4 (dmueller-4)]

can you try injecting pmf=2 into your wpa_supplicant.conf? does it work if you disable wpa3 in fritzbox? then we're talking about the same issue.

[Meissner-i (meissner-i)]

i switched my Friotzbox wlan to WPA2(CCMP) (so no WPA3) ... and the laptop now connects over wifi with dirks last wpa_supplicant.

So there is some WPA3 fishyness.

The Fritz!box 7430 has a a PMF setting
"Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren"
which is default enable for WPA3, but can be selectively enabkled for WPA2 only.

[Reiokorn (reiokorn)]

(In reply to Dirk Mueller from comment #16)
> (In reply to B from comment #15)
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
> > I've switched to wicked service instead of networkmanager and the problem is
> > gone even with the 2.10 (standard version) wpa_supplicant
>
> Good news!
>
> > Issue in Networkmanager instead?
>
> unlikely, the logs show wpa_supplicant failing to connect though. I think
> this is confirmed by the finding in the debian BTS. when they reverted the
> patch that implements the SAE dbus interface that networkmanager is using,
> the connection worked.
>
> I'm not 100% confident that wicked can use WPA3, so wicked working might
> mean you're actually connecting via WPA2.
>
> if you have control over your wpa_supplicant.conf, please try whether adding
> pmf=2 or pmf=1 at the beginning of the file changes the situation.
>
> My current guess is that pmf=2 would make you able to connect again.

Tried both with your modified version - no change. No connection possible.

[Reiokorn (reiokorn)]

Just to make sure, I modified and added that parameter in /etc/wpa_supplicant.conf

That's the right one, yes?

I noticed that there is also a conf file with the same name in another place in the system in /etc/dbus-1/system.d

[Reiokorn (reiokorn)]

(In reply to Marcus Meissner from comment #20)
> i switched my Friotzbox wlan to WPA2(CCMP) (so no WPA3) ... and the laptop
> now connects over wifi with dirks last wpa_supplicant.
>
> So there is some WPA3 fishyness.
>
> The Fritz!box 7430 has a a PMF setting
> "Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren"
> which is default enable for WPA3, but can be selectively enabkled for WPA2
> only.

I did the same and switched to WPA2(CCMP) and connection is possible and working again. That's with Dirk's modified version AND the current tumbleweed version - makes no difference.

[Reiokorn (reiokorn)]

Created attachment 855797
networkmanager logs

I tried to get the logs like they did in the bugs.debian post with:

> 3) Enable NetworkManager logging
> $ sudo nmcli general logging level DEBUG domains ALL
>
> 4) Get logs
> $ journalctl -u NetworkManager -b

I hope this can help to pinpoint the issue

[Dmueller-4 (dmueller-4)]

(In reply to B from comment #23)
> I did the same and switched to WPA2(CCMP) and connection is possible and
> working again. That's with Dirk's modified version AND the current
> tumbleweed version - makes no difference.

just to be clear, I have no patches in wpa_supplication in "dirks version", the only change there is feature enablement of further flags that I was originally hoping would fix this issue.

meanwhile we know also the debian version has the issue, which has even more feature flags enabled. so it should not be related to config changes.

> The Fritz!box 7430 has a a PMF setting
> "Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren"
> which is default enable for WPA3, but can be selectively enabkled for WPA2
> only.

what setting did you have and what do you have now regarding PMF? can you turn off PMF for WPA3 and does it allow connecting with WPA3 then again?

[Hp-jansen (hp-jansen)]

FYI, I've built a version of Dirk's wpa_supplicant package with the "offending" commit reverted here:

https://build.opensuse.org/package/show/home:frispete:Tumbleweed/wpa_supplicant

With this package, you can keep the FB setting as "WPA2 + WPA3".

[Hp-jansen (hp-jansen)]

Just some thoughts to further investigation.

Assuming the majority of german users use FB in "WPA2 + WPA3" mode at home, and control their wifi with NetworkManager, I wonder why this issue doesn't occur more often.

Except for the NM part, this also applies to you, Dirk, does it?

I experimented with a couple of settings today.

FB (7490 with current FW 7.29 and WPA3 transitional mode):

/etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
# enforce PMF
pmf=1|2
sae_pwe=0|2
#sae_groups=1 2 5 19 20 21 22 23 24
ieee80211w=1|2
key_mgmt=WPA-EAP WPA-EAP-SHA256|SAE

Variations are denoted by the pipe.

The initiated discover that this covers variations from optional WPA3 to mandatory MPA3-Personal. None of these setting variations result in a working configuration here.

I begin to believe, that older wifi hardware suffers from some unknown deficits, that contribute to this issue. Mine is a "Intel Centrino Advanced-N 6205 [Taylor Peak]" from my ten years old Lenovo X1 Carbon (Gen 1). Other, than that, I'm up-to-date: kernel 5.16.6 (a bit ahead of TW), kernel-firmware-iwlwifi-20220119, etc..

[Hp-jansen (hp-jansen)]

Created attachment 855916
result of iw phy0 info

[Hp-jansen (hp-jansen)]

Could somebody with a working config share the result of

$ iw phy0 info

please.

[Reiokorn (reiokorn)]

Created attachment 855920
iw phy0 info RTL8191SEvB

(In reply to Hans-Peter Jansen from comment #29)
> Could somebody with a working config share the result of
>
> $ iw phy0 info
>
> please.

Sure, here you go.

That old RTL8191SEvB is working just fine.

The problem with my WLAN connection concerns my laptop with an "Intel Centrino Advanced-N 6235".

[Reiokorn (reiokorn)]

(In reply to Hans-Peter Jansen from comment #27)
> Just some thoughts to further investigation.
>
> Assuming the majority of german users use FB in "WPA2 + WPA3" mode at home,
> and control their wifi with NetworkManager, I wonder why this issue doesn't
> occur more often.
>
> Except for the NM part, this also applies to you, Dirk, does it?
>
> I experimented with a couple of settings today.
>
> FB (7490 with current FW 7.29 and WPA3 transitional mode):
>
> /etc/wpa_supplicant/wpa_supplicant.conf:
>
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> # enforce PMF
> pmf=1|2
> sae_pwe=0|2
> #sae_groups=1 2 5 19 20 21 22 23 24
> ieee80211w=1|2
> key_mgmt=WPA-EAP WPA-EAP-SHA256|SAE
>
> Variations are denoted by the pipe.
>
> The initiated discover that this covers variations from optional WPA3 to
> mandatory MPA3-Personal. None of these setting variations result in a
> working configuration here.
>
> I begin to believe, that older wifi hardware suffers from some unknown
> deficits, that contribute to this issue. Mine is a "Intel Centrino
> Advanced-N 6205 [Taylor Peak]" from my ten years old Lenovo X1 Carbon (Gen
> 1). Other, than that, I'm up-to-date: kernel 5.16.6 (a bit ahead of TW),
> kernel-firmware-iwlwifi-20220119, etc..

The common denominator so far is probably that they are Intel WLAN chips.(In reply to Hans-Peter Jansen from comment #27)
> Just some thoughts to further investigation.
>
> Assuming the majority of german users use FB in "WPA2 + WPA3" mode at home,
> and control their wifi with NetworkManager, I wonder why this issue doesn't
> occur more often.
>
> Except for the NM part, this also applies to you, Dirk, does it?
>
> I experimented with a couple of settings today.
>
> FB (7490 with current FW 7.29 and WPA3 transitional mode):
>
> /etc/wpa_supplicant/wpa_supplicant.conf:
>
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> # enforce PMF
> pmf=1|2
> sae_pwe=0|2
> #sae_groups=1 2 5 19 20 21 22 23 24
> ieee80211w=1|2
> key_mgmt=WPA-EAP WPA-EAP-SHA256|SAE
>
> Variations are denoted by the pipe.
>
> The initiated discover that this covers variations from optional WPA3 to
> mandatory MPA3-Personal. None of these setting variations result in a
> working configuration here.
>
> I begin to believe, that older wifi hardware suffers from some unknown
> deficits, that contribute to this issue. Mine is a "Intel Centrino
> Advanced-N 6205 [Taylor Peak]" from my ten years old Lenovo X1 Carbon (Gen
> 1). Other, than that, I'm up-to-date: kernel 5.16.6 (a bit ahead of TW),
> kernel-firmware-iwlwifi-20220119, etc..

I would argue that the common denominator, from you, the bug report on debian and also with me is the Intel WLAN chip.

[Hp-jansen (hp-jansen)]

Meanwhile, I'm pretty confident, this is the culprit:

$ 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 your 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)

Your RTL provides them, our old Intel miss them.

In theory, these ciphers are supplied easily in software, but this requires some community intelligence to be realized.

@Dirk: no amount of forcing the connection from NM (Security: WPA/WPA2 Personal), then tweaking the connection with nmcli does result in a successful connect.

If forcing the connection security to "WPA3 Personal", the connection settings are:
802-11-wireless-security.key-mgmt: sae
802-11-wireless-security.pmf: 3 (required)

With WPA/WPA2 Personal:
802-11-wireless-security.key-mgmt: wpa-psk
802-11-wireless-security.pmf: 0 (default)

Also tried:
802-11-wireless-security.key-mgmt: wpa-psk
802-11-wireless-security.pmf: 1 (disable)

@B, you can check this yourself with:

$ nmcli connection show

Look up your specific connection.

$ nmcli connection show <uuid>

Specifically:

$ nmcli connection show <uuid> | grep -E 'key-mgmt|pmf'

In my humble opinion, wpa_supplicant should test for sufficient ciphers, and not even try to connect with WPA3 otherwise. Will report this to the wpa_supplicant mailing list, but need to subscribe first...

[Reiokorn (reiokorn)]

(In reply to Hans-Peter Jansen from comment #32)
> Meanwhile, I'm pretty confident, this is the culprit:
>
> $ 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 your 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)
>
> Your RTL provides them, our old Intel miss them.
>
> In theory, these ciphers are supplied easily in software, but this requires
> some community intelligence to be realized.
>
> @Dirk: no amount of forcing the connection from NM (Security: WPA/WPA2
> Personal), then tweaking the connection with nmcli does result in a
> successful connect.
>
> If forcing the connection security to "WPA3 Personal", the connection
> settings are:
> 802-11-wireless-security.key-mgmt: sae
> 802-11-wireless-security.pmf: 3 (required)
>
> With WPA/WPA2 Personal:
> 802-11-wireless-security.key-mgmt: wpa-psk
> 802-11-wireless-security.pmf: 0 (default)
>
> Also tried:
> 802-11-wireless-security.key-mgmt: wpa-psk
> 802-11-wireless-security.pmf: 1 (disable)
>
> @B, you can check this yourself with:
>
> $ nmcli connection show
>
> Look up your specific connection.
>
> $ nmcli connection show <uuid>
>
> Specifically:
>
> $ nmcli connection show <uuid> | grep -E 'key-mgmt|pmf'
>
> In my humble opinion, wpa_supplicant should test for sufficient ciphers, and
> not even try to connect with WPA3 otherwise. Will report this to the
> wpa_supplicant mailing list, but need to subscribe first...

why was it possible to connect with the wpa_supplicant version before the update to 2.10 then without issues? The supported ciphers didn't change, did they?

[Reiokorn (reiokorn)]

(In reply to Hans-Peter Jansen from comment #32)
> (...)
> $ nmcli connection show <uuid> | grep -E 'key-mgmt|pmf'
>
> In my humble opinion, wpa_supplicant should test for sufficient ciphers, and
> not even try to connect with WPA3 otherwise. (...)

My output on the laptop with RTL and working connection:

> 082-11-wireless-security.key.mgmt: wpa-psk
> 082-11-wireless-security.key.pmf: 0 (default)

[Fkrueger-6 (fkrueger-6)]

Others are hit as well: https://bugzilla.redhat.com/show_bug.cgi?id=2050840

[Hp-jansen (hp-jansen)]

(In reply to B from comment #34)
> (In reply to Hans-Peter Jansen from comment #32)
> > (...)
> > $ nmcli connection show <uuid> | grep -E 'key-mgmt|pmf'
> >
> > In my humble opinion, wpa_supplicant should test for sufficient ciphers, and
> > not even try to connect with WPA3 otherwise. (...)
>
> My output on the laptop with RTL and working connection:
>
> > 082-11-wireless-security.key.mgmt: wpa-psk
> > 082-11-wireless-security.key.pmf: 0 (default)

Try to switch to WPA3 in the NetworkManager ui and the FB. Depending on the package in use (try the original TW pkg first), you might even have success with WPA3. ;-)

(In reply to Frank Krüger from comment #35)
> Others are hit as well: https://bugzilla.redhat.com/show_bug.cgi?id=2050840

Thanks Frank, I posted the issue to the wpa_supplicant ML meanwhile, and reported it to AVM. Let's see, how this goes..

[Hp-jansen (hp-jansen)]

Hi B,

mind providing more detailed logs while experiencing the failure?

$ systemctl edit --full wpa_supplicant.service

Add -dddddddddd to the ExecStart arguments, e.g.:

ExecStart=/usr/sbin/wpa_supplicant -dddddddddd -c /etc/wpa_supplicant\ /wpa_supplicant.conf -u -t -f /var/log/wpa_supplicant.log

Add debug logging to NetworkManager (assuming, you don't have a [logging] section in there already):

$ cat < EOF >> /etc/NetworkManager/NetworkManager.conf

[logging]
level=DEBUG

EOF

$ cat /dev/null > /var/log/wpa_supplicant.log

Reboot into the failing state

$ reboot

Provide /var/log/wpa_supplicant.log and the output of

$ journalctl -u NetworkManager -b

Thank you!

[Reiokorn (reiokorn)]

Created attachment 855988
wpa_supplicant.log

(In reply to Hans-Peter Jansen from comment #37)

> (...)
> Provide /var/log/wpa_supplicant.log and the output of
>
> $ journalctl -u NetworkManager -b
>
> Thank you!

Here's the log

[Reiokorn (reiokorn)]

Created attachment 855989
journalctl -u NetworkManager -b

here's the journal

[Meissner-i (meissner-i)]

fwiw the current tumbleweed version also does NOT work with Fritz!box in wpa2 only mode.

Dirks branch works with the Fritz!Box in wpa2 only mode.

[Reiokorn (reiokorn)]

latest update of wpa_supplicant on tumbleweed (to v. 2.10-2.1) fixed the connectivity issues for me.

[Dmueller-4 (dmueller-4)]

(In reply to Marcus Meissner from comment #40)
> Dirks branch works with the Fritz!Box in wpa2 only mode.

there is no difference between my branch and tumbleweed. please provide logs from wpa_supplicant.

[Reiokorn (reiokorn)]

https://build.opensuse.org/request/show/952644

[Hpj-u (hpj-u)]

Just a heads up:

AVM is still investigating on this.

Some tests with newer hardware confirmed, that WPA3 is working well there.

[Cfamullaconrad (cfamullaconrad)]

Hi Hans-Peter,
do you have updates from AVM?

[Cfamullaconrad (cfamullaconrad)]

From my point of view, it is now fixed in NetworkManger with these two commits:

 * https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/cd1e0193abcf26f523bd52d83af5aab086ceaa92
 * https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/a0988868ba7b4390790cab43cca5103f80a6a300

I would like to remove the work-around of not forwarding SAE capabilities to the
NetworkManager, as this just prohibit WPA3.

Can someone verify, if it now works with NetworkManager and a wifi card which support SAE but do not have the PMF cipher support like CMAC (00-0f-ac:6).

This is the wpa_supplicant package without that patch:
https://build.opensuse.org/package/show/home:cfconrad:branches:hardware/wpa_supplicant

Thanks

[Hp-jansen (hp-jansen)]

(In reply to Clemens Famulla-Conrad from comment #45)
> Hi Hans-Peter,
> do you have updates from AVM?

Ups, sorry, the answer was so disappointing that I forgot to pass it on:

> Thank you for your patience.
>
> The Wi-Fi client you are using "Intel Centrino Advanced-N 6205" is from 2011
> and supports WPA2 only due to its specs:
>
> https://www.compare.de/datacontent.php?EAN=0675901041713
>
> https://ark.intel.com/content/www/de/de/ark/products/59471/intel-centrino-advancedn-6205-dual-band.html
>
> To resolve the issue, the colleagues recommend to perform step 4 in the
> following link:

> Wireless device cannot establish a connection to the FRITZ!Box
> https://en.avm.de/service/knowledge-base/dok/FRITZ-Box-7490/509_Wireless-device-cannot-establish-a-connection-to-the-FRITZ-Box

Considering that I had already told them at the beginning that we are trying to avoid the complete shutdown of WPA3, this statement is already strong stuff.

(In reply to Clemens Famulla-Conrad from comment #46)
> From my point of view, it is now fixed in NetworkManger with these two
> commits:
>
> *
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/
> cd1e0193abcf26f523bd52d83af5aab086ceaa92
> *
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/
> a0988868ba7b4390790cab43cca5103f80a6a300
>
> I would like to remove the work-around of not forwarding SAE capabilities to
> the
> NetworkManager, as this just prohibit WPA3.

You're right.

> Can someone verify, if it now works with NetworkManager and a wifi card
> which support SAE but do not have the PMF cipher support like CMAC
> (00-0f-ac:6).
>
> This is the wpa_supplicant package without that patch:
> https://build.opensuse.org/package/show/home:cfconrad:branches:hardware/
> wpa_supplicant

Will test this again and report, and leave the needinfo flag enabled until then.

[Hp-jansen (hp-jansen)]

(In reply to Hans-Peter Jansen from comment #47)
> > (In reply to Clemens Famulla-Conrad from comment #45)
>
> Will test this again and report, and leave the needinfo flag enabled until
> then.

Hi Clemens,

I can confirm, that current NetworkManager + wpa_supplicant with this patch omitted works fine here with an old X1 and a newer T495.

X1:~# nmcli connection show ::uuid:: | grep -E 'key-mgmt|pmf'
802-11-wireless-security.key-mgmt: wpa-psk
802-11-wireless-security.pmf: 0 (default)

T495:~# nmcli connection show ::uuid:: | grep -E 'key-mgmt|pmf'
802-11-wireless-security.key-mgmt: sae
802-11-wireless-security.pmf: 0 (default)

In fact, I experimentally removed that patch already before vacation leave, but forgot about reporting success..

It's good to go, please submit.

[Cfamullaconrad (cfamullaconrad)]

Hi Hans-Peter Jansen, thanks a lot for your help!

The request is on its way https://build.opensuse.org/request/show/984154