[TRACKING] WiFi drops out (especially when downloading a lot) but fixes instantly by reconnecting (AMD)

[Matias]

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.

[Matt_Hartley]

@Matias

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.

[Matt_Hartley]

@Matias

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.

Testing this now, on Bluefin pushing 4k video on two separate instances with no drop out. The older firmware was auto-updated.

Please do keep us updated as we have yet to be able to repro this and we lack logs to pass along for a bug report.

[Matias]

I just was able to accidentally reproduce it while on a Jitsi Meet call with version:

[   15.976914] mt7921e 0000:01:00.0: ASIC revision: 79220010
[   16.054399] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240219103244a
[   16.451150] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240219103337
[   17.611006] mt7921e 0000:01:00.0 wlp1s0: renamed from wlan0

I don’t see anything in the dmesg that refers to the drop-out, only messages when I manually reconnect.

I believe this is the updated firmware. Should I try the outdated firmware then?

[Matt_Hartley]

@Matias

I don’t see anything in the dmesg that refers to the drop-out, only messages when I manually reconnect.

I believe this is the updated firmware. Should I try the outdated firmware then?

Let’s get you into a ticket so I can review your logs.

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.

[James3]

Hi,

I have seen similar symptoms but in a different scenario.
A laptop wifi client and an AP that has a mediatek wifi chip in it.
At times I get packets being lost over wifi, and a manual reconnect of the wiki link on the laptop resumes normal operation.
There are no messages in the syslog logs when the problem occurs.
Also, power cycling the AP, as opposed to just soft rebooting it seems to make the problem go away for longer.
Summary:
Take both the Laptop wifi and the AP wifi chips into account when diagnosing a problem like this. So, the above people mentioning problems should also mention which wifi access point and software version the AP is using, in addition to the Laptop wifi chip being used.

Also, due to various bugs in the Linux kernel wifi code, it is also possible that an extra Wifi client on the AP, can affect this one. So tests should be done by users with all other wifi devices switched off, or mobile phone wifi in airplane mode.

[Matt_Hartley]

Okay folks, I now have access to a WiFi 6E router (mesh, actually, adding even more points to fail and track down for repro). Early testing, zero issues thus far. Some interesting findings here, though.

My eero pro 6E has a feature called steering. Great for coverage, but not always the best for speed.

• On a lark, I disabled steering. My speed climbed an additional 45 Mbps just with this change.

• It bounced it self to the 5ghz range., gained another 35 Mbps. This testing against multiple speed test service, numbers averaged. Clearly deciding to switch things up.

• Tested against a running a 4k video in 2160p the entire time to watch for drops.

• Kernel and distro : 6.8.0-31 generic Ubuntu 24.04.

• MediaTek MT7922 WIFI card, Framework Laptop 13 AMD Ryzen 7040 Series.

• WPA3 Set on router.

• Any and all QoS or steering is OFF.

Going to sit on this config while working tomorrow, see if this sticks or if I was just luckily.

I have AX210s on track for testing this week as well, to compare my findings, Ubuntu 24.04, same kernel as described above.

So what I need now is this:

• Easy to duplicate workflows I can bang against. I need to be able to repro this, but I have limited cycles available. So quick do this paste and run situations are ideal, otherwise if it’s something with very specific steps you provide, I can set aside some time to repro. But I need hyper specifics: actions, packages, ideally sticking within the Fedora/Ubuntu space please, kernels used.

[Matt_Hartley]

Okay, some testing against WiFi 6E (as I’ve never been able to repro on WiFi 5), Framework 16, default MediaTek card, power save off.

Using Bazzite as my control for testing as I can through their devs, control my default environment - as I mentioned previously, I have Bazzite using a previous firmware release (per my request for FW images). First call of the day over G Meet, video call.

Used Brave, a patched kernel (a patched kernel that makes for a nice control as it is known to be highly optimized). These are Bazzite defaults that I know are very good, hence why I am testing against it as it’s basically a highly customized F40 Atomic image.

Butter smooth, absolutely delightful over 4 mesh hops. Bazzite’s lead has had the same experience in calls as I have had, FW 16, MediaTek.

---

Fedora 39 MediaTek testing:
Now the next test will be Fedora 39, fully updated including the latest firmware (which differs from Bazzite). I will again, be testing against Brave and this time, also testing against Chrome as well.

