So there’s this annoyance happening in my Lenovo Ideapad since April. The problem in question is: every time I’m in a video call, and it doesn’t matter which program (Discord, TeamSpeak, Google Meet, Whatsapp Web) my rx will oscillate between 0 and 52 bits/s; it may take a few minutes, it may take some hours. And it’s specific to video calls (not even in Discord when in a solely audio call this happened). It’s never happened in an online match, downloading some torrent, browsing the web, it’s always in a video call. I’ve tried some things that I looked in Linux forums:
Deactivated the power saving measures from my wifi (`power_aspm=off)`;
Switched from wpa_supplicant to iwd;
Disabled in /etc/iwd/main.conf the “roam-scan” (and it still shows roam-scan in the journalctl).
I also tried the following:
Turning off my camera and letting the other person in the call with it activated (which defeats the whole purpose of our video calls) also doesn’t work;
Lowering the resolution of my webcam output.
None of the above have worked.
Weirdly enough, I haven’t seen any log indicating any kind of failure (checked dmesg, journalctl, systemctl, tcpdump, …). Even stranger is the fact that when this connection drop happens, my “Device rx” oscillates between 0 and 52 b/s for exactly one minute before connection is reestablished. The thing is: the wifi signal stays strong (between -40 and -50 dBm the whole time this happens) and the terminal running “ping -D 1.1.1.1” never shows that a packet has been lost. I’m writing this because I’ve already tried everything I can to test or tweak my laptop to stop this from happening. I doubt it’s because of my ISP because this only happens in my laptop and only during video calls. Not only that, this only happens in video calls in my laptop, because when I’m working and using my company’s laptop, this never happens, which maybe suggests that it’s something related to my wifi board (RTL8852BE)?
I’ve seen this happen in Fedora 44 (Gnome 50) and kernel 7.1.13-200.fc44.x86_64, seeing it right now in Fedora 43 (Gnome 49; thought this could be some weird package in Fedora 44) and kernel 6.17.1-300.fc43.x86_64 and haven’t seen it happen even once while using Linux Mint LMDE 7 with kernel 6.12 (which is why I’m using LMDE, because I thought it was a kernel problem but I also wanted to keep using Fedora).
What else can I test and what kind of information/logs can I paste here to try to solve this?
Hey, first of all, thanks for commenting. Sorry for the late response, but I just tested what you suggested:
ping -D 1.1.1.1: 21:33:25 is the moment the video call dropped, and 21:34:05 is when it reconnected:
[2026-09-14 21:33:24.854692] 64 bytes de 1.1.1.1: icmp_seq=320 ttl=57 tempo=10.5 ms
[2026-09-14 21:33:25.948244] 64 bytes de 1.1.1.1: icmp_seq=321 ttl=57 tempo=103 ms
[2026-09-14 21:33:26.904953] 64 bytes de 1.1.1.1: icmp_seq=322 ttl=57 tempo=58.8 ms
[2026-09-14 21:33:27.856644] 64 bytes de 1.1.1.1: icmp_seq=323 ttl=57 tempo=8.74 ms
[2026-09-14 21:33:28.861116] 64 bytes de 1.1.1.1: icmp_seq=324 ttl=57 tempo=12.0 ms
[2026-09-14 21:33:29.866928] 64 bytes de 1.1.1.1: icmp_seq=325 ttl=57 tempo=16.7 ms
[2026-09-14 21:33:30.863759] 64 bytes de 1.1.1.1: icmp_seq=326 ttl=57 tempo=11.6 ms
[2026-09-14 21:33:31.864764] 64 bytes de 1.1.1.1: icmp_seq=327 ttl=57 tempo=10.8 ms
[2026-09-14 21:33:32.870970] 64 bytes de 1.1.1.1: icmp_seq=328 ttl=57 tempo=15.0 ms
[2026-09-14 21:33:33.868270] 64 bytes de 1.1.1.1: icmp_seq=329 ttl=57 tempo=11.2 ms
[2026-09-14 21:33:34.867144] 64 bytes de 1.1.1.1: icmp_seq=330 ttl=57 tempo=9.09 ms
[2026-09-14 21:33:35.870006] 64 bytes de 1.1.1.1: icmp_seq=331 ttl=57 tempo=10.8 ms
[2026-09-14 21:33:36.868960] 64 bytes de 1.1.1.1: icmp_seq=332 ttl=57 tempo=8.75 ms
[2026-09-14 21:33:37.871732] 64 bytes de 1.1.1.1: icmp_seq=333 ttl=57 tempo=9.62 ms
[2026-09-14 21:33:38.872977] 64 bytes de 1.1.1.1: icmp_seq=334 ttl=57 tempo=9.07 ms
[2026-09-14 21:33:39.875150] 64 bytes de 1.1.1.1: icmp_seq=335 ttl=57 tempo=9.95 ms
[2026-09-14 21:33:40.874639] 64 bytes de 1.1.1.1: icmp_seq=336 ttl=57 tempo=8.62 ms
[2026-09-14 21:33:41.875860] 64 bytes de 1.1.1.1: icmp_seq=337 ttl=57 tempo=8.73 ms
[2026-09-14 21:33:42.879757] 64 bytes de 1.1.1.1: icmp_seq=338 ttl=57 tempo=11.6 ms
[2026-09-14 21:33:43.878275] 64 bytes de 1.1.1.1: icmp_seq=339 ttl=57 tempo=9.14 ms
[2026-09-14 21:33:44.879982] 64 bytes de 1.1.1.1: icmp_seq=340 ttl=57 tempo=9.80 ms
[2026-09-14 21:33:45.881617] 64 bytes de 1.1.1.1: icmp_seq=341 ttl=57 tempo=10.4 ms
[2026-09-14 21:33:46.881545] 64 bytes de 1.1.1.1: icmp_seq=342 ttl=57 tempo=9.42 ms
[2026-09-14 21:33:47.882278] 64 bytes de 1.1.1.1: icmp_seq=343 ttl=57 tempo=9.25 ms
[2026-09-14 21:33:48.888220] 64 bytes de 1.1.1.1: icmp_seq=344 ttl=57 tempo=13.7 ms
[2026-09-14 21:33:49.887959] 64 bytes de 1.1.1.1: icmp_seq=345 ttl=57 tempo=11.5 ms
[2026-09-14 21:33:50.887529] 64 bytes de 1.1.1.1: icmp_seq=346 ttl=57 tempo=9.40 ms
[2026-09-14 21:33:51.892314] 64 bytes de 1.1.1.1: icmp_seq=347 ttl=57 tempo=13.2 ms
[2026-09-14 21:33:52.890722] 64 bytes de 1.1.1.1: icmp_seq=348 ttl=57 tempo=10.2 ms
[2026-09-14 21:33:53.891238] 64 bytes de 1.1.1.1: icmp_seq=349 ttl=57 tempo=8.93 ms
[2026-09-14 21:33:54.893140] 64 bytes de 1.1.1.1: icmp_seq=350 ttl=57 tempo=9.59 ms
[2026-09-14 21:33:55.894452] 64 bytes de 1.1.1.1: icmp_seq=351 ttl=57 tempo=9.13 ms
[2026-09-14 21:33:56.894773] 64 bytes de 1.1.1.1: icmp_seq=352 ttl=57 tempo=8.65 ms
[2026-09-14 21:33:57.895977] 64 bytes de 1.1.1.1: icmp_seq=353 ttl=57 tempo=8.81 ms
[2026-09-14 21:33:58.898401] 64 bytes de 1.1.1.1: icmp_seq=354 ttl=57 tempo=9.23 ms
[2026-09-14 21:33:59.901311] 64 bytes de 1.1.1.1: icmp_seq=355 ttl=57 tempo=10.2 ms
[2026-09-14 21:34:00.900809] 64 bytes de 1.1.1.1: icmp_seq=356 ttl=57 tempo=8.76 ms
[2026-09-14 21:34:01.905013] 64 bytes de 1.1.1.1: icmp_seq=357 ttl=57 tempo=11.9 ms
[2026-09-14 21:34:02.904378] 64 bytes de 1.1.1.1: icmp_seq=358 ttl=57 tempo=10.2 ms
[2026-09-14 21:34:03.910505] 64 bytes de 1.1.1.1: icmp_seq=359 ttl=57 tempo=15.4 ms
[2026-09-14 21:34:04.906207] 64 bytes de 1.1.1.1: icmp_seq=360 ttl=57 tempo=9.51 ms
[2026-09-14 21:34:05.906872] 64 bytes de 1.1.1.1: icmp_seq=361 ttl=57 tempo=8.82 ms
[2026-09-14 21:34:06.911444] 64 bytes de 1.1.1.1: icmp_seq=362 ttl=57 tempo=12.4 ms
ping -D 192.168.3.1:
[1789432406.739924] 64 bytes de 192.168.3.1: icmp_seq=738 ttl=64 tempo=101 ms
[1789432407.675147] 64 bytes de 192.168.3.1: icmp_seq=739 ttl=64 tempo=35.1 ms
[1789432408.642130] 64 bytes de 192.168.3.1: icmp_seq=740 ttl=64 tempo=1.52 ms
[1789432409.648501] 64 bytes de 192.168.3.1: icmp_seq=741 ttl=64 tempo=6.19 ms
[1789432410.644585] 64 bytes de 192.168.3.1: icmp_seq=742 ttl=64 tempo=1.49 ms
[1789432411.645533] 64 bytes de 192.168.3.1: icmp_seq=743 ttl=64 tempo=1.45 ms
[1789432412.647707] 64 bytes de 192.168.3.1: icmp_seq=744 ttl=64 tempo=2.00 ms
[1789432413.647995] 64 bytes de 192.168.3.1: icmp_seq=745 ttl=64 tempo=1.09 ms
[1789432414.649509] 64 bytes de 192.168.3.1: icmp_seq=746 ttl=64 tempo=1.38 ms
[1789432415.651701] 64 bytes de 192.168.3.1: icmp_seq=747 ttl=64 tempo=1.97 ms
[1789432416.651179] 64 bytes de 192.168.3.1: icmp_seq=748 ttl=64 tempo=1.03 ms
[1789432417.652106] 64 bytes de 192.168.3.1: icmp_seq=749 ttl=64 tempo=1.46 ms
[1789432418.660734] 64 bytes de 192.168.3.1: icmp_seq=750 ttl=64 tempo=8.42 ms
[1789432419.659001] 64 bytes de 192.168.3.1: icmp_seq=751 ttl=64 tempo=5.87 ms
[1789432420.655749] 64 bytes de 192.168.3.1: icmp_seq=752 ttl=64 tempo=1.90 ms
[1789432421.655348] 64 bytes de 192.168.3.1: icmp_seq=753 ttl=64 tempo=1.21 ms
[1789432422.666444] 64 bytes de 192.168.3.1: icmp_seq=754 ttl=64 tempo=10.9 ms
[1789432423.666037] 64 bytes de 192.168.3.1: icmp_seq=755 ttl=64 tempo=9.37 ms
[1789432424.661708] 64 bytes de 192.168.3.1: icmp_seq=756 ttl=64 tempo=3.44 ms
[1789432425.663289] 64 bytes de 192.168.3.1: icmp_seq=757 ttl=64 tempo=2.77 ms
[1789432426.663606] 64 bytes de 192.168.3.1: icmp_seq=758 ttl=64 tempo=1.48 ms
[1789432427.664978] 64 bytes de 192.168.3.1: icmp_seq=759 ttl=64 tempo=1.18 ms
[1789432428.668277] 64 bytes de 192.168.3.1: icmp_seq=760 ttl=64 tempo=3.00 ms
[1789432429.668802] 64 bytes de 192.168.3.1: icmp_seq=761 ttl=64 tempo=2.11 ms
[1789432430.668334] 64 bytes de 192.168.3.1: icmp_seq=762 ttl=64 tempo=1.21 ms
[1789432431.670463] 64 bytes de 192.168.3.1: icmp_seq=763 ttl=64 tempo=1.91 ms
[1789432432.670448] 64 bytes de 192.168.3.1: icmp_seq=764 ttl=64 tempo=1.32 ms
[1789432433.671773] 64 bytes de 192.168.3.1: icmp_seq=765 ttl=64 tempo=1.12 ms
[1789432434.673545] 64 bytes de 192.168.3.1: icmp_seq=766 ttl=64 tempo=1.52 ms
[1789432435.675549] 64 bytes de 192.168.3.1: icmp_seq=767 ttl=64 tempo=1.79 ms
[1789432436.676700] 64 bytes de 192.168.3.1: icmp_seq=768 ttl=64 tempo=1.55 ms
[1789432437.678146] 64 bytes de 192.168.3.1: icmp_seq=769 ttl=64 tempo=1.23 ms
[1789432438.679413] 64 bytes de 192.168.3.1: icmp_seq=770 ttl=64 tempo=1.06 ms
[1789432439.680206] 64 bytes de 192.168.3.1: icmp_seq=771 ttl=64 tempo=1.10 ms
[1789432440.682322] 64 bytes de 192.168.3.1: icmp_seq=772 ttl=64 tempo=1.96 ms
[1789432441.682184] 64 bytes de 192.168.3.1: icmp_seq=773 ttl=64 tempo=1.07 ms
[1789432442.683633] 64 bytes de 192.168.3.1: icmp_seq=774 ttl=64 tempo=1.54 ms
[1789432443.684850] 64 bytes de 192.168.3.1: icmp_seq=775 ttl=64 tempo=1.06 ms
[1789432444.685157] 64 bytes de 192.168.3.1: icmp_seq=776 ttl=64 tempo=1.02 ms
[1789432445.686306] 64 bytes de 192.168.3.1: icmp_seq=777 ttl=64 tempo=1.17 ms
[1789432446.687322] 64 bytes de 192.168.3.1: icmp_seq=778 ttl=64 tempo=1.23 ms
[1789432447.689860] 64 bytes de 192.168.3.1: icmp_seq=779 ttl=64 tempo=2.25 ms
[1789432448.689190] 64 bytes de 192.168.3.1: icmp_seq=780 ttl=64 tempo=1.10 ms
ethtool -i wlp2s0:
driver: rtw89_8852be
version: 6.17.1-300.fc43.x86_64
firmware-version: N/A
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
Now, I’ve also applied yesterday some things that were related to my problem:
Any more information I can bring? It felt like it worked like a charm yesterday (no drops for some 8 hours), but it happened again today (twice in a short period of time). The same problem doesn’t happen when I’m browsing on my phone while this drop happens in my laptop.
I guess you don’t have the equipment to run a wired connection as a workaround (or at least to confirm that it is a problem with the WiFi driver)? With WiFi, external interference is always a possibility. For example, maybe you always do the video calls from a location that is more distant from your router, or you always close your office door and that weakens the WiFi signal?
Sadly, my laptop doesn’t have an Ethernet port for me to test it. The router is one wall away from, some 2 meters max. From an earlier test I ran, the signal was ranging from -45 to -55 dBm, even during the drop.
I don’t know. Maybe it could be some bug in the TCP window scaling algorithm?[1] There are knobs to play with that sort of thing, but when you start messing with the settings at that level, your odds of improving anything diminish rapidly unless you really know what you are doing.
Edit: Before you go too much into those weeds, you might want to check that hardware accelerated decoding is working in your browser for whatever video encoding you are working with.
iw dev returned Power save: off and head /sys/module/rtw89_pci/parameters/* returned the following:
==> /sys/module/rtw89_pci/parameters/disable_aspm_l1 <==
Y
==> /sys/module/rtw89_pci/parameters/disable_aspm_l1ss <==
Y
==> /sys/module/rtw89_pci/parameters/disable_clkreq <==
Y
Yeah, I think I’ll try this guide as a last resort/hail Mary. I disabled hardware acceleration in TeamSpeak, and the same thing happened again… The strangest part of all this, to me, is how my rx keeps fluctuating between 0 and 52 B/s; I tried looking into whether this could be related some packet size of any type but no luck. As a penultimate resort, I think I’ll salvage a Qualcomm Wi-Fi card from my old laptop (hopefully it won’t be worse than a Realtek card). In the meantime, I’ll keep following the discussion here.
Edit: And thanks for the guide and the other comment, any help here is appreciated!!
Did you mean enabled ? I think you want the hardware acceleration enabled to take the load off your CPU. From that article I linked earlier (emphasis added):
Even if the network and all its switches and routers have ample bandwidth and buffer space packets can still be lost:
The host operating system might be under memory pressure and drop
packets. Remember that a host might be handling tens of thousands of packet streams simultaneously.
The CPU might not be able to drain incoming packets from the network interface fast enough. This causes packet drops in the network adapter itself.
Yes, exactly that; typed the answer while I was sleepy. Anyway, the connection drops, after implementing all the three solutions I mentioned earlier, are sparser now (they didn’t disappear tho). I think I’ll end up buying an Intel AX210 anyway. I salvaged the board from my previous laptop only to find out it’s a RTL8822CE. In the meantime, I’ll keep looking for other discussions mentioning the realtek 8852.
Quick update: this problem is still present in Fedora 45, using the latest kernel (7.2.6-300.fc45.x86_64) and linux-firmware 20260916-1.fc45. d3cold still 0, disable_aspm_l1, disable_aspm_l1ss and disable_clkreq all set to Y. Seeing how this problem has been mentioned since at least 2025, I don’t expect it to be fixed any time soon. The only thing so far that has worked was using Linux Mint LMDE 7 with its 6.12 kernel.
Since you report that the problem doesn’t occur with an older kernel, I’ll add the kernel tag to let the kernel team know that there might be a problem here. Like you said though, if the problem has been around for over a year, the likelihood that anyone is working on fixing it is pretty low.
So. After this whole situation, I decided to undo every change I’ve made. d3cold_allowed was reset to 1, the /etc/default/grub file now only has rhgb quiet[1] and wifi_powersave in the /etc/NetworkManager/conf.d/00-wifi-powersave.conf/was set back to 3; basically, everything back as if it was a “”“clean”“” install…
…except that I forgot that I applied this solution to a /etc/modprobe.d/rtw8852be.conf file. To my surprise, when I checked head /sys/module/rtw89_pci/parameters/* , after deleting the same parameters from GRUB_CMDLINE_LINUX, it was all set to “Y”. And the problem disappeared.
For two consecutive days I haven’t had any connection drop during a video call.
Well, I don’t know if the combination of all the settings above (editing GRUB, setting powersave = 2, dwcold = 0, and the file /etc/modprobe.d/rtw8852be.conf with all the options) didn’t work because of some conflict between them or for some other reason, but now everything is working as it should. So, I’ll mark this as solved, and I want to thank everybody who guided and helped me here.
Now my /etc/modprobe.d/rtw8852be.conf is like this: