Hi all, thanks for taking the time to read this. I have been struggling for a couple of months with regular issues with connectivity. I am relatively naive when it comes to trouble shooting this sort of thing, but am happy to run any commands y’all suggest.
Symptoms: I usually notice the issue when browsing the internet. Webpages will be slow to load, then won’t load at all. This issue persists on both Chrome and Firefox, so I don’t think it is a browser related issue. It also only affects me when I am using my School’s network. When I have my laptop at home I don’t run into this issue. I can fix the issue by disconnecting and reconnecting to the network. This usually buys me about 15 minutes before I run into the same problem. Sometimes I can wait out the ping spike and the connection returns to normal, though this takes between 2 and 5 minutes. Running journalctl -u NetworkManager -f shows that this entry pops up right before the most recent episode:
Oct 28 15:45:08 framework NetworkManager[1156]: <info> [1730151908.9276] dhcp4 (wlp170s0): state changed new lease, address=172.28.21.4
Oct 28 15:45:58 framework NetworkManager[1156]: <info> [1730151958.1467] manager: NetworkManager state is now CONNECTED_SITE
Oct 28 15:46:18 framework NetworkManager[1156]: <info> [1730151978.1893] manager: NetworkManager state is now CONNECTED_GLOBAL
I have tried a variety of fixes, including setting a permanent MAC address, and disabling IPv6 for the network. The school networks are both WPA2-EAP and the issue is present with both. I have tried reaching out the schools IT team, but since the issue is only affecting my machine, they haven’t been able to help very much.
For reference this is what the ping values look like when I am experiencing the issue:
~$ ping 8.8.8.8
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=110 time=41.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=41.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=1284 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=4576 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=5539 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=5397 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=4421 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=3826 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=2877 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=3359 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=2551 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=1557 ms
and during normal function
~$ ping 8.8.8.8
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=110 time=41.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=41.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=41.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=110 time=41.3 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=110 time=41.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=110 time=41.4 ms
Please let me know what other diagnostics I can run to give more info. Thanks again!
Can you provide some information on which wireless network controller you have (either by running nmcli and lspci) and what kind of wireless network you are connecting to and what bands it supports?
I’ve had issues with connection drops on WiFi 6E networks that have the 6 GHz band enabled with some wireless network controllers, but not others.
I’m assuming that you’re using a Framework laptop, based on the hostname. If it’s an AMD version, there can be some flakiness with the default AMD/MediaTek wireless network controller.
Sure thing. I am using a Framework laptop, but with 11th gen intel i5, so that rules out the AMD idea.
isaac@framework:~$ nmcli
wlp170s0: connected to eduroam
"Intel 6E AX210/AX1675* 2x2"
wifi (iwlwifi), F4:7B:09:9B:C6:7F, hw, mtu 1500
ip4 default
inet4 172.28.21.4/17
route4 172.28.0.0/17 metric 600
route4 default via 172.28.0.1 metric 600
lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128
p2p-dev-wlp170s0: disconnected
"p2p-dev-wlp170s0"
wifi-p2p, hw
enp0s13f0u1u1c2: unavailable
"ASIX AX88179"
ethernet (cdc_ncm), A0:CE:C8:B1:12:C6, hw, mtu 1500
DNS configuration:
servers: 129.128.5.233 129.128.76.233
domains: uws.ualberta.ca
interface: wlp170s0
Use "nmcli device show" to get complete information about known devices and
"nmcli connection show" to get an overview on active connection profiles.
The school’s IT suggested forcing the network to use the 5Ghz band only, which i tried this morning. It didn’t resolve the issue
I have a Framework Laptop 16 where I replaced the AMD/MediaTek wireless with the same one that you have (although, the non-vPro version). I don’t think I’ve seen that issue pop up unless it bounces me off of the 6 GHz network down to the 5 GHz network.
I’m wondering if there might be some power management settings that could be set or tweaked. Whie troubleshooting the flakiness I was encountering, I tried making the changes and it helped keep a connection alive a little better.
You can view the current setting by running nmcli connection show ssid and look for 802-11-wireless.powersave. You’ll need to replace ssid in the command with the name of the network (use quotes if the name includes spaces).
Running nmcli connection modify ssid 802-11-wireless.powersave 2should disable power saving. You’ll also need to replace ssid with the name of the network as before.
To revert, run the command, but replace 2 with the original value.
I updated the powersaving options as described but the issue persists. I think it is really linked to dhcp lease renewal. The past few times that I have experienced lag spikes, looking at the output of journalctl -u NetworkManager -f shows that there is usually an entry like dhcp4 (wlp170s0): state changed new lease, address=172.28.21.4 in the minute or two before I notice the issue. Any idea what might be going on?
Is the wireless connection set to use a semi-random MAC address or set to clone the hardware MAC address. I think the default behavior is the former.
I’m wondering if the (privacy-focused) semi-random MAC address could be causing issues when a connection drops and a new lease has to be negotiated?
I have set mine to use the hardware MAC address due to using up DHCP leases when I experiencing issues with the AMD/MediaTek wireless controller.
If you run the nmcli connection show {ssid} command, there should be an entry named 802-11-wireless.cloned-mac-address. If it’s coming back with permanent then it’s using the hardware MAC address rather than a random one.
There is a Fedora change document that provides steps on how to set that via the command line.
I forgot to mention that in my first post. One of the fixes the school suggested was to set a permanent MAC address. You command returns the following: 802-11-wireless.cloned-mac-address: permanent. So I am on a hardware MAC address
It looks like you did mentioned that, but forgot about it when I replied. Oops.
Do you see the IP address changing when you see the dhcp4 log entry? The log entries would mean that either the wireless controller lost a connection and had to re-associate, thus requesting a new DHCP lease unless if the DHCP lease is set to an extremely short duration.
The ip address seemed to be the same as it was before, it is just renewing the lease rather than switching to a new ip.
Here is a more verbose printout of journalctl around the time of the ping spike.
Oct 29 14:08:36 framework NetworkManager[1420]: <info> [1730232516.0252] dhcp4 (wlp170s0): state changed new lease, address=172.28.21.4
Oct 29 14:08:36 framework systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Oct 29 14:08:36 framework systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Oct 29 14:08:36 framework 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'
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-STARTED EAP authentication started
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=BE/O=GlobalSign nv-sa/CN=GlobalSign RSA OV SSL CA 2018' hash=b676ffa3179e8812093a1b5eafee876ae7a6aaf231078dad1bfb21cd2893764a
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=CA/ST=Alberta/L=Edmonton/O=University of Alberta/CN=wirelessauth.ualberta.ca' hash=a296a85036513802a78431e8e1d2dafd0c58d98d1f9bc93064ab6a8a2edad614
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:wirelessauth.ualberta.ca
Oct 29 14:08:37 framework wpa_supplicant[1614]: EAP-MSCHAPV2: Authentication succeeded
Oct 29 14:08:37 framework wpa_supplicant[1614]: EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-REMOVED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:08:37 framework wpa_supplicant[1614]: wlp170s0: WPA: Key negotiation completed with [redacted] [PTK=CCMP GTK=CCMP]
Oct 29 14:08:46 framework systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Oct 29 14:08:46 framework 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'
Oct 29 14:10:05 framework systemd[2418]: app-libreoffice\x2dcalc@86a05dba7d214d72846512f12f4d14bf.service: Consumed 4.902s CPU time, 341.7M memory peak.
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:12 framework wpa_supplicant[1614]: wlp170s0: PMKSA-CACHE-ADDED [redacted] 0
Oct 29 14:10:27 framework NetworkManager[1420]: <info> [1730232627.9177] audit: op="statistics" interface="wlp170s0" ifindex=2 args="2000" pid=2951 uid=1000 result="success"
Oct 29 14:10:29 framework plasmashell[2951]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
Oct 29 14:10:29 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:10:29 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:12:17 framework NetworkManager[1420]: <info> [1730232737.4657] audit: op="statistics" interface="wlp170s0" ifindex=2 args="2000" pid=2951 uid=1000 result="success"
Oct 29 14:12:18 framework plasmashell[2951]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
Oct 29 14:12:18 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:12:18 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:12:51 framework NetworkManager[1420]: <info> [1730232771.4877] audit: op="statistics" interface="wlp170s0" ifindex=2 args="2000" pid=2951 uid=1000 result="success"
Oct 29 14:12:58 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:12:58 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:12:59 framework NetworkManager[1420]: <info> [1730232779.4018] audit: op="statistics" interface="wlp170s0" ifindex=2 args="2000" pid=2951 uid=1000 result="success"
Oct 29 14:13:00 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:13:00 framework plasmashell[2951]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:53:29: QML ScrollBar: Binding loop detected for property "visible"
Oct 29 14:13:19 framework NetworkManager[1420]: <info> [1730232799.6579] audit: op="statistics" interface="wlp170s0" ifindex=2 args="2000" pid=2951 uid=1000 result="success"
The disconnected at 14:10 is when I believe I noticed the issue and reset the connection (disconnect and reconnect to the network). I was using a VPN at the time, but the issue shows up both when using a VPN and without. I was ssh’d into another computer on the school campus, and had the opportunity to compare ping values for 8.8.8.8. The other computer was getting the regular 40ms, mine was around 16000ms.
Since they’ve been applying hotfixes for that series of WiFi cards recently, I’d experiment with a few different kernel versions and see if some work better than others. I’d also look for module parameters that could alter the functionality in some way that works better in your environment (e.g. forcing 5G or disabling power management).