Fedora 40 MediaTek testing:
Now the next test will be Fedora 40, fully updated including the latest firmware (which differs from Bazzite). I will again, be testing against Brave and this time, also testing against Chrome as well.

F39/F40 use the same MediaTek firmware release I believe, when fully updated. If by some chance I am still unable to repro the call drop issue or the drop issue pushing large files back and forth, those affected here can compare notes.

AX210 testing:
Tomorrow. This is my next phase of focus. Same 6E network. Ubuntu 24.04 and Fedora 40.

(Image has IP data removed, it is present)

[Matt_Hartley]

Now testing Fedora 39 on FW 16, current MediaTek firmware provided by dnf. Kernel is 6.8.9.

Wi-Fi 6E.
WPA3 enabled.
No QoS or “client steering” enabled on the router. <—this is important
Bluetooth on, Bluetooth off.
3.03 FW 16 BIOS.

Testing has been a mix of Google Meet video calls on the Brave browser while pushing 4k YT scenic videos for hours at a time in the background.

---

Tomorrow, I do some testing with Intel AX210 (be it not officially supported by AMD) on AMD Ryzen boards. Same basic principles in testing as above.

[Alex_S]

So it’s looking good on Bazzite?

[Matt_Hartley]

@Alex_S

So it’s looking good on Bazzite?

Yes, ran F39 on last night, 10 hour 4K video, no drops there either.

[Matt_Hartley]

Okay, F39 is also good to go. Fully updated, of course.

Testing F39/F40, the AX210 card is seeing similar speeds to MediaTek, almost a match. This is on Wi-Fi 6E, 6Ghz confirmed as well.

Folks experiencing drops, please use this script, and you can attach both logs created after a full 60 minutes of running and provide this to support with this forum post as well.

Please use this: GitHub - FrameworkComputer/network-tester: MediaTek/Intel Wi-Fi Drop Tester

[Matt_Hartley]

For AX210 on FW16 (not officially supported), using my script, captured two drops and the time stamps with video chatting for a full hour. Going to compare this with the dmesg/journal now.

---

For AX210, using the above script, captured two drops and the time stamps. Going to compare this with the dmesg/journal now. Below are the details of one of them.

Without my script, I’d missed this as I am multitasking and these drops were only 10 seconds.

This was during a video call. Using a fake SSID for these posts.

---

Here is the clipped area my script caught for iw_logfile, giving me a time stamp.

---------------------------
Thu May 16 01:54:45 PM PDT 2024:
Connected to d8:8e:d4:7d:2e:c8 (on wlp5s0)
	SSID: MEH
	freq: 6135.0
	RX: 1338030973 bytes (974265 packets)
	TX: 804649852 bytes (812745 packets)
	signal: -51 dBm
	rx bitrate: 1921.5 MBit/s 160MHz HE-MCS 9 HE-NSS 2 HE-GI 0 HE-DCM 0
	tx bitrate: 1729.6 MBit/s 160MHz HE-MCS 8 HE-NSS 2 HE-GI 0 HE-DCM 0
	bss flags: short-slot-time
	dtim period: 2
	beacon int: 100
---------------------------
Thu May 16 01:54:55 PM PDT 2024:
Not connected.
---------------------------
Thu May 16 01:55:05 PM PDT 2024:
Connected to e8:d3:eb:b8:d2:c7 (on wlp5s0)
	SSID: MEH
	freq: 5180.0
	RX: 682332 bytes (894 packets)
	TX: 550518 bytes (751 packets)
	signal: -64 dBm
	rx bitrate: 432.4 MBit/s 80MHz HE-MCS 8 HE-NSS 1 HE-GI 0 HE-DCM 0
	tx bitrate: 576.4 MBit/s 80MHz HE-MCS 5 HE-NSS 2 HE-GI 0 HE-DCM 0
	bss flags: short-slot-time
	dtim period: 2
	beacon int: 100
	
	journalctl --since "2024-05-16 13:50:00" --until "2024-05-16 13:58:00"

And with this and a little journal action:

journalctl --since "2024-05-16 13:50:00" --until "2024-05-16 13:58:00"

