I just got and built my Batch 1 Ryzen 7AI 350 laptop. Love it so far! I put Bazzite on it, and am mostly able to get all the software I need (looking forward to Ubuntu support since I do a LOT of bioinformatics and compiling stuff myself gets boring), but I have been having one issue: my wifi keeps dropping in and out, randomly. Has anyone else seen this before? I’m hoping that it’s Bazzite (which I am not familiar with, and may not keep) and not the hardware…
1 Like
Moved your thread to Linux subcategory and added Bazzite tag.
1 Like
Solved it. As it turns out Bazzite plays a bit loose with MAC addresses in some strange way. My TP-Link DECO wifi system let me know that it suspected a “cloned” MAC was on the network. Long story short, configure Bazzite with a firm and unchanging MAC and now the TP-Link network is fine.
2 Likes
Thanks for sharing this. We’re actively working on trying to track down a possible issue in the latest linux-firmware package that had not presented any symptoms on Bazzite previously, but this may be a clue to what is causing the issue we’re tracking. cc @Matt_Hartley
2 Likes
Happy to be of assistance. As an aside, I’m a bioinformaticist and as such Bazzite isn’t really the best bistro for me to use - I will be switching to either BioArch Linux or, failing that, wait for Ubuntu to become supported on the Ryzen 7 AI 300 series. Either way I’m happy to help troubleshoot those as well if needed. 
One final update: the problem recurred, and I suspect that my “temporary” change of the MAC didn’t hold. So, I edited:
/etc/NetworkManager/system-connections
and made certain that MACAddressPolicy=persistent was set (instead of random). I’m not 100% that this fixes Bazzite and TP-Link Deco Wifi, but it’s at least one more tiny-a** step in the right direction
Interesting and yes, this can help prevent common drop issues. I will explain what this does for those read this.
What it does:
Setting MACAddressPolicy=persistent in your Wi-Fi connection profile tells NetworkManager to always use your real hardware MAC address instead of a randomly generated one. This disables MAC randomization for that specific connection.
Why it might work for others as needed:
Some routers and mesh systems (like TP-Link Deco) may treat each randomized MAC as a new device, causing issues such as:
-
reauthentication loops
-
DHCP lease confusion
-
throttling or de-prioritization
-
dropped connections
When this might help:
-
You’re using a mesh network like TP-Link Deco
-
You experience random Wi-Fi drops or reconnections
-
You’re on a distro with MAC randomization enabled by default
How to apply it using nmcli:
- List your active connections:
nmcli connection show
- Set the MAC policy to persistent:
nmcli connection modify "<your-connection-name>" 802-11-wireless.mac-address-randomization persistent
- Restart the connection:
nmcli connection down "<your-connection-name>" && nmcli connection up "<your-connection-name>"
When it helps:
-
On routers or mesh systems (like TP-Link Deco) that treat MAC-randomized clients as new devices every time, switching bands (2.4 GHz ↔ 5 GHz) can trigger a reauthentication or reassignment.
-
With a persistent MAC, your device is recognized as the same client, making frequency transitions smoother and less error-prone.
When it doesn’t help:
-
If the drop is due to firmware or driver issues on your Wi-Fi card (like MediaTek MT7925e or similar), especially in Linux, MAC policy won’t fix that.
-
If the kernel, firmware, or Wi-Fi driver mishandles band steering, this requires driver or firmware fixes, not MAC adjustments.
Rough Summary Table (your results may vary)
| Symptom | MAC Randomization | Firmware/Driver |
|---|---|---|
| Drops at connect or boot | Yes | No |
| Router shows device multiple times | Yes | No |
| Mid-session drops, especially on load or band switch | No | Yes |
Only fixed by reboot or modprobe -r |
No | Yes |
| Logs show random MACs | Yes | No |
| Logs show firmware errors/timeouts | No | Yes |
My Batch 3 Ryzen 7 AI 350 doesn’t connect to a 5Ghz-only Fritz 7490/1750E mesh network running Fedora 42. Both Fritz’s are on the latest FW.
Updated to the latest firmware build April 25:
$ sudo dmesg | grep mt7925
[ 18.127270] mt7925e 0000:c0:00.0: ASIC revision: 79250000
[ 18.202559] mt7925e 0000:c0:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250425072955a
[ 18.545249] mt7925e 0000:c0:00.0: WM Firmware Version: ____000000, Build Time: 20250425073109
[ 19.908320] mt7925e 0000:c0:00.0 wlp192s0: renamed from wlan0
$ uname -r
6.14.5-300.fc42.x86_64
and tried, with DHCP, these 3 recommended Wifi settings without results 
:
$ nmcli connection show "d7c131fa-5bad-4427-942c-a7bb67cdf7e0" | grep -iE 'mac-address-randomization|cloned-mac-address|powersave'
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization:never
802-11-wireless.powersave: 2 (disable)
$ iw dev wlp192s0 get power_save
Power save: off
These work fine 
- Fedora 42 connecting to a Personal Hotspot on iPhone and
- Windows 11 connecting to the Fritzbox 7490 mesh network
- Fedora 42 without DHCP with a fixed ip-address on WLAN
Anything I can test or try to make the Mediatek MT7925 work with my Mesh network and DHCP? Or should I wait for a newer kernel or firmware?
You tried setting a static MAC address on n the network settings for your mesh?
One more update: I replaced the stock Mediatek Wifi card with a refurbished AX210 (purchased directly from Framework). Casual use so far indicates that it did fix the problem with Ubuntu, and seems to have made connectivity in Bazzite far more reliable as well. It also has the advantage of being somewhat faster in my ad-hoc testing. I’ll report back if I have any updates…