mt7921e (MT7902/Filogic 310): intermittent auth timeout + post-associate deauth (Reason 3, DEAUTH_LEAVING) + DHCP timeout, reproduced across unrelated APs

Hardware

• MediaTek MT7902 802.11ax PCIe Wireless Network Adapter [Filogic 310]
• Subsystem: AzureWave Device 5520
• PCI ID: 14c3:7902
• Driver: mt7921e
• ASIC revision: 79020000
• HW/SW Version: 0x8a108a10
• Firmware version: ____000000, Build Time: 20251212032127
• Laptop: ASUS VivoBook 15 F1504ZA

Kernel / OS

• Fedora 44
• 7.1.3-201.fc44.x86_64
• NetworkManager-1.56.1-2.fc44.x86_64

Describe the bug

Intermittent WiFi instability, reproduced on two completely unrelated
networks (home router with two BSSIDs on the same SSID across 2.4GHz/5GHz,
and a separate unrelated phone hotspot), which rules out AP-specific
misconfiguration as the root cause.

Symptoms observed, varying between connection attempts on the same
session:

1. Auth timeout — repeated send auth (try 1-3/3) with no response,
   ending in authentication timed out.

2. Successful auth+associate followed by self-initiated deauth after
   a consistent ~45 seconds:
   wlo1: authenticated
   wlo1: associate with (try 1/3)
   wlo1: RX AssocResp from (capab=0x11 status=0 aid=4)
   wlo1: associated
   wlo1: Limiting TX power to 30 (30 - 0) dBm as advertised by
   [~45s later]
   wlo1: deauthenticating from by local choice (Reason: 3=DEAUTH_LEAVING)
   The 45s window matches NetworkManager's DHCP4 transaction timeout.
   journalctl debug logs (domains DHCP4,IP4) confirm the client sends
   repeated DHCPDISCOVER with no DHCPOFFER received in that window,
   after which NetworkManager itself issues the deauth. This suggests
   the deauth is a NetworkManager-side reaction to DHCP failure, not
   an AP-initiated event — but it's unclear whether the DHCP failure
   itself is triggered by something upstream in the driver's link
   state reporting (e.g. the AP considering the client still fully
   connected while userspace does not).

3. "ssid-not-found" failures for networks visible seconds earlier
   in nmcli device wifi list / iw dev wlo1 scan, suggesting a
   possible desync between scan results cache and the association
   path.

All three symptoms were reproduced against both the home router and an
unrelated phone hotspot, on the same boot session, with no config changes
between attempts — ruling out AP-side causes (DHCP pool exhaustion, MAC
filtering, band/channel issues) for at least the auth-timeout and
ssid-not-found symptoms.

Steps already ruled out (no effect on reproducibility)

• Forcing wifi.powersave off (persistent via NetworkManager conf.d)
• Forcing cloned-mac-address to permanent (vs. default stable-ssid)
• Forcing 802-11-wireless band/channel manually
• Recreating the NetworkManager connection profile from scratch
• Router reboot (ruled out DHCP pool/router-side issue, since the
  phone hotspot reproduces the same instability)

Expected behavior

Stable connection and session persistence, consistent between different
access points, without recurring auth timeouts or DHCP-window deauths.

Additional notes

Behavior is non-deterministic — the same network sometimes connects on
the first attempt and holds for extended periods, other times requires
several minutes of repeated nmcli connection up retries. Willing to
gather additional debug logs (wpa_supplicant DEBUG level, iw event
capture, etc.) if useful for diagnosis.

Start with the mt7921e driver and the reported NetworkManager DHCP4/IP4 journal logs, then collect the suggested wpa_supplicant DEBUG output and an iw event capture during failed attempts. Compare authentication, association, link-state, and DHCP timing across the home router and phone hotspot; done requires identifying a reproducible driver-side failure and demonstrating stable connections on both access points.