There is a newer rtl8192eu driver available, based on a newer proprietary driver than our current one It is supposed to support kernels up to 5.12.
See https://github.com/clnhub/rtl8192eu-linux for details.
If applicable, I think we should use it in Mageia 9, rather than our current driver.
Mageia 9Source RPM:
https://github.com/Mange/rtl8192eu-linux-driver is actually using a newer version (5.6.4) and was also patched for 5.12 (https://github.com/Mange/rtl8192eu-linux-driver/pull/233) and dkms-rtl8192eu was already updated in Cauldron after that was committed
(In reply to Pascal Terjan from comment #2)
> https://github.com/Mange/rtl8192eu-linux-driver is actually using a newer
> version (5.6.4) and was also patched for 5.12
> (https://github.com/Mange/rtl8192eu-linux-driver/pull/233) and
> dkms-rtl8192eu was already updated in Cauldron after that was committed
Thank you for that information. But...
Changing this bug to Mageia 8 in light of Bug 28889, backporting the 5.12 series kernel to Mageia 8.
I have tested the first offering from that bug, and our current Mageia 8 dkms-rtl8192eu does not build successfully. I believe the Mageia 8 version of that driver should be updated to the same one as in Cauldron, assuming, of course, that it also works with the 5.10 series kernels currently in use.
I realize that backports do not carry the same guarantee that they will not break a system as ordinary updates do, but it seems to me we should not ignore known problems if there is a viable solution available. In addition, in this case I look at this update as simple insurance against breakage for the time when we may move beyond the 5.10 series kernel in Mageia 8.
We COULD offer this as another backport, but I believe an update makes more sense.
Mageia 9 =>
What is the current status of this driver in MGA8? I need this driver update too and it looks like it is not even in testing yet (neither updates nor backports)...
I've pushed dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 (the same as in cauldron) to mga8 updates_testing
please test it when it's available....
Updated my test system to kernel 5.10.37 and this driver in one operation. This system normally connects via Ethernet cable, so it took a bit of finagling, but once started the driver works Ok with the 5.10 series kernel.
Activated backports, and installed the 5.12.4 kernel and associated packages. After a reboot, the wifi connection came up and is working with no problems. Using it to write this comment.
Looks OK to me.
Confirming the new driver version works with both 5.10.37 & 5.12.4 kernels. Probably it needs a couple of days for more thorough testing on large downloads and uploads before promoting to updates...
I haven't found any problems with this version of driver so far and I think it can be promoted to updates.
(In reply to Thomas Backlund from comment #5)
> I've pushed dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 (the same as in
> cauldron) to mga8 updates_testing
> please test it when it's available....
Did you forgot to assign to QA?
dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 is still in updates_testing and here two persons tested it to be OK
This driver will not work unless the rtl8xxxu module is blacklisted. Currently, the user has to do that manually. There is a lot of confusion about this, and users often believe the driver doesn't work because they miss this step. See bug 28404.
Before we pass this update on, is there some way we could take care of that automatically for the user? It seems to me like an excellent opportunity.
Please add the output of "lspcidrake -v|grep -i network".
$ lsusb | grep Realtek
Bus 003 Device 002: ID 2357:0109 TP-Link TL-WN823N v2/v3 [Realtek RTL8192EU]
$ lspcidrake -v | grep Realtek
r8169 : Realtek Semiconductor Co., Ltd.|RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8168 subv:1458 subd:e000) (rev: 06)
rtl8192eu : Realtek |802.11n NIC (vendor:2357 device:0109)
Created attachment 12927 [details]
udev rule for dkms 8192eu usb wireless adaptor
Please remove or comment out the blacklisting.
Save the attached file as /etc/udev/rules.d/00-dkms-rtl8192eu.rules
Check lsmod to see if the rtl8xxxu module has been removed and the 8192eu
module loaded when the device is plugged in.
If that works, the file should be added to the package in the /usr/lib/udev/rules.d/ directory.
(In reply to Dave Hodgins from comment #14)
> Please remove or comment out the blacklisting.
> Save the attached file as /etc/udev/rules.d/00-dkms-rtl8192eu.rules
> and reboot.
> Check lsmod to see if the rtl8xxxu module has been removed and the 8192eu
> module loaded when the device is plugged in.
Should it work at boot time too? I have this dongle connected permanently as it is connected to my desktop PC without built-in wifi adapter and I need it to connect to my home wifi network and Internet.
I think so.
udev should be able to load module on its own without extra rules for usb and pci devices as long as the driver exposes correct ids...
note that if you add a config file with
you need to recreate the initrd after that so it gets added in early system loading
also, we need to test if this driver also builds with kernel 5.14 series as that is now in kernel and a first build is in backports_testing
I have a 64-bit Plasma system that has not used the rtl8192eu device before. I am trying to simulate an uninformed user trying to install this device. I already have it working on another install on this hardware, so I know it CAN work.
When I plug the device in, it wants to use the rtl8xxxu driver, which only partially works. A modified version of Dave's command gives me this:
$ lspcidrake -v|grep -i Realtek
r8169 : Realtek Semiconductor Co., Ltd.|RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8168 subv:1849 subd:8168) (rev: 03)
rtl8xxxu : Realtek|802.11n NIC (vendor:0bda device:818b)
The first part IDs the Ethernet controller, so the last line is the applicable one. (Note that it is differenet from Oleg's output, even though the two devices are supposed to be using the same chip.)
I have already established that simply installing dkms-rtl8192eu will not work unless I manually blacklist the rtl8xxxu module.
Am I correct in thinking that if I install this rtl8192eu driver from updates_testing, and follow Dave's instructions from Comment 14, that it should then start to work? And that if it does, that would be the best way to automate the process?
(In reply to Thomas Backlund from comment #18)
> note that if you add a config file with
> blacklist rtl8xxxu
> you need to recreate the initrd after that so it gets added in early system
Ah, I had forgotten that step.
> also, we need to test if this driver also builds with kernel 5.14 series as
> that is now in kernel and a first build is in backports_testing
I will see if I can try it out using another install where it is already working with the 5.10 series kernel.
Attempting to install any version of dkms-rtl8192eu on a system that does not already have a kernel-devel package installed brings you right up against Bug 29148.
The driver pulls in the kernel-devel-latest packages from Backports instead of the ones from Core_updates as it is supposed to.
I don't think we can really push this update along, even if it is ready otherwise, until that bug is fixed.
Yes it is irritating, but most users do not have backports configured at all, so will not be affected.
I must disagree, Morgan.
When users first install Mageia, at the step where the online repositories are configured, if they use our GUI tool all of the mirror's hdlists are downloaded. Backports, testing, debug, all are there, even if they have never been activated.
If they installed Mageia at release time, there was nothing in Backports, and if they never activate backports they never update that and they don't run into the bug. But if they install now, or use the gui to switch to a different mirror, new hdlists are downloaded, and now backports are no longer empty. And that means that even if they never did anything with backports, they run into the bug if they install almost anything that involves a "latest" package.
The system from Comment 21 was, until about a month ago, an old Mageia 7 test system. I made a new, clean install of Mageia 8 for testing purposes, clean rather than upgrade because I wanted to clear out all residue of old tests.
Consequently, when I used the MCC tool to set up my mirror, the situation I described occurred. I have never done anything with backports on that system, other than set up the mirror with the gui. Many, if not most of our users are doing just that. They are not using the command line when one of our well-advertised Mageia tools is there.
Keep in mind that mgaapplet and urpmi.update -a will not update the lists for
disabled media, so if the mirror list was set up during install shortly after
Mageia 8 was released, the list of packages available in the backports repos
would be empty.
It's only if the repos are deleted (urpmi.removemedia -a) and re-added now that
the list of packages in the backports repos will be available for urpmi to
consider. Alternatively the disabled media may be updated using "urpmi.update e"
which works because all of or media (Core, Nonfree, and Tainted) contain the
letter e in as least one of the words it the repo's name.
(In reply to Thomas Andrews from comment #20)
> (In reply to Thomas Backlund from comment #18)
> > also, we need to test if this driver also builds with kernel 5.14 series as
> > that is now in kernel and a first build is in backports_testing
> I will see if I can try it out using another install where it is already
> working with the 5.10 series kernel.
Sorry this took so long, but I finally decided to ignore bug 29148, and move on.
This driver/device DOES work with kernel-desktop 5.14.10 which is in core_backports now, as well as the 5.10.70 kernel. It seems to be necessary to boot with the device inserted. Hotplugging the device in a running system will not work.
This system is one that was already working with 5.10 series kernel, by manually blacklisting the rtl8xxxu module. Also, I'm using Network Manager, as it handles multiple devices and connections better for me than our Network Center does.