Recently (last couple of months), I've been having issues with Wifi on my Asus Zenbook. While a recent (kernel version 6.13.x) fixed it, I figured compiling all of the info I found into one spot might help someone else.

System Information

Laptop

Zenbook U5401R (AMD-based ASUS laptop)
Fedora 40
Kernel 6.10.x
MEDIATEK MT7922 802.11ax PCI Express Wireless Network Adapter

Upstream

My Access Point is a Ubiquiti U6 Pro. It's connected to a USW Lite 8 PoE switch (the only thing on it) and that's connected to a UDM Pro. While I did experience a power outage recently, none of the other devices connected to my Wifi / Gateway are having issues.

The U6 Pro is broadcasting on both 2.4GHz and 5GHz bands. I live in a very noisy environment for Wifi signals. These might contribute, but again, I only see this issue with this my single device.

Firmware Versions

I was experiencing this with:

mt7xxx-firmware-20250311-1
mt7xxx-firmware-20241110-1
mt7xxx-firmware-20240909-1

but possibly not with

mt7xxx-firmware-20240610-1

The issue I have is that I don't necessarily use my laptop all that often.

Issue Markers

The first sign I was getting was "IP Configuration was Unavailable" error from NetworkManager. This would happen every minute or so as NetworkManager tried reconnecting to the AP. Notably, it is connecting to the AP, but then something fails and it disconnects (you may also see the "This device appears to be connected to a network but is unable to reach the Internet" error, as well).

In journalctl, I see the following messages:

NetworkManager[$PID$]: <info>  [$UNIX_TIMESTAMP] device (wlan0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
NetworkManager[$PID]: <warn>  [$UNIX_TIMESTAMP] device (wlan0): Activation: failed for connection '$CONNECTION_NAME'
NetworkManager[$PID]: <info>  [$UNIX_TIMESTAMP] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')

The name of the connection may also be wlp1s0, depending on your system's network configuration.

Additionally, there are a significant number of messages in the log related to CTRL-EVENT-SIGNAL-CHANGE:

wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-63 noise=9999 txrate=8600
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-62 noise=9999 txrate=8600
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-62 noise=9999 txrate=8600
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-62 noise=9999 txrate=8600
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-61 noise=9999 txrate=8600
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-79 noise=9999 txrate=17200
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-79 noise=9999 txrate=17200

Though I'm pretty sure that's normal behavior.

Additionally, in trying to troubleshoot the issue and recreate the connection, I was also occasionally getting incorrect password prompts, and the following line in journalctl:

wpa_supplicant[$PID]: wlp1s0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect

If I run systemctl restart NetworkManager after boot, then sometimes it connects (a successive restart connects if it doesn't the first time?), but it isn't stable, and will continually connect and drop the connection. Sometimes if I then reboot, it will come back for moments at a time.

Finally, the following message will also show up at times when a connection is successful:

kernel: wlp1s0: deauthenticated from 6e:22:32:ee:db:4f (Reason: 34=DISASSOC_LOW_ACK)
wpa_supplicant[$PID]: wlp1s0: CTRL-EVENT-DISCONNECTED bssid=$MAC_ADDRESS reason=34

Reason 34 is "Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions."

Things I Didn't have

• I did not see any issues related to the mt7921e driver in dmesg's output. Similar issues from threads I found did have that.

Attempted Solutions

Disabling Powersave via NetworkManager

Adding:

[connection]
wifi.powersave = 2

to NetworkManager's config (I did it via adding /etc/NetworkManager/conf.d/wifi-powersave-off.conf).

While this seemed to leave the connection on for longer before failure, it still dropped.

Enabling / Disabling BIOS Fastboot

Based on this ongoing GitHub issue thread, I tried enabling "Fast Boot" in the BIOS, since I had already disabled it, previously. I saw no change in the issue behavior.

"Solution"

After updating (...again) to kernel 6.13.7-100, I stopped having issues. Still running mt7xxx-firmware version 20250311-1.

While I'm happy about this, the ~1,300 words that I've written here makes this feel like a hollow victory. Running updates when your network connection is flaky is not the easiest, either.

Addenda

Other Laptop / ASUS Thoughts

I have been pleased with many things about this laptop, and incredibly frustrated with a few other things.

The good:

• The OLED Screen is beautiful.
• The performance is Fine(TM).
• The touchscreen precision is great (I was still using my old Surface Book 2 pen on it, because I think the ASUS pen sucks).
• Battery life is decent.

The bad, though...

ASUS' model naming makes it very difficult to search for issues. Not the names themselves, "UN5401R" is certainly a unique string, but in debugging prior issues, I found it nearly impossible to find the product information page on ASUS' own site, weeks after I'd bought the laptop. They seem to cycle their products so quickly that any given model is available for a short period and then replaced by something else, which makes searching for issues that might be related to your particular model hard. In addition, because of the mixing of Intel and AMD chipsets within a model, two users may think they have similar hardware and have very different hardware. Trying to figure out the differences between revisions (UN5401Q, UN5401QA, UN5401R, UN5401QAB(?)) is likely difficult for anyone that doesn't have the internal spreadsheet that I know someone in ASUS has.

The "AMD Sensor Fusion HUB" is not well-supported inside of the Linux kernel. This bug seems to be the one tracking information, but it was opened in 2021, and last updated in January of 2024. The Asus Linux Drivers repository has a discussion about this issue, but following the link chain leads to using this userland service for flip events, which has some limitations since it's using the accelerometer for detecting the screen state. I think I tried it and still found that it had the issue of not disabling the keyboard / touchpad like I expected (in Wayland), but that was awhile ago.

Bug Report

"Why didn't you submit a bug report?"
Because I had no idea where or what to submit. I don't have a meaningfully reproducible test case, and even if I did, is this a NetworkManager issue, a wpa-supplicant issue, a Fedora issue, a MT7922 hardware issue, a driver issue, or something else? The issue potentially started well before I was actually aware of it, and with how often I've been using this laptop, I couldn't pin down a single change that triggered it, either.

Fun Postscript

While debugging this, I also ran into an issue where, if you have DNF aliases configured to use the cache, like so:

$ dnf alias 
Alias deplist='deplist --nogpgcheck --cacheonly --assumeno --quiet'
Alias info='info --nogpgcheck --cacheonly --assumeno --quiet'
Alias list='list --nogpgcheck --cacheonly --assumeno --quiet'
Alias provides='provides --nogpgcheck --cacheonly --assumeno --quiet'
Alias repoquery='repoquery --nogpgcheck --cacheonly --assumeno --quiet'
Alias search='search --nogpgcheck --cacheonly --assumeno --quiet'

and get the error message:

Error: Cache-only enabled but no cache for 'fedora' (or some other repo), then you may be running into this bug. A workaround is to add optional_metadata_types=filelists in your /etc/dnf/dnf.conf, taken from the first post of this discussion. Thanks to R Haley for reading the documentation about the change on the Fedora wiki, including the documentation / config change.