Arch Linux

You can obtain older versions of the kernel from the ALA [1] for testing. Once you have determined which package update introduced the issue you can bisect it with git [2].
[3] Has links to some prebuilt kernels bisecting between 5.18 and 5.19. If you want more help bisecting the issue please start a thread on the forums.

[1] https://wiki.archlinux.org/title/Arch_Linux_Archive
[2] https://wiki.archlinux.org/title/Bisecting_bugs_with_Git
[3] https://bbs.archlinux.org/viewtopic.php?pid=2053777#p2053777

Yeah, it smells like a kernel regression which needs bisecting. I wonder if it only affects your specific hardware? The info provided by @loqs is exactly what's required to track down bugs like this.

Thanks for the instructions. Using the packages from the ALA, I was able to find this is a regression introduced between linux-5.19.1.arch2-1 and linux-5.19.2.arch1-1.
I'm going to try to bisect it now :)

Edit: I have to go somewhere else, and I won't have access to WPA3 AP for a few days. I'll be able to finish the bisect and post the result later this week.

I had to bisect using the PKGBUILD of the linux package retrieved with asp (using archlinux/linux) because the upstream repository used by `linux-git` doesn't include tags for 5.19.1/5.19.2 (only v5.19) for some reasons.

The full bisect log is attached.


7a53ad13c09150076b7ddde96c2dfc5622c90b45 is the first bad commit
commit 7a53ad13c09150076b7ddde96c2dfc5622c90b45
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu Apr 14 16:50:57 2022 +0200

wifi: cfg80211: do some rework towards MLO link APIs

[ Upstream commit 7b0a0e3c3a88260b6fcb017e49f198463aa62ed1 ]

In order to support multi-link operation with multiple links,
start adding some APIs. The notable addition here is to have
the link ID in a new nl80211 attribute, that will be used to
differentiate the links in many nl80211 operations.

So far, this patch adds the netlink NL80211_ATTR_MLO_LINK_ID
attribute (as well as the NL80211_ATTR_MLO_LINKS attribute)
and plugs it through the system in some places, checking the
validity etc. along with other infrastructure needed for it.

For now, I've decided to include only the over-the-air link
ID in the API. I know we discussed that we eventually need to
have to have other ways of identifying a link, but for local
AP mode and auth/assoc commands as well as set_key etc. we'll
use the OTA ID.

Also included in this patch is some refactoring of the data
structures in struct wireless_dev, splitting for the first
time the data into type dependent pieces, to make reasoning
about these things easier.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 9 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +-
drivers/net/wireless/marvell/libertas/mesh.c | 10 +-
drivers/net/wireless/marvell/mwifiex/11h.c | 2 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 18 +-
drivers/net/wireless/microchip/wilc1000/cfg80211.c | 3 +-
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 14 +-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 2 +-
drivers/net/wireless/quantenna/qtnfmac/event.c | 15 +-
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 4 +-
include/linux/ieee80211.h | 3 +
include/net/cfg80211.h | 99 +++-
include/uapi/linux/nl80211.h | 28 +
net/mac80211/cfg.c | 8 +-
net/mac80211/mlme.c | 2 +-
net/wireless/ap.c | 46 +-
net/wireless/chan.c | 196 +++++--
net/wireless/core.c | 28 +-
net/wireless/core.h | 13 +-
net/wireless/ibss.c | 57 +-
net/wireless/mesh.c | 31 +-
net/wireless/mlme.c | 74 +--
net/wireless/nl80211.c | 623 +++++++++++++++------
net/wireless/ocb.c | 5 +-
net/wireless/rdev-ops.h | 32 +-
net/wireless/reg.c | 139 +++--
net/wireless/scan.c | 8 +-
net/wireless/sme.c | 102 ++--
net/wireless/trace.h | 86 ++-
net/wireless/util.c | 44 +-
net/wireless/wext-compat.c | 48 +-
net/wireless/wext-sme.c | 29 +-
33 files changed, 1255 insertions(+), 533 deletions(-)

Good work on the bisection! Did you end up reporting this upstream? Is the problem still happening? Please let us know.

Ping?

Related [1]

[1] https://github.com/systemd/systemd/issues/24585

Sorry, I was very busy last month.

I didn't report the issue upstream because the bisection was done against archlinux/linux and the kernel bug tracker ask to report bugs to distributions.
I think that commit IDs in the bisect log will not match the upstream repo? i.e, the first bad commit reported is 7a53ad13c09150076b7ddde96c2dfc5622c90b45 but its description says it's 7b0a0e3c3a88260b6fcb017e49f198463aa62ed1 upstream.
However, if you think a report would still be accepted as-is, I can send it upstream.

I worked around the bug, so it's not really impacting me anymore. I'll check again if this still happens on 6.0.8 when I will have access to a WPA3 AP (likely next weekend).

> and the kernel bug tracker ask to report bugs to distributions

That's to stop non-technical users from spamming them...Arch users tend to be more tech savvy and should be capable of submitting a good bug report :P

However, the kernel bugzilla can sometimes be a dead end. You could always try emailing the patch author directly with your findings. But definitely worth trying the latest kernel first (even the latest -rc which you can find already built here [1])

[1] https://wiki.archlinux.org/title/Unofficial_user_repositories#miffe

I was able to reproduce on 6.0.8.

Reported to the kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216711

Patch has been committed in c38c701851011c94ce3be1ccb3593678d2933fd8[1] which was released in 6.3-rc1 and backported to 6.2.3.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c38c701851011c94ce3be1ccb3593678d2933fd8