My fresh install of Arch was working just fine two days ago. I am using a wireless network for now, and everything seemed to function perfectly. Yesterday I did not use my computer at all. Today, I could barely get a connection: constant timeouts, high latency, and large packet losses.
To be specific, it’s not that the computer did not connect to the internet: I used iwctl to re-connect to my home network, and that worked - for a moment. Both ping 1.1.1.1 and ping archlinux.com were slow to start, often with very high times (some surpassing 7000 ms), and sometimes with over 50% packet loss. At the time, my ThinkPad (also using Arch) had zero trouble navigating the internet, and nor did my phone, so at least I was able to mostly discard router-specific issues.
Aside
Standard Linux disclaimer: This solution may or may not work based on your specific wireless card/motherboard, etc. For context, this is what I am working with:
➤ lspci -k | rg -A3 Network 05:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10) Subsystem: Intel Corporation Device 2110 Kernel driver in use: iwlwifi Kernel modules: iwlwifi
I checked ip a and something like this was the result:
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether <MAC ADDRESS> brd ff:ff:ff:ff:ff:ff
inet <LOCAL IP> metric 600 brd 192.168.1.255 scope global dynamic wlan0
valid_lft 85468sec preferred_lft 85468sec
inet6 <IPV6>/64 scope link proto kernel_ll
valid_lft forever preferred_lft foreverLikewise for rfkill:
ID TYPE DEVICE SOFT HARD
0 bluetooth hci0 unblocked unblocked
1 wlan phy0 unblocked unblockedSo what gives? The next place to check was journalctl -b -p 3 (the flags are -b for current boot session, -p 3 indicate the priority level - “error” in this case).:
kernel: iwlwifi 0000:05:00.0: Queue 11 is active on fifo 3 and stuck for 10000 ms. SW [0, 2]
TRB=0x0c030b001
kernel: iwlwifi 0000:05:00.0: Start IWL Error Log Dump:
kernel: iwlwifi 0000:05:00.0: Transport status: 0x0000004A, valid: 6
kernel: iwlwifi 0000:05:00.0: Loaded firmware version: 29.0bd893f3.0 3168-29.ucode
kernel: iwlwifi 0000:05:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
kernel: iwlwifi 0000:05:00.0: 0x00800634 | trm_hw_status0
kernel: iwlwifi 0000:05:00.0: 0x00000000 | trm_hw_status1
kernel: iwlwifi 0000:05:00.0: 0x00043D6C | branchlink2
kernel: iwlwifi 0000:05:00.0: 0x0004AFA2 | interruptlink1
kernel: iwlwifi 0000:05:00.0: 0x000001E4 | interruptlink2
kernel: iwlwifi 0000:05:00.0: 0x00000000 | data1
kernel: iwlwifi 0000:05:00.0: 0x00000080 | data2
kernel: iwlwifi 0000:05:00.0: 0x07030000 | data3
kernel: iwlwifi 0000:05:00.0: 0x5D409D3C | beacon time
kernel: iwlwifi 0000:05:00.0: 0xDD8412CC | tsf low
kernel: iwlwifi 0000:05:00.0: 0x00000024 | tsf hi
kernel: iwlwifi 0000:05:00.0: 0x00000000 | time gp1
kernel: iwlwifi 0000:05:00.0: 0x02B10A43 | time gp2
kernel: iwlwifi 0000:05:00.0: 0x00000001 | uCode revision type
kernel: iwlwifi 0000:05:00.0: 0x0000001D | uCode version major
kernel: iwlwifi 0000:05:00.0: 0x0BD893F3 | uCode version minor
kernel: iwlwifi 0000:05:00.0: 0x00000220 | hw version
kernel: iwlwifi 0000:05:00.0: 0x00C89200 | board version
kernel: iwlwifi 0000:05:00.0: 0x0B00001C | hcmd
kernel: iwlwifi 0000:05:00.0: 0xA402200A | isr0
kernel: iwlwifi 0000:05:00.0: 0x01800000 | isr1
kernel: iwlwifi 0000:05:00.0: 0x0000000A | isr2
kernel: iwlwifi 0000:05:00.0: 0x0041BCC4 | isr3
kernel: iwlwifi 0000:05:00.0: 0x00000000 | isr4
kernel: iwlwifi 0000:05:00.0: 0x00900118 | last cmd Id
kernel: iwlwifi 0000:05:00.0: 0x00000000 | wait_event
kernel: iwlwifi 0000:05:00.0: 0x00000080 | l2p_control
kernel: iwlwifi 0000:05:00.0: 0x00012030 | l2p_duration
kernel: iwlwifi 0000:05:00.0: 0x0000003F | l2p_mhvalid
kernel: iwlwifi 0000:05:00.0: 0x000000CE | l2p_addr_match
kernel: iwlwifi 0000:05:00.0: 0x00000007 | lmpm_pmg_sel
kernel: iwlwifi 0000:05:00.0: 0x14100601 | timestamp
kernel: iwlwifi 0000:05:00.0: 0x00343840 | flow_handler
kernel: iwlwifi 0000:05:00.0: Fseq Registers:
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_ERROR_CODE
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_TOP_INIT_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_CNVIO_INIT_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_OTP_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_TOP_CONTENT_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_ALIVE_TOKEN
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_CNVI_ID
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_CNVR_ID
kernel: iwlwifi 0000:05:00.0: 0x00000000 | CNVI_AUX_MISC_CHIP
kernel: iwlwifi 0000:05:00.0: 0x00000000 | CNVR_AUX_MISC_CHIP
kernel: iwlwifi 0000:05:00.0: 0x00000000 | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
kernel: iwlwifi 0000:05:00.0: 0x00000000 | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_PREV_CNVIO_INIT_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_WIFI_FSEQ_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_BT_FSEQ_VERSION
kernel: iwlwifi 0000:05:00.0: 0x00000000 | FSEQ_CLASS_TP_VERSION
kernel: iwlwifi 0000:05:00.0: Device error - SW resetThat’s a fair amount of data, but the important parts, as far as I can tell, are the queue system getting stuck or frozen, the actual firmware crashing (thus NMI_INTERRUPT_UNKNOWN) and the requirement for a hard reset (Device error - SW reset).
After searching the archlinux forums for sometime, I came across the following threads:
My first try was to set the following in /etc/modprobe.d/iwlwifi.conf:
options iwlwifi power_save=0 power_level=5 11n_disable=1
options iwlwifi led_mode=1What this means is that power saving on the WiFi card is disabled (don’t need it, since this is a desktop computer plugged in to AC mains), set power level to highest performance, and disable 802.11n (wifi 4) connectivity. After a reboot, this worked! And yet, like most things in Linux, the solution came at a price: as far as I understand, disabling 802.11n connectivity forces the card to rely on 802.11g and, due to this, my networks speeds were about half of what my laptop and my phone would see (at least according to Speedtest.net).
The thing is, if the problem is specifically drivers for 802.11n, can I simply use a different standard? After all, my computer’s motherboard (which has the onboard WiFi card) is maybe from 2022, or there about. It should be compatible with 802.11ac (wifi 5) at least, if not 802.11ax (wifi 6). To double check, I (installed and) ran iw phy (iw is a configuration tool for wireless devices, while the phy argument is short for “physical layer”, used to get my wireless card’s physical radio capabilities).
This command is used to get information such as supported WiFi standards, frequency bands, data rates, encryption, etc. On this occasion I was looking for either VHT (Very High Throughput) or HE (High Efficiency) support; the former refers to 802.11ac, the latter to 802.11ax. A simple iw phy | rg VHT revealed the following (I also used rg HE but it turns out I can’t use 802.11ax):
VHT Capabilities (0x33807120):
VHT RX MCS set:
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
VHT TX highest supported: 0 Mbps
VHT extended NSS: supported
* [ VHT_IBSS ]: VHT-IBSSThis means I am able to use 802.11ac1. It also means I should be able to re-enable 802.11n and find a different way to deal with this. I tried with a simple config:
options iwlwifi power_save=0 power_level=5
options iwlwifi led_mode=1Basically, disable power saving and set the antenna power level as high as it does. This sort of worked, but my connection remained very slow:
What gives? I should be able to use higher speeds, especially if I’m using newer WiFi standards and maximising the power level of my antenna. Also, even if I had 802.11n (or even 802.11g) I should be able to reach the maximum speed of my router - the max theoretical rate of 802.11n is 150 Mbps per stream, and according to a quick internet search, real-world speeds of 100 to 300 Mbps total. That is an order magnitude faster than my measly 2.5 Mbps.
So if the antenna itself isn’t the bottleneck, perhaps it is the amount of devices connecting to the router? What if the environment is too crowded? For this I added another option to the iwlwifi config:
options iwlwifi power_save=0 power_level=5
options iwlwifi led_mode=1
options cfg80211 cfg80211_disable_40mhz_24ghz=YThe cfg80211 line here disables 40 MHz channels on the 2.4 GHz band (forcing the use of 20 MHz channels) but allowing wider channels on 5 GHz frequencies. This immediately improved my speed:
Not incredibly fast, but a definite improvement. Still, I know the connection can be much faster because of what I see on my phone and my laptop - often peaking around 17 Mbps or so. My hunch was that something was still not configured quite right. I looked what frequency was being used to connect, and had a huge “aha!” moment:
➤ iwconfig wlan0 | rg Frequency
Mode:Managed Frequency:2.447 GHzIf the 2.4 GHz environment is already fairly congested (to the point where changing the channel width significantly improved my speed), then why stick to that particular frequency? Why not switch to the faster 5 GHz network, especially since my computer is not particularly far from the access point? To do this, I modified /var/lib/iwd/<SSID>.psk and added a simply section:
[Settings]
Band=5ghzThen I disconnected from the network, reconnected, and voila!:
➤ iwctl station wlan0 disconnect
➤ ping 1.1.1.1
ping: connect: Network is unreachable
➤ iwctl station wlan0 connect "<SSID>"
➤ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=5.35 ms
➤ iwconfig wlan0 | rg Frequency
Mode:Managed Frequency:5.18 GHZSo how do my speeds fare now? Well, more like what I expected:
Hopefully this will continue to work.
Footnotes
-
Although the output shows
VHT TX/RX highest supported: 0 Mbpsit turns out that this is a bit misleading; the Modulation and Coding Scheme, which defines the data rates WiFi can use, is defined elsewhere in the output ofiw phy. The0 Mbpshere simply means that this field isn’t used to indicate max rate and it is delegated to MCS. ↩