Abnormally low WiFi speed

z5kb · 2026-02-08 00:27:18

My WiFi speed fluctuates between 20 and 80 mbps (megabits per second; I use fast.com to measure the speed). I had a windows 11 installation ~6 months ago and I used to download games from steam with at least 400 mbps. Also, my phone manages to reach 450-500 mbps when connected to the same network.

I'm using Archer tx20e for WiFi & bluetooth (it has a Realtek RTL8852BE wifi & bluetooth card inside). I'm connecting to a 5G network using NetworkManager with wpa_supplicant. Per a suggestion from someone, I tried switching to NetworkManager with iwd by downloading networkmanager-iwd (as noted in the wiki) but this didn't help. I also tried disabling power saving but this didn't work as well.

Can't really think of anything else. Open to any suggestions.

Last edited by z5kb (2026-02-08 01:24:50)

seth · 2026-02-08 09:12:33

Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

I also tried disabling power saving but this didn't work as well.

How?

systool -vm rtw88_core
systool -vm rtw88_pci

Do you have https://archlinux.org/packages/?name=li … re-realtek ?

z5kb · 2026-02-12 17:20:20

I have linux-firmware-realtek installed.

I disabled the power saving and checked afterwards like this:

[user@archlinux ~]$ iw dev wlan0 get power_save
Power save: on
[user@archlinux ~]$ sudo iw dev wlan0 set power_save off
[user@archlinux ~]$ iw dev wlan0 get power_save
Power save: off

The output of the command you sent:

[user@archlinux ~]$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
apparmor.service                         | multi-user.target.wants
bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.resolve1.service    | system
dbus-org.freedesktop.timesync1.service   | system
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nvidia-hibernate.service                 | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-suspend.service.wants
nvidia-resume.service                    | systemd-suspend-then-hibernate.service.wants
nvidia-suspend.service                   | systemd-suspend.service.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
postgresql.service                       | multi-user.target.wants
remote-fs.target                         | multi-user.target.wants
systemd-resolved.service                 | sysinit.target.wants
systemd-timesyncd.service                | sysinit.target.wants
systemd-userdbd.socket                   | sockets.target.wants
ufw.service                              | multi-user.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs.service                    | graphical-session-pre.target.wants

seth · 2026-02-12 19:59:12

seth wrote:

systool -vm rtw88_core
systool -vm rtw88_pci

The rtw88 modules have power saving options that are notorious for causing problems.

modinfo rtw88_core rtw88_pci # don't post that, it's for you to look at

z5kb · 2026-02-12 21:55:13

Sorry, forgot to send the output of these commands. Keep in mind that I don't have any rtw88 modules, but I do have 5 named "rtw89_..." (see the second code section). I have redacted the attributes since they seem unrelated. Otherwise, seems like the power saving for both kernel modules you noted is enabled.

[user@archlinux ~]$ systool -vm rtw89_core
Module = "rtw89_core"

  Attributes:
    coresize            = ...
    initsize            = ...
    initstate           = ...
    refcnt              = ...
    srcversion          = ...
    taint               = ...
    uevent              = ...

  Parameters:
    debug_mask          = "0"
    disable_ps_mode     = "N"

  Sections:

[user@archlinux ~]$ systool -vm rtw89_pci
Module = "rtw89_pci"

  Attributes:
    coresize            = ...
    initsize            = ...
    initstate           = ...
    refcnt              = ...
    srcversion          = ...
    taint               = ...
    uevent              = ...

  Parameters:
    disable_aspm_l1ss   = "N"
    disable_aspm_l1     = "N"
    disable_clkreq      = "N"

  Sections:

[user@archlinux ~]$

[user@archlinux ~]$ lsmod
Module                  Size  Used by
...
rtw89_8852be           12288  0
rtw89_8852b           352256  1 rtw89_8852be
rtw89_8852b_common     65536  1 rtw89_8852b
rtw89_pci             122880  1 rtw89_8852be
rtw89_core           1191936  3 rtw89_8852b,rtw89_pci,rtw89_8852b_common
mac80211             1683456  2 rtw89_core,rtw89_pci
cfg80211             1429504  3 rtw89_core,mac80211,rtw89_8852b_common
rfkill                 45056  9 rtw89_core,bluetooth,cfg80211
...

Regarding this command:

modinfo rtw88_core rtw88_pci # don't post that, it's for you to look at

Curiously enough, modinfo returns information about these 2 modules even though lsmod does not list them? Nevertheless, I used the command for the 2 rtw88 modules as well as the 2 rtw89 modules. The parameters related to power saving on all 4 state "Set Y to disable...", but as far as I understood the "modinfo" command lists the default configuration for the modules so this doesn't change much (or perhaps I misunderstood the output).

I tried disabling power saving by creating a file named "/usr/lib/modprobe.d/70-rtw89.conf" containing this and rebooting after that:

options rtw89_pci disable_clkreq=y disable_aspm_l1=y disable_aspm_l1ss=y
options rtw89_core disable_ps_mode=y

It seems like power saving is now disabled when I check it with systool, but my internet is still very slow:

...
  Parameters:
    debug_mask          = "0"
    disable_ps_mode     = "Y"
...
  Parameters:
    disable_aspm_l1ss   = "Y"
    disable_aspm_l1     = "Y"
    disable_clkreq      = "Y"
...

Last edited by z5kb (2026-02-12 21:56:03)

seth · 2026-02-12 22:34:25

8852be is handled by rtw89 not, rtw88 - brilliant

Curiously enough, modinfo returns information about these 2 modules even though lsmod does not list them?

That's normal, modinfo checks the binary on disk.

Don't disable clkreq
Please return to NM + wpa_supplicant, run a speedtest then post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

as well as https://wiki.archlinux.org/title/Networ … _interface

20-80 Mbps sounds a bit like 802.11a/g - so HT/VHT aren't working (assuming you're more around 50 Mbps and the browser rendering javascript introduces the fluctuation as artifact)

z5kb · 2026-02-13 00:02:28

I did what you asked and the speed test reached 48 mbps so you are on point when you assume that it's around 50 mbps... and I believe you may have found the cause. From the FreeBSD man page for rtw89:

While rtw89 supports 802.11a/b/g/n/ac/ax modes, the compatibility code currently only supports 802.11a/b/g modes. Support for 802.11n/ac/ax is yet to come.

Which means that, apparently, I am stuck in 2008.

In case I am wrong, here are the logs you requested. I am using NM + wpa_supplicant. Reverted clkreq to enabled and rebooted:

...
  Parameters:
    debug_mask          = "0"
    disable_ps_mode     = "Y"
...
  Parameters:
    disable_aspm_l1ss   = "Y"
    disable_aspm_l1     = "Y"
    disable_clkreq      = "N"
...

Journalctl logs: https://0x0.st/PaOQ.log

Wireless interface status logs:

[user@archlinux ~]$ iw dev wlan0 link
Connected to 60:32:b1:2f:11:46 (on wlan0)
	SSID: <network_ssid>
	freq: 5200.0
	RX: 81881713 bytes (120391 packets)
	TX: 555960836 bytes (365642 packets)
	signal: -60 dBm
	rx bitrate: 117.0 MBit/s VHT-MCS 3 80MHz VHT-NSS 1
	tx bitrate: 175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

P.S. I distinctly remember that I reached a speed of ~84 mbps when I was downloading a game from Steam. This happened at the time of which I opened this post. If rtw89 only supports 802.11a/b/g, I believe this shouldn't be possible as they are limited to 54 mbps (802a specifically as I am on a 5G network). Please let me know if you have any other input. Otherwise I guess I'll mark the post as solved.

seth · 2026-02-13 15:21:56

Which means that, apparently, I am stuck in 2008.

Could be worse… but your wifi is on a 80MHz 5GHz VHT connection - the signal isn't great but serviceable.
Can you get closer to the AP?

You're btw. averaging at 117 Mbps inbound and nothing looks all that wrong in the journal.

