Created attachment 287333 [details] uname -a Greetings, I have briefly mentioned this problem on another thread here (relating to another problem): https://bugzilla.kernel.org/show_bug.cgi?id=205107#c9 Part of the information is there. On August, 2019, I installed Lubuntu as my main OS. The kernel version was the one which came with the default LTS version (I don't know the version number at this point). The problem I'm describing here would also occur with Linux Mint (installed on the hard-drive), but I am no longer able to test it now. My computer is a Toshiba Satellite laptop (I don't know the model name either) and it came with an RTL8188ee wifi adapter, which has been giving me problems for the longest time. The Wifi is constantly dropping (about every 2 minutes) and the speed is horrendous. Even if I try using wget to download simple lightweight files from the Internet (as Firefox just quits downloading right away), it rarely goes beyond 100 KB/s, at times as low as 10 KB/s. This problem seems to get worse if I try connecting to multiple addresses at once. Typically, it hangs for a long time and then the connection just drops. I must say, however, that, on rare days, it works not too badly. All my devices work well with my connection. As I mentioned on that thread, when this computer ran on Windows 10, this problem was not present (or at least not on this scale). The driver was also made by Realtek, if I remember correctly. Strangely, I have noticed that when I'm connecting to the Internet at the same time with other devices (namely a smartphone), the Wifi tends to work better. The speed is probably just as bad, but the connection is dropped less frequently. I thought it could possibly be related to powersaving, but I have tried disabling that in multiple ways to visible changes. Additionally, if I don't set IPv6 as "Automatic (DHCP-only)" in the Network Manager (I'm not too knowledgeable about networking), it doesn't even try loading anything, so I have it set this way since then. I have also tried multiple combinations in its configurations, but nothing works well. However, if I delete the connection and recreate/reconnect (incl. re-inputting the password), it seems to work well for a while (if I set IPv6 as previously shown). Something similar happens if I turn off Wifi + Networking, and turn them back on after some seconds. I also tried updating the kernel with success. As mentioned on the previous thread, I left the phone next to the computer (but not connected together) connecting to the Internet as the kernel was being updated and only this way was it able to update (also after a long time). As shown by "uname -a" (attachments), I'm currently running Linux 5.0.0-36-generic with the same problems still present. The attachments show my attempts at fetching all kinds of information I could find relating to the driver. Just to show how slow it can get, loading a page of bugzilla right now takes an average of >30 seconds to load (with NoScript enabled, which disables Javascript from being run). I await your reply, Hélder
Created attachment 287335 [details] module params for f in /sys/module/rtl8188ee/parameters/*; do echo $f; cat $f; done
Created attachment 287337 [details] modinfo >> modinfo rtl8188ee
Created attachment 287339 [details] lspci -k >> lspci -k
Created attachment 287341 [details] lshw network >> lshw -class network
Created attachment 287343 [details] dmesg 0 >> dmesg | grep rtlwifi
Created attachment 287345 [details] dmesg 1 >> dmesg | grep wlp
Created attachment 287347 [details] dmesg 2 >> dmesg | grep -i firm
I have the same issue with my HP 15-ba018wm. It has an RTL8818EE. Every time the kernel updates, I need to assure that I have a copy of this code: https://github.com/lwfinger/rtlwifi_new When I follow the instructions provided then my WiFi works fine. Maintainers, please incorporate the code into the mainstream kernel. Thank you!
I have the same problem with the wifi card rtl8188ee and 5.4.0-56-generic kernel. Upload is dropping to 100KiB/s (instead of 5 Mb/s with other devices), Download is 500KiB/s (instead of 5 Mb/s). At all connection is slow and unstable. Couldn't find a fix as the repo https://github.com/lwfinger/rtlwifi_new is down. Suggestions to fix this annoying problem?
> Maintainers, please incorporate the code into the mainstream kernel. I believe the code was integrated [1]. > If you are looking for a driver for chips such as RTL8188EE, RTL8192CE, > RTL8192CU, RTL8192DE, RTL8192EE, RTL8192SE, RTL8723AE, RTL8723BE, or > RTL8821AE, these should be provided by your kernel. If not, then you should > go to the Backports Project > (https://backports.wiki.kernel.org/index.php/Main_Page) to obtain the > necessary code. So please test the latest Linux kernel version, currently 6.0.7 and 6.1-rc4, and report back. If the problem persists, please send an email to the contacts for rtlwifi listed in the file `MAINTAINERS`. [1]: https://github.com/lwfinger/rtw88
I've tested with 6.0.10, and can confirm this is still an issue, at least on RTL8821AE. The network disconnects and asks me for the wifi password over and over, no matter what secret service I use (kdewallet, gnome-keyring, all the same). I'm not sure if I should be using a driver from backports for this.
Created attachment 303362 [details] Snippet of systemd journal from when the disconnect occurs After digging around a little, I isolated the exact logs from when this happens on rtl8821ae. It appears that the supplicant service disconnects from the network because it is unable to re-authenticate when the band changes. I will also e-mail the maintainer about this.
Can confirm this is still a problem. RTL8723BE (same family) Linux dora 6.2.8-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:11:02 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Mar 30 22:12:03 dora kernel: wlp7s0: deauthenticated from 74:4d:28:4b:b6:eb (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA) Mar 30 22:12:03 dora wpa_supplicant[922]: wlp7s0: CTRL-EVENT-DISCONNECTED bssid=74:4d:28:4b:b6:eb reason=6 Mar 30 22:26:58 dora wpa_supplicant[922]: wlp7s0: WPA: Group rekeying completed with 74:4d:28:4b:26:ee [GTK=CCMP] Mar 30 22:31:58 dora wpa_supplicant[922]: wlp7s0: WPA: Group rekeying completed with 74:4d:28:4b:26:ee [GTK=CCMP] it's incredibly frustrating, you can't simply change the WiFI card in this old laptop lenovo hardware locks them so you can only put their part number in it.
Please always attach your full log (`dmesg`), and also list what driver is used. It looks like the Linux kernel bug tracker is not used by the subsystem maintainers, so I recommend to contact the maintainer and list, listed in `MAINTAINERS` [1]. @Josh, what old Lenovo laptop is that? Maybe you can use coreboot, or patch the vendor firmware. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS
The plan was to include dmesg but it wouldn't format right (need markdown or something). I'll look up the maintainer. however this is a bug that has existed sine 2017 even now there are several bugs in this bug tracker about it.. not to mention every linux distro tracker i've checked.. it's either an elusiive issue that only hapens on some dies or defective dies. I've noticed that, it starts happening when a bluetooth device is connected to, if i leave bluetooth off its fine.. but once i connect to a bt speaker etc. it starts happening at the very least much much more frequentatly after that only way to fix it is modprobe -r and reload it will work better until i connect to another BT device.. sad thing is it has horrible speakers so a BT speaker is almost a requirement.. Anyway, it's a Lenovo B50-45 it's an older APU machine, and i don't know if coreboot is supported as for patching the firmware, i've read about it it seems to require a jtag/clip and directly writing to the EPROM.. If i'm being honest, the potato isn't worth that much to me, soon as i can aquire a replacement it will get thrown in my server room as a small webserver or something
Thank you for the update. (I would have filed a separate issue, if using Bluetooth causes the issue.) Please do not paste the Linux messages into the comment, but attach it as a text file. If the maintainers do not use the bug tracker, then they won’t know about the problem. So, contacting the mailing list is best. Fingers crossed, that they have the resources to look into it.
The issues resolve for me when I prevent the firmware from being loaded, either by deleting it or moving it.