hi! i’m running Fedora 39 Silverblue (actually Universal Blue, also with tuned instead of PPD) and I keep having my WiFi just stop working randomly. it seems to happen way more when i’m using more bandwidth. it fixes itself very quickly by just reconnecting to the network manually, and usually connections are also restored that way.
Please do file a bug report with the Fedora team so they can address this, I am pretty heads down and you all may be able to get this done faster than I as I need cycles to repro. But yes, as Mario indicated, reaching out directly via email may be faster/smoother as this is a wireless mailing list related item.
Yes. Please do test this. We have found power save from 3 to 2 can address issues described, which for Intel cards was an issue at one time.
First see if power save is enabled (2) or not (3).
interface=$(iw dev | awk '/Interface/ {print $2}'); powersave=$(nmcli -t -f 802-11-wireless.powersave connection show "$(nmcli -t -f NAME,DEVICE con show --active | grep ":${interface}$" | cut -d: -f1)"); echo "The name of your wireless interface is: $interface, and the power save setting is: $powersave"
If it’s is showing as “the power save setting is: 802-11-wireless.powersave:enable”, test it this way with it disabled. See if this improves.
nmcli con mod "$(nmcli -t -f NAME,DEVICE con show --active | grep ":$(iw dev | awk '/Interface/ {print $2}')" | cut -d: -f1)" 802-11-wireless.powersave 2
Then check again, then see if the connection behaves (this will reset on reboot, so just for testing)
interface=$(iw dev | awk '/Interface/ {print $2}'); powersave=$(nmcli -t -f 802-11-wireless.powersave connection show "$(nmcli -t -f NAME,DEVICE con show --active | grep ":${interface}$" | cut -d: -f1)"); echo "The name of your wireless interface is: $interface, and the power save setting is: $powersave"
All dealing with this, I need to gather specific details.
Distro/Release:
Kernel:
MediaTek Wireless card firmware version: (Just grab what come up with this in your terminal) sudo dmesg | grep mt7921e
Steps to reproduce: (Ideally easy to duplicate steps are ideal; YouTube, large file transfer LAN or to a cloud provider, etc.)
Wi-Fi Router Type: (Wi-Fi 5, 6, 6E, etc?)
With this, I can escalate this internally and get resources behind this. I can also justify my own limited cycles to see if myself or @Loell_Framework is able to repro this ourselves, gather logs, and get this moving forward.
Steps to reproduce: (Ideally easy to duplicate steps are ideal; YouTube, large file transfer LAN or to a cloud provider, etc.)
Use bandwidth. Usually, the more you use, the faster it happens. (Seriously; it has happened when downloading Linux ISOs over BitTorrent, while watching YouTube, while being on a Jitsi Meet, etc.)
Hrm - I have been montioring this relatively closely and I am thinking it’s to do with AP setups which have different regulatory domains set. I have a relatively complex network and I am seeing two potential antecedents to this which involve bgscan and changing the regulatory domain. My guess is the mt driver isn’t able to cleanly deal with switching between AP’s where there is a different regulatory domain set as I get drop outs whenever I get steered from one AP to another and am seeing this:
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: Trying to associate with 24:4b:fe:62:67:04 (SSID='kainga-atawhai' freq=5500 MHz)
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=NZ
May 03 12:29:42 emiemi NetworkManager[1456]: <info> [1714696182.3650] device (wlp1s0): supplicant interface state: authenticating -> associating
May 03 12:29:42 emiemi NetworkManager[1456]: <info> [1714696182.3650] device (p2p-dev-wlp1s0): supplicant management interface state: authenticating -> associating
May 03 12:29:42 emiemi kernel: wlp1s0: associate with 24:4b:fe:62:67:04 (try 1/3)
May 03 12:29:42 emiemi kernel: wlp1s0: RX ReassocResp from 24:4b:fe:62:67:04 (capab=0x1511 status=0 aid=2)
May 03 12:29:42 emiemi kernel: wlp1s0: associated
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: Associated with 24:4b:fe:62:67:04
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
May 03 12:29:42 emiemi kernel: wlp1s0: Limiting TX power to 24 (24 - 0) dBm as advertised by 24:4b:fe:62:67:04
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: WPA: Key negotiation completed with 24:4b:fe:62:67:04 [PTK=CCMP GTK=CCMP]
May 03 12:29:42 emiemi wpa_supplicant[3280]: wlp1s0: CTRL-EVENT-CONNECTED - Connection to 24:4b:fe:62:67:04 completed [id=0 id_str=]
May 03 12:29:42 emiemi wpa_supplicant[3280]: bgscan simple: Failed to enable signal strength monitoring
May 03 12:29:42 emiemi NetworkManager[1456]: <info> [1714696182.5240] device (wlp1s0): supplicant interface s
This isn’t an ideal situation but it’s worth a shot, we reverted the firmware on the card to an older version in the latest update to Bluefin last night to see if we can nail it down. If you wouldn’t mind kicking the tyres it would be great feedback, thanks!
I’m not sure if this applies to me; the AP that I usually connect to is always the same AP, with a unique SSID. I can’t find CTRL-EVENT-REGDOM-CHANGE in my dmesg.
Acknowledging the missing CTRL-EVENT-REGDOM-CHANGE taking place in dmesg. We think this may be related, yes. Idea being, we have a custom environment while it would mean an install (spare Nvme if you have one works), but it would allow us to see if the behavior replicates on the previous firmware with Bluefin (a HIGHLY customized Fedora Silverblue image)
I asked Jorge and the team to see if they could help me with this, putting this together as a method of verifying firmware differences to see if the issue clears up.
The idea is expanding on what @jwp indicated, seeing if the firmware is the culprit with the hand off. I know this isn’t ideal, but as we cannot repro this here, we want to flag the correct fault - AP, Wi-Fi environment or as I suspect, Firmware.
Please link to this thread and because it sounds like you’re on Bluefin, please run:
ujust logs-this-boot > thisboot.txt and attach the thisboot.txt file which will appear in the home directory in the ticket. Ask the agent to send to my assigned ticket queue.
I have had multiple folks try to replicate this on Fedora and two others on Bluefin, no luck thus far.