Feb 13 01:19:48 archlinux (udev-worker)[1708]: cfg80211: Process '/usr/bin/set-wireless-regdom' failed with exit code 1.
Feb 13 01:19:52 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
Feb 13 01:19:52 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT before freq=5200 max_tx_power=2000 no_ir=1
Feb 13 01:19:52 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT after freq=5200 max_tx_power=2000
Feb 13 01:19:56 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
Feb 13 01:19:56 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT before freq=5240 max_tx_power=2000 no_ir=1
Feb 13 01:19:56 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT after freq=5240 max_tx_power=2000
Feb 13 01:20:12 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Feb 13 01:20:13 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
Feb 13 01:20:13 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT before freq=5200 max_tx_power=2000 no_ir=1
Feb 13 01:20:13 archlinux wpa_supplicant[1985]: wlan0: CTRL-EVENT-REGDOM-BEACON-HINT after freq=5200 max_tx_power=2000

https://wiki.archlinux.org/title/Networ … ory_domain (though there're no signs that you're powering down from there)

Randomly you could try to stop uwf (and clear the netfilter tables) and disable https://wiki.archlinux.org/title/Networ … domization (though this typically would only cause complete connection failure because the AP considers this malicious)

Last edited by seth (2026-02-13 15:22:20)

z5kb · 2026-02-13 19:20:10

I can't get closer to the router, but it won't change much anyways - I used to download games from steam at ~450 mbps from the same spot when I was using windows like 6 months ago.

Apparently I was wrong. In the "iw dev wlan0 link" logs above, the lines starting with "rx bitrate" and "tx bitrate" contain "VHT-MCS". VHT (Very High Throughput) was introduced with 802.11ac, so the computer should be working in 802.11ac mode (or possibly higher but idk). What I read in the documentation yesterday was related purely to FreeBSD. Apparently FreeBSD can't use Linux kernel modules, so they have some compatibility layer which allows them to use them. The compatibility layer itself doesn't support 802.11ac, but the driver does - so it should work fine on arch.

I set the regdomain, no noticable difference in speed. I didn't clear the netfilter tables and didn't disable mac randomization as it seems like a big hassle and I suspect it won't do much (correct me if I'm wrong but it seems like you also think it's a last resort).

==========================================================================================================

I dug deeper into the output of the "iw dev wlan0 link" command and noticed that tx is working on an 80 Mhz channel while rx is using a 40 Mhz channel. I tried forcing my router to use 80Hz for both channels, and it does, but the computer downgrades it to 40 Mhz for most of the time, although it does come back up to 80 Mhz sometimes (should be because of wireless interferences).

I also noticed that the rx & tx bitrate, although they look like random numbers, do not change. I found this table, which clarified things a bit:
- VHT-NSS is the number of spatial streams
- signal is the same as RSSI in the table
- Data Rate is not shown in the logs but seems to be 800ns
- 80Mhz/40Mhz is the current channel frequency
- VHT-MCS is the total index for "network quality" which corresponds to a given fixed bitrate

RX has a VHT-MCS index of 1-2, while TX has a VHT-MCS index of 4-7 and this persists all the time. VHT-MCS index of 6 corresponds to 526.6 mbps on 2 spatial streams and to 263.3 on 1 spatial stream. TX is almost always working at 526.6 mbps or above, while RX not only never goes above VHT-MCS 2, but switches between 2 and 1 spatial streams half the time and also uses a 40 MHz channel most of the time and sometimes even gets downgraded to a 20 MHz channel, which means that it almost never goes above 58.5 mbps. Following are some examples:

	SSID: ssid
	freq: 5180.0
	RX: 76691061 bytes (113621 packets)
	TX: 800694743 bytes (274485 packets)
	signal: -59 dBm
	rx bitrate: 54.0 MBit/s VHT-MCS 1 40MHz VHT-NSS 2
	tx bitrate: 526.6 MBit/s VHT-MCS 6 80MHz VHT-NSS 2
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

	SSID: ssid
	freq: 5200.0
	RX: 291760582 bytes (286898 packets)
	TX: 538546511 bytes (193667 packets)
	signal: -63 dBm
	rx bitrate: 54.0 MBit/s VHT-MCS 1 40MHz VHT-NSS 2
	tx bitrate: 585.0 MBit/s VHT-MCS 7 80MHz VHT-NSS 2
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 10

	SSID: ssid
	freq: 5220.0
	RX: 65142995 bytes (115843 packets)
	TX: 782963126 bytes (265871 packets)
	signal: -62 dBm
	rx bitrate: 54.0 MBit/s VHT-MCS 1 40MHz VHT-NSS 2
	tx bitrate: 526.6 MBit/s VHT-MCS 6 80MHz VHT-NSS 2
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

	SSID: ssid
	freq: 5240.0
	RX: 44347229 bytes (33954 packets)
	TX: 50702988 bytes (35718 packets)
	signal: -65 dBm
	rx bitrate: 40.5 MBit/s VHT-MCS 2 40MHz VHT-NSS 1
	tx bitrate: 175.6 MBit/s VHT-MCS 2 80MHz VHT-NSS 2
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

	SSID: ssid
	freq: 5240.0
	RX: 44935726 bytes (39487 packets)
	TX: 155479951 bytes (95796 packets)
	signal: -63 dBm
	rx bitrate: 54.0 MBit/s VHT-MCS 1 40MHz VHT-NSS 2
	tx bitrate: 526.6 MBit/s VHT-MCS 6 80MHz VHT-NSS 2
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

	SSID: ssid
	freq: 5240.0
	RX: 7281219 bytes (9063 packets)
	TX: 1855373 bytes (2852 packets)
	signal: -62 dBm
	rx bitrate: 39.0 MBit/s VHT-MCS 4 VHT-NSS 1
	tx bitrate: 390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1
	bss flags: short-slot-time
	dtim period: 1
	beacon int: 100

I see no possible explanation for having a x5-10 difference between RX and TX speeds most of the time, especially considering that it never gave me any problems under windows. The only possible explanation I have is that there is an issue with the driver specifically related to RX. After reading this article, I am considering downgrading to see if that fixes the problem: https://beamtic.com/realtek-bluetooth-wifi-issues-linux

Last edited by z5kb (2026-02-20 13:20:20)

seth · 2026-02-13 21:44:38

The article seems to blame the firmware, specifically rtw8852c_fw-1.bin and rtw8852c_fw-2.bin ?
https://gitlab.com/kernel-firmware/linu … type=heads

z5kb · 2026-02-20 15:11:31

Seems like it does.

I tried disabling all packages by renaming them to "*.old", and then re-enabled rtw8852bt_fw.bin.zst, rtw8852bt_fw-1.bin.zst and rtw8852bt_fw-2.bin.zst one at a time. The first is slower than usual (5-10 mbps on fast.com), the second is 25-30 mbps on fast.com (seems like this is the one being used usually), and the third one doesn't work. I also tried using only rtw8852bt_fw.bin.zst since the name is kind of similar to the ones which seemed to be used usually, but it doesn't work so I guess it's not made for my hardware.
The folder with the files:

[user@archlinux rtw89]$ pwd
/lib/firmware/rtw89
[user@archlinux rtw89]$ ls
rtw8851b_fw.bin.zst.old     rtw8852c_fw-2.bin.zst.old
rtw8852a_fw.bin.zst.old     rtw8852c_fw.bin.zst.old
rtw8852b_fw-1.bin.zst       rtw8922a_fw-1.bin.zst.old
rtw8852b_fw-2.bin.zst.old   rtw8922a_fw-2.bin.zst.old
rtw8852b_fw.bin.zst.old     rtw8922a_fw-3.bin.zst.old
rtw8852bt_fw-1.bin.zst.old  rtw8922a_fw-4.bin.zst.old
rtw8852bt_fw.bin.zst.old    rtw8922a_fw.bin.zst.old
rtw8852c_fw-1.bin.zst.old

As a last resort, I guess I can open a ticket in the rtw89 repo and, if this still doesn't help, I'll probably try contacting the linux-firmware maintainers from Realtek.

Let me know if you can think of anything else.

seth · 2026-02-20 16:30:57

Not really - does either of them yield a reproducibly stronger or weaker signal?
Does the AP offer a second stack, ie. can you connect to a 2.4GHz AP?

z5kb · 2026-02-20 17:00:08

with "rtw8852b_fw-1.bin.zst":
5G network (-60 dBm): 16 mbps, 23 mbps, 25 mbps, 16 mbps, 27 mbps
2G network (-58 dBm): 3 mbps, 11 mbps, 14 mbps, 8 mbps, 16 mbps

with "rtw8852b_fw.bin.zst":
5G network (-63 dBm): 11 mbps, 12 mbps, 15 mbps, 14 mbps, 18 mbps
2G network (-60 dBm): 56 mbps, 42 mbps, 62 mbps, 59 mbps, 59 mbps

seth · 2026-02-20 17:31:18

So 5GHz gets better, 2.4GHz worse w/ the fw update despite the latter having a (slightly) stronger signal.
My immediate concern would be why the signal is similarly strong/weak on both bands…

I can't get closer to the router, but

Why not? How far are you roughly away and what is inbetween?
Do you have a signal reading from your phone (in doubt, how many bars do you get on the indicator, but dBm would oc be better)

z5kb · Yesterday 02:20:37

I am less than 5 meters away and I have 1 brick wall between me and the router. I am also maybe half a meter below it. I suppose the signal is similarly strong because I am very close to the router. Perhaps a single brick wall doesn't influence the signal strength that much. I also have a window right next to me and a window around 30 cm below the router... perhaps my devices could be catching the waves from the window instead of through the wall? No idea.

Results from my android phone using WiFiAnalyzer for the signal strength and fast.com for the internet speed:
5G (-61 dBm): 430 mbps, 460 mbps, 450 mbps, 430 mbps, 440 mbps
2G (-59 dBm): 110 mbps, 110 mbps, 110 mbps, 110 mbps, 110 mbps

seth · Yesterday 09:00:36

'key the signal has similar quallity on the phone but yields much better throughput, so it's not the mediocre signal per se (at 5m you'd expect a stronger signal - maybe some lead-paint )

I'll point out that the link statistics outperform your fast.com results by a magnitude.
Get ABBS for a simple console speedtest using wget and some linode hosts.
You're not using a VPN or so? Can you run a local iperf test?
https://wiki.archlinux.org/title/Benchmarking#iperf (you need to iperf instances in the LAN)

z5kb · Yesterday 18:24:55

Thankfully lead paint couldn't be the issue

The link results, as far as I understand, are the theoretical maximum "receive" (rx) and "transmit" (tx) speeds depending on the current network configuration, which is calculated with the data frequency, signal strength, channel frequency and number of spatial streams (see this table I mentioned earlier). So yes, while the actual download speed with fast.com is below the theoretical maximum RX bitrate of (usually) 54 mbps, I think we should instead ask why there is an RX maximum of 54 mbps in the first place - after all, the TX maximum is approximately 10 times higher most of the time.

I am not using a VPN during testing. Following are the results from the ABBS script. I do have to note, though, that the results seem wrong - in the first test, for instance, if 100MB get download in 121 seconds, the speed should be 0.83MB/s, not 5.25 MB/s.

[user@archlinux ~]$ ./abbs net speed

1) Newark, USA			     4) Frankfurt, Deutschland		 7) Sidney, Australia		    10) मुंबई (Bombay), Bhārat (India)
2) Singapore			     5) Dallas, USA			 8) Atlanta, USA		    11) Fremont, USA
3) London, UK			     6) Toronto, Canada			 9) 東京都 (Tokyo), 日本国 (Japan)

Enter location: 4

1) 100MB
2) 1GB

Select size: 1

/dev/null                                  100%[======================================================================================>] 100.00M  5.25MB/s    in 2m 1s
2026-02-21 19:47:48 URL:http://speedtest.frankfurt.linode.com/100MB-frankfurt.bin [104857600/104857600] -> "/dev/null" [1]
[user@archlinux ~]$ ./abbs net speed

1) Newark, USA			     4) Frankfurt, Deutschland		 7) Sidney, Australia		    10) मुंबई (Bombay), Bhārat (India)
2) Singapore			     5) Dallas, USA			 8) Atlanta, USA		    11) Fremont, USA
3) London, UK			     6) Toronto, Canada			 9) 東京都 (Tokyo), 日本国 (Japan)

Enter location: 3

1) 100MB
2) 1GB

Select size: 1

/dev/null                                  100%[======================================================================================>] 100.00M  6.85MB/s    in 88s
2026-02-21 19:50:24 URL:http://speedtest.london.linode.com/100MB-london.bin [104857600/104857600] -> "/dev/null" [1]

I didn't quite understand what you meant with "you need to iperf instances in the LAN", so I tried running iperf with my router set as the server but iperf timed out when trying to connect to the router.

[user@archlinux ~]$ iperf -c 192.168.0.1 -e -i 1
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001 with pid 43107 (1/0 flows/load)
Write buffer size: 131072 Byte
TCP congestion control using cubic
TOS defaults to 0x0 (dscp=0,ecn=0) (Nagle on)
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  1] tcp connect to 192.168.0.1 port 5001 failed (Connection timed out) on <timestamp>
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001 with pid 43107 (1/0 flows/load)
Write buffer size: 131072 Byte
TCP congestion control using cubic
TOS defaults to 0x0 (dscp=0,ecn=0) (Nagle on)
TCP window size: 16.0 KByte (default)
------------------------------------------------------------

seth · Yesterday 22:10:13

if 100MB get download in 121 seconds, the speed should be 0.83MB/s, not 5.25 MB/s.

That's just wget - is the progression linear or does it create little stalls or a huge stall before the download actually starts?
When looking at a wall clock, does it take 120s or 20s?

wget -O /dev/null 'http://speedtest.london.linode.com/100MB-london.bin' 2>/tmp/wget.log

will write a detailed log…

Obviously even 5.25MB/s would be a meager 42 Mbps.

You need to run iperf on two systems in the LAN, one as server and one as client.

cantabile · Yesterday 23:03:20

Do try the Github version of rtw89. It has newer code than the kernel. Maybe the problem was fixed already. If it doesn't help, report the problem to the linux-wireless mailing list. The RTL8852BE is still supported.

You could also try the other official driver (from a random Github repository): https://github.com/KunYi/RTL8852BE

It probably doesn't compile with kernel 6.18, but maybe it does with 6.12 (the linux-lts package). If this driver works better, then fixing rtw89 could be easier.

Arch Linux

#1 2026-02-08 00:27:18

Abnormally low WiFi speed

#2 2026-02-08 09:12:33

Re: Abnormally low WiFi speed

#3 2026-02-12 17:20:20

Re: Abnormally low WiFi speed

#4 2026-02-12 19:59:12

Re: Abnormally low WiFi speed

#5 2026-02-12 21:55:13

Re: Abnormally low WiFi speed

#6 2026-02-12 22:34:25

Re: Abnormally low WiFi speed

#7 2026-02-13 00:02:28

Re: Abnormally low WiFi speed

#8 2026-02-13 15:21:56

Re: Abnormally low WiFi speed

#9 2026-02-13 19:20:10

Re: Abnormally low WiFi speed

#10 2026-02-13 21:44:38

Re: Abnormally low WiFi speed

#11 2026-02-20 15:11:31

Re: Abnormally low WiFi speed

#12 2026-02-20 16:30:57

Re: Abnormally low WiFi speed

#13 2026-02-20 17:00:08

Re: Abnormally low WiFi speed

#14 2026-02-20 17:31:18

Re: Abnormally low WiFi speed

#15 Yesterday 02:20:37

Re: Abnormally low WiFi speed

#16 Yesterday 09:00:36

Re: Abnormally low WiFi speed

#17 Yesterday 18:24:55

Re: Abnormally low WiFi speed

#18 Yesterday 22:10:13

Re: Abnormally low WiFi speed

#19 Yesterday 23:03:20

Re: Abnormally low WiFi speed

Board footer