May 16 13:54:48 fedora kernel: wlp5s0: Connection to AP d8:8e:d4:7d:2e:c8 lost
May 16 13:54:48 fedora wpa_supplicant[2341]: wlp5s0: CTRL-EVENT-DISCONNECTED bssid=d8:8e:d4:7d:2e:c8 reason=4 locally_generated=1
May 16 13:54:48 fedora wpa_supplicant[2341]: BSSID d8:8e:d4:7d:2e:c8 ignore list count incremented to 2, ignoring for 10 seconds
May 16 13:54:48 fedora NetworkManager[2272]: <info>  [1715892888.9478] device (wlp5s0): supplicant interface state: completed ->>
May 16 13:54:48 fedora NetworkManager[2272]: <info>  [1715892888.9479] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:49 fedora NetworkManager[2272]: <info>  [1715892889.0391] device (wlp5s0): supplicant interface state: disconnected>
May 16 13:54:49 fedora NetworkManager[2272]: <info>  [1715892889.0391] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:49 fedora wpa_supplicant[2341]: wlp5s0: SME: Trying to authenticate with d8:8e:d4:7d:2e:c7 (SSID='MEH' freq=5180>
May 16 13:54:49 fedora kernel: wlp5s0: authenticate with d8:8e:d4:7d:2e:c7 (local address=9a:25:6c:43:ef:61)
May 16 13:54:49 fedora kernel: wlp5s0: send auth to d8:8e:d4:7d:2e:c7 (try 1/3)
May 16 13:54:49 fedora NetworkManager[2272]: <info>  [1715892889.2763] device (wlp5s0): supplicant interface state: scanning -> >
May 16 13:54:49 fedora NetworkManager[2272]: <info>  [1715892889.2764] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:50 fedora kernel: iwlwifi 0000:05:00.0: Not associated and the session protection is over already...
May 16 13:54:50 fedora kernel: wlp5s0: Connection to AP d8:8e:d4:7d:2e:c7 lost
May 16 13:54:51 fedora kernel: wlp5s0: send auth to d8:8e:d4:7d:2e:c7 (try 2/3)
May 16 13:54:52 fedora kernel: iwlwifi 0000:05:00.0: Not associated and the session protection is over already...
May 16 13:54:52 fedora kernel: wlp5s0: Connection to AP d8:8e:d4:7d:2e:c7 lost
May 16 13:54:53 fedora kernel: wlp5s0: send auth to d8:8e:d4:7d:2e:c7 (try 3/3)
May 16 13:54:53 fedora geoclue[5751]: Failed to query location: Could not connect to location.services.mozilla.com: No route to >
May 16 13:54:54 fedora kernel: iwlwifi 0000:05:00.0: Not associated and the session protection is over already...
May 16 13:54:54 fedora kernel: wlp5s0: Connection to AP d8:8e:d4:7d:2e:c7 lost
May 16 13:54:54 fedora kernel: wlp5s0: aborting authentication with d8:8e:d4:7d:2e:c7 by local choice (Reason: 3=DEAUTH_LEAVING)
May 16 13:54:54 fedora wpa_supplicant[2341]: BSSID d8:8e:d4:7d:2e:c7 ignore list count incremented to 2, ignoring for 10 seconds
May 16 13:54:54 fedora NetworkManager[2272]: <info>  [1715892894.3034] device (wlp5s0): supplicant interface state: authenticati>
May 16 13:54:54 fedora NetworkManager[2272]: <info>  [1715892894.3035] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:54 fedora NetworkManager[2272]: <info>  [1715892894.8079] device (wlp5s0): supplicant interface state: disconnected>
May 16 13:54:54 fedora NetworkManager[2272]: <info>  [1715892894.8080] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: SME: Trying to authenticate with e8:d3:eb:b8:d2:c7 (SSID='MEH' freq=5180>
May 16 13:54:55 fedora kernel: wlp5s0: authenticate with e8:d3:eb:b8:d2:c7 (local address=9a:25:6c:43:ef:61)
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.0422] device (wlp5s0): supplicant interface state: scanning -> >
May 16 13:54:55 fedora kernel: wlp5s0: send auth to e8:d3:eb:b8:d2:c7 (try 1/3)
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.0422] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: Trying to associate with e8:d3:eb:b8:d2:c7 (SSID='MEH' freq=5180 MHz)
May 16 13:54:55 fedora kernel: wlp5s0: authenticated
May 16 13:54:55 fedora kernel: wlp5s0: associate with e8:d3:eb:b8:d2:c7 (try 1/3)
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.0813] device (wlp5s0): supplicant interface state: authenticati>
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.0814] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora kernel: wlp5s0: RX AssocResp from e8:d3:eb:b8:d2:c7 (capab=0x1111 status=0 aid=4)
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: Associated with e8:d3:eb:b8:d2:c7
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
May 16 13:54:55 fedora kernel: wlp5s0: associated
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1092] device (wlp5s0): supplicant interface state: associating >
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1092] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora kernel: wlp5s0: Limiting TX power to 30 (30 - 0) dBm as advertised by e8:d3:eb:b8:d2:c7
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1255] device (wlp5s0): supplicant interface state: associated ->
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1256] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: WPA: Key negotiation completed with e8:d3:eb:b8:d2:c7 [PTK=CCMP GTK=CCMP]
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: CTRL-EVENT-CONNECTED - Connection to e8:d3:eb:b8:d2:c7 completed [id=0 id_s>
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1738] device (wlp5s0): supplicant interface state: 4way_handsha>
May 16 13:54:55 fedora wpa_supplicant[2341]: wlp5s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-56 noise=9999 txrate=245000
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1745] device (wlp5s0): ip:dhcp4: restarting
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1746] dhcp4 (wlp5s0): canceled DHCP transaction
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1746] dhcp4 (wlp5s0): activation: beginning transaction (timeou>
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1746] dhcp4 (wlp5s0): state changed no lease
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1746] dhcp4 (wlp5s0): activation: beginning transaction (timeou>
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.1749] device (p2p-dev-wlp5s0): supplicant management interface >
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.2098] dhcp4 (wlp5s0): state changed new lease, address=192.168.>
May 16 13:54:55 fedora NetworkManager[2272]: <info>  [1715892895.2099] dhcp4 (wlp5s0): state changed new lease, address=192.168.>

---

From the logs, this screams firmware to me (Intel AX210 in this case)

• reason=4: Reason code 4 means “Disassociated due to inactivity”.

• locally_generated=1: This indicates that the disconnection was initiated locally rather than by the access point.

In this case, historically, we would disable power savings. This is for AX210 and is likely a linux-firmware package issue, not us specifically. Regression.

To determine if power save is on (and it likely is):

iw dev | grep Interface | awk '{print $2}' | xargs -I {} iw dev {} get power_save

If this returns: Power save: on

Run this script:

echo -e "[connection]\nwifi.powersave = 2" | sudo tee /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf && sleep 1 && echo -e "\033[1;33mProcess is complete"

and then

sudo systemctl restart NetworkManager

Check again:

iw dev | grep Interface | awk '{print $2}' | xargs -I {} iw dev {} get power_save

Should output: Power save: off

---

Completed testing of AX210 with power saving OFF.

Flawless, no issues whatsoever, no drops. Script and journal confirmed it.

Suggestion for anyone using AX210, continue with this:

To determine if power save is on (and it likely is):

iw dev | grep Interface | awk '{print $2}' | xargs -I {} iw dev {} get power_save

If this returns: Power save: on

Run this script:

echo -e "[connection]\nwifi.powersave = 2" | sudo tee /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf && sleep 1 && echo -e "\033[1;33mProcess is complete"

and then

sudo systemctl restart NetworkManager

Check again:

iw dev | grep Interface | awk '{print $2}' | xargs -I {} iw dev {} get power_save

Should output: Power save: off

---

Final Results

Intel AX210 on FW 16 does indeed see drops for 10 seconds at a time when a drop occurs.
Repeated this, with power saving for wifi disabled and did not see the drop offs.

Noticed something here - see the jump happening here:

Thu May 16 01:54:45 PM PDT 2024:
Connected to d8:8e:d4:7d:2e:c8 (on wlp5s0)
SSID: (fake)
freq: 6135.0

Thu May 16 01:54:55 PM PDT 2024:
Not connected.

Thu May 16 01:55:05 PM PDT 2024:
Connected to e8:d3:eb:b8:d2:c7 (on wlp5s0)
SSID: (fake)
freq: 5180.0

---

---

---

MediaTek card on FW 16 did not see any drop off, even with the defaults of having power save on.

Wi-Fi 6E.
WPA3 enabled.
No QoS or “client steering” enabled on the router. <—this is important
Bluetooth on, Bluetooth off.
3.03 FW 16 BIOS.

[Matt_Hartley]

Pinned this for two weeks for visibility.

[Brody_Brooks]

Apologies for reviving this thread, but I think I’m experiencing a related issue with the MediaTek (MT7922A22M) wi-fi module.

On Bluefin Fedora, I began to notice my FW13 AMD’s wi-fi get weak, then become unreliable, then stop effectively working even after reboot. I thought it might be hardware failure, but then I tried a live session of Fedora 40 Workstation and everything works perfectly. I’ve tried turning Power Save off, as noted above. No change.

Fedora 40 Silverblue, from the Fedora site, fresh Install:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=13473 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=12522 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=7035 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=7978 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=7735 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=7141 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=7909 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=8341 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=9478 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=9452 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=117 time=7024 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=6417 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=117 time=4410 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=117 time=4652 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=117 time=1719 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=117 time=2940 ms

Fedora 40 Workstation, running from a USB drive:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=5.79 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=9.95 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=21.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=9.95 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=24.1 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=20.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=22.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=21.7 ms

The laptop is in the same physical location accessing the same access point in both tests. Both OSs are running the same kernel, so I’m at a loss for what the difference could be.

Here’s a journal from five minutes where I was running the network test script:

brody@unknown06f4c5352847:~$ journalctl --since "2024-07-19 20:40:00" --until "2024-07-19 20:45:00"
Jul 19 20:40:25 unknown06f4c5352847.attlocal.net systemd[2116]: Starting grub-boot-success.service - Mark boot as successful...
Jul 19 20:40:25 unknown06f4c5352847.attlocal.net systemd[2116]: Finished grub-boot-success.service - Mark boot as successful.
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3471]: USER_AUTH pid=3471 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix acct="brody" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3471]: USER_ACCT pid=3471 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="brody" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3471]: USER_CMD pid=3471 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/home/brody" cmd=646E6620696E7374616C6C202D79206C736877 exe="/usr/bin/sudo" terminal=pts/0 res=failed'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: USER_ACCT pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="brody" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net sudo[3528]:    brody : TTY=pts/0 ; PWD=/var/home/brody ; USER=root ; COMMAND=/usr/sbin/dmidecode -s bios-version
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: USER_CMD pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/home/brody" cmd=646D696465636F6465202D732062696F732D76657273696F6E exe="/usr/bin/sudo" terminal=pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: CRED_REFR pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net sudo[3528]: pam_unix(sudo:session): session opened for user root(uid=0) by brody(uid=1000)
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: USER_START pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net sudo[3528]: pam_unix(sudo:session): session closed for user root
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: USER_END pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3528]: CRED_DISP pid=3528 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3534]: USER_ACCT pid=3534 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="brody" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3534]: USER_CMD pid=3534 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/home/brody" cmd=6C736877202D43206E6574776F726B exe="/usr/bin/sudo" terminal=pts/0 res=failed'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3539]: USER_ACCT pid=3539 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="brody" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Jul 19 20:40:41 unknown06f4c5352847.attlocal.net audit[3539]: USER_CMD pid=3539 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/home/brody" cmd=6C736877202D43206E6574776F726B exe="/usr/bin/sudo" terminal=pts/0 res=failed'
Jul 19 20:43:07 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Error during transfer: Curl error (56): Failure when receiving data from the peer for https://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/4354287adab66f1cdd602806d4c93ad4dcc8a44091fd3c20151ed840fc0a1b4e-primary.xml.zck [OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0]
Jul 19 20:43:07 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Downloading: http://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/4354287adab66f1cdd602806d4c93ad4dcc8a44091fd3c20151ed840fc0a1b4e-primary.xml.zck
Jul 19 20:43:09 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Error during transfer: Curl error (56): Failure when receiving data from the peer for https://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/9517548d67732d021dd292e51ba85b1e12a319947bc7c3997570f55a86313a13-filelists.xml.zck [OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0]
Jul 19 20:43:09 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Downloading: http://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/9517548d67732d021dd292e51ba85b1e12a319947bc7c3997570f55a86313a13-filelists.xml.zck
Jul 19 20:43:15 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Error during transfer: Curl error (56): Failure when receiving data from the peer for https://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/595a22498b89177b956a713f1bbbe2d409dd2568b67f9e0fe360870ca08c0741-updateinfo.xml.zck [OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 0]
Jul 19 20:43:15 unknown06f4c5352847.attlocal.net rpm-ostree[3124]: Downloading: http://nnenix.mm.fcix.net/fedora/linux/updates/40/Everything/x86_64/repodata/595a22498b89177b956a713f1bbbe2d409dd2568b67f9e0fe360870ca08c0741-updateinfo.xml.zck
Jul 19 20:43:25 unknown06f4c5352847.attlocal.net systemd[2116]: Created slice background.slice - User Background Tasks Slice.
Jul 19 20:43:26 unknown06f4c5352847.attlocal.net systemd[2116]: Starting systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories...
Jul 19 20:43:26 unknown06f4c5352847.attlocal.net systemd[2116]: Finished systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net NetworkManager[1215]: <info>  [1721447054.8589] dhcp6 (wlp1s0): activation: beginning transaction (timeout in 45 seconds)
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net NetworkManager[1215]: <info>  [1721447054.8601] policy: set 'Jamestown Base' (wlp1s0) as default for IPv6 routing and DNS
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net avahi-daemon[1100]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::1c5:f141:9650:f340.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net avahi-daemon[1100]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address 2600:1700:5d80:25d0:199f:49da:f961:a8a1.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net avahi-daemon[1100]: Registering new address record for 2600:1700:5d80:25d0:199f:49da:f961:a8a1 on wlp1s0.*.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net avahi-daemon[1100]: Withdrawing address record for fe80::1c5:f141:9650:f340 on wlp1s0.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net systemd-resolved[1060]: wlp1s0: Bus client set DNS server list to: 192.168.1.254, 2600:1700:5d80:25d0::1
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Jul 19 20:44:14 unknown06f4c5352847.attlocal.net audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 19 20:44:15 unknown06f4c5352847.attlocal.net NetworkManager[1215]: <info>  [1721447055.5987] dhcp6 (wlp1s0): state changed new lease, address=2600:1700:5d80:25d0::20
Jul 19 20:44:15 unknown06f4c5352847.attlocal.net avahi-daemon[1100]: Registering new address record for 2600:1700:5d80:25d0::20 on wlp1s0.*.
Jul 19 20:44:19 unknown06f4c5352847.attlocal.net systemd[1]: Started pcscd.service - PC/SC Smart Card Daemon.
Jul 19 20:44:19 unknown06f4c5352847.attlocal.net audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 19 20:44:19 unknown06f4c5352847.attlocal.net (pcscd)[3744]: pcscd.service: Referenced but unset environment variable evaluates to an empty string: PCSCD_ARGS
Jul 19 20:44:26 unknown06f4c5352847.attlocal.net systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Jul 19 20:44:26 unknown06f4c5352847.attlocal.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Any suggestions?

[Matt_Hartley]

Really appreciate you bringing this up, especially with the comparison. I’ve been trying to nail this down and I think you may have.

On Bluefin, run super key, update (it’ll be slow, just grab a drink and come back).

Once done, reboot and let me know if anything changed.

Also, comparing the two installs. Is Fedora fully up to date or a little behind? I want to make sure we have Bluefin aligned with where Fedora lands.

Cc @Jorge_Castro for visibility. Jorge, I can circle back with our Geordi La Forge once I can nail this down. For me, it’s not been an issue for a long time, but who knows.

[Brody_Brooks]

Thanks for the reply!

• Fedora 40 Workstation [Fedora 40] was downloaded from fedoraproject.org yesterday (wi-fi works great)
• Fedora 40 Silverblue was downloaded from the same place two days ago (wi-fi unreliable)
• I just downloaded Bluefin GTS [Fedora Linux 39.20240715.0 (Silverblue)] (which is currently based on F39), installed it to the FW13, and while I see that I have wi-fi signal, performing an update fails to run:

0: Command failed: '/usr/bin/rpm-ostree upgrade'
1: '/usr/bin/rpm-ostree' failed: exit status: 1

Location: src/steps/os/linux.rs:273

[Jorge_Castro]

Can you paste in a rpm-ostree status please?

[Brody_Brooks]

This is what I get:

❯ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:gts
                   Digest: sha256:937b915cdd3f3397e707cfb3ded02906c468a1e2c81abd40ba7261c34993ad0d
                  Version: 39.20240715.0 (2024-07-15T12:07:41Z)