mt7921e: 5GHz authentication fails/times out on channel 161 (works fine on Windows, 2.4GHz unaffected)

Summary

mt7921e fails to authenticate to a 5GHz AP on channel 161 (5805 MHz), retrying repeatedly and eventually failing with ssid-not-found, while the same card connects to the same router's 2.4GHz radio without issue. The same laptop connects to this AP's 5GHz network without any problem when booted into Windows, indicating the issue is specific to the Linux mt7921e/mt76 driver stack rather than the hardware or the AP itself.

System information
Laptop: Lenovo LOQ 15ARP9 (Type 83JC), AMD Ryzen 5 7235HS
Wi-Fi card: MediaTek MT7921 802.11ax PCIe Wireless Network Adapter (Filogic 330)
Driver: mt7921e
ASIC revision: 79610010
Firmware: WM Firmware Version ____010000, Build Time 20260224110949
HW/SW Version: 0x8a108a10, Build Time 20260224110909a
OS: Fedora Workstation 44
Kernel: 7.1.12-200.fc44.x86_64
wpa_supplicant: v2.11 (wpa_supplicant-2.11-9.fc44.x86_64)
NetworkManager: 1.56.1-2.fc44.x86_64
BIOS: PQCN22WW (EC: PQEC22WW)
linux-firmware was already up to date at time of testing (dnf update linux-firmware reported nothing to do)
AP information
SSID broadcasting both 2.4GHz (MyNetwork_2.4) and 5GHz (MyNetwork_5) bands from what appears to be an ISP-provided gateway
5GHz band: channel 161, 5805 MHz (confirmed via scan — not a DFS channel)
Security: WPA2/WPA3 mixed mode (key_mgmt: WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE)
Gateway/subnet: 192.168.1.0/24
2.4GHz band on the same AP connects and authenticates without issue
Symptom

Every connection attempt to the 5GHz network fails at the authentication stage. wpa_supplicant/NetworkManager logs show a repeating pattern:

supplicant interface state: scanning -> authenticating
supplicant interface state: authenticating -> disconnected

This repeats several times (typically 5–6 attempts over ~25–30 seconds) before NetworkManager gives up with:

Activation: (wifi) association took too long, failing activation
state change: config -> failed (reason 'ssid-not-found', managed-type: 'full')

Kernel-level (dmesg) output during a failed attempt:

wlo1: authenticate with f8:0c:58:xx:xx:xx (local address=xx:xx:xx:xx:xx:xx)
wlo1: send auth to f8:0c:58:xx:xx:xx (try 1/3)
wlo1: send auth to f8:0c:58:xx:xx:xx (try 2/3)
wlo1: send auth to f8:0c:58:xx:xx:xx (try 3/3)
wlo1: authentication with f8:0c:58:xx:xx:xx timed out

No response is received from the AP to any of the three authentication frame retries — this is a raw 802.11 auth timeout, not a rejection with a status code.

Troubleshooting already performed (ruled out)
Signal strength: 59% (approx. -60 to -65 dBm) at time of testing — not a range/weak-signal issue
Regulatory domain: country NP: DFS-JP; channel 161 (5735–5835 MHz range) is explicitly permitted, non-DFS
PCIe ASPM: tested both with ASPM disabled (pcie_aspm=off kernel param + mt76 disable_aspm=1 module option) and with ASPM fully re-enabled (all overrides removed) — no change in behavior either way
NetworkManager IPv4 config: connection profile is clean/default, no ignore-auto-routes/ignore-auto-dns overrides (this was a separate, unrelated bug we found and fixed earlier — a stale profile setting that caused "connected but no internet"; not related to the auth failure)
PMF (Protected Management Frames): tested with wifi-sec.pmf=1 (optional) — no change. This also drops SAE/WPA3 from the negotiated key_mgmt list entirely (falls back to WPA-PSK WPA-PSK-SHA256 FT-PSK), and the plain WPA2-only attempt fails identically
WPA3-SAE specifically: ruled out by the PMF test above — failure is identical whether WPA3-SAE is offered or not
Wi-Fi power save: confirmed off (iw dev wlo1 get power_save → off) throughout testing
rfkill: not soft- or hard-blocked
udev rules / module blacklist / NetworkManager unmanaged flags: none present affecting this device
BIOS Wireless LAN setting: confirmed Enabled
linux-firmware: already at latest version available via dnf
Expected behavior

mt7921e should authenticate and associate to the 5GHz network the same way it does on Windows with the same card and the same AP.

Additional notes
The failure is consistent and reproducible on-demand — not a rare/intermittent event, though on some occasions the connection has eventually succeeded after 4–5 automatic retries (~20 seconds), suggesting a possible timing-sensitive race in the authentication exchange rather than a hard rejection every time.
2.4GHz on this same AP/gateway has been completely reliable throughout testing, which points at something specific to the 5GHz/channel 161 negotiation path rather than the driver, the AP, or the client being broadly broken.
Happy to provide a full wpa_supplicant debug log (-ddd), a packet capture, or test any suggested kernel module parameters / patches.

Start at the mt7921e/mt76 authentication path and reproduce the failure on the channel 161, 5GHz network described in the report. Collect the offered full wpa_supplicant debug log (-ddd) or a packet capture, then compare the authentication exchange with the working 2.4GHz case. Done means the adapter reliably authenticates and associates on channel 161.