rtl8192eu-linux and the out-of-tree driver for Realtek USB WiFi chips

What the repository is, and which chip it is for

This is the Realtek rtl8192eu official Linux driver, at version 5.11.2.3 on the default branch, with the master branch carrying 5.2.19.1 and additional versions 5.6.3.1, 5.6.4 and 5.11.2.1 also present. The language is C, and the repository is not archived with a last push on 2026-10-13.

The README states the relationship with the upstream vendor plainly: the driver is based on the latest official and manufacturer supported Realtek v5.11.2.3 driver with fixes and improvements to support the latest kernels, from 5 up to 7.3.

That last clause is the whole reason the repository exists. Realtek does not ship this driver in the mainline kernel for this chipset, so a user on a recent distribution is left with either a driver that does not build or one that builds but misbehaves. The value here is the patch set on top of the vendor code, not the vendor code itself.

The audience is specific: a Linux user with a USB WiFi adapter built on the RTL8192EU, on a kernel in the 5 to 7.3 range, who is prepared to install an out-of-tree module. The directory layout confirms the shape of a vendor driver, with hal/ for the hardware abstraction layer, os_dep/ for the operating system interface, core/ for the protocol stack, platform/ for the platform glue, and include/ for headers, alongside a dkms.conf and a Kconfig.

There are also two files in the root that are not typical of a driver: runwpa and wlan0dhcp, plus an ifcfg-wlan0. Those are network configuration helpers for connecting the adapter, and their presence tells you the project is aimed at users who need to get a working connection, not just developers porting the module.

The licence is not stated in the repository metadata, and the README does not describe one either. Since the code is Realtek's, that is a gap worth closing with the vendor before anyone puts this into a product.

The Makefile is the configuration surface

Out-of-tree drivers in the Realtek family are configured by editing a Makefile, and this repository's Makefile is where you find out what you are actually building.

The chip selection is a block of CONFIG_ flags under a WIFI IC heading, and the pattern is that everything is set to n except the one you want. In the shown configuration, CONFIG_RTL8192E = y with every other entry disabled: CONFIG_RTL8188E, CONFIG_RTL8812A, CONFIG_RTL8821A, CONFIG_RTL8723B, CONFIG_RTL8814A, CONFIG_RTL8723C, CONFIG_RTL8188F, CONFIG_RTL8188GTV, CONFIG_RTL8822B, CONFIG_RTL8723D, CONFIG_RTL8821C, CONFIG_RTL8710B, CONFIG_RTL8192F, CONFIG_RTL8822C and CONFIG_RTL8814B are all off. There is also CONFIG_MULTIDRV = n, which is the switch that would let one build cover several chips at once.

Below that are the interface and feature blocks. The interface section selects the bus: CONFIG_USB_HCI = y with CONFIG_PCI_HCI, CONFIG_SDIO_HCI and CONFIG_GSPI_HCI off, which is correct for a USB dongle. The feature section turns on CONFIG_AP_MODE, CONFIG_P2P, CONFIG_MP_INCLUDED, CONFIG_POWER_SAVING, CONFIG_BT_COEXIST and CONFIG_EFUSE_CONFIG_FILE, while CONFIG_USB_AUTOSUSPEND, CONFIG_HW_PWRP_DETECTION, CONFIG_WAPI_SUPPORT and CONFIG_EXT_CLK are off.

The compiler flags are worth a note because they explain a class of build failure. The file adds -Wmissing-prototypes and -Werror=missing-prototypes, which turns a missing prototype into a hard error, and it adds a set of -Wno- flags to suppress warnings that the vendor code would otherwise trip. There is also a version check for GCC 4.9 and later that adds -Wno-date-time, with a comment explaining that it fixes a compile error and warning on gcc 4.9 and later.

None of this is configurable through Kconfig in the kernel sense. Kconfig is present in the root, but the practical configuration is the Makefile, and you edit it in place before building.

Installing: the automated path and the manual path

There are two documented ways in, and the automated one is a single script.

First the build prerequisites. The README asks you to have headers, build, dkms and git packages installed, and gives the exact command per distribution. On Debian, Ubuntu and Mint the command is `sudo apt install linux-headers-generic build-essential dkms git`. Fedora installs a development tools group and dkms and git, RHEL and CentOS install the Development Tools group and dkms and git, Arch and Manjaro install base-devel, dkms and git, openSUSE installs the devel_C_C++ pattern plus dkms and git, and for Raspberry Pi the command adds raspberrypi-kernel-headers to the apt list.

With that in place, the automated install is run from the driver directory:

./install_wifi.sh

And the automated uninstall and reset is the mirror image:

./uninstall_wifi.sh

The manual path is spelled out in more detail, and it is worth understanding even if you use the script, because the script does these things for you.

First, remove any competing drivers. The commands are rmmod 8192eu and rmmod rtl8xxxu, and a dkms remove of the module rtl8192eu at version 1.0. The README tells you to skip this step if lshw -C network and dkms status show no WiFi drivers at all.

Then blacklist the in-kernel driver. On Ubuntu the default driver is rtl8xxxu, and the fix is to append the blacklist line to a file and move it into /etc/modprobe.d/:

echo "blacklist rtl8xxxu" >> ./blacklist-rtl8xxxu.conf
sudo mv ./blacklist-rtl8xxxu.conf /etc/modprobe.d/

Then install the module as a DKMS package, copying the source tree to /usr/src/rtl8192eu-1.0 and running dkms add and dkms install with the same module name and version.

Finally, load it with sudo modprobe 8192eu, or reboot.

The DKMS step is the important one for longevity. DKMS, the Dynamic Kernel Module Support framework, rebuilds a module whenever the kernel changes, so the driver survives a kernel upgrade without you doing anything. That is why the module name and version are fixed strings in the commands above: they are the identifiers DKMS tracks.

Non-x86 platforms, monitor mode and Secure Boot

Two configuration details in the README are easy to miss and expensive to get wrong.

The first is the platform. The README says that if you are using a different architecture than x86, you should set CONFIG_PLATFORM_I386_PC = n in the Makefile and also set your architecture, giving the examples CONFIG_PLATFORM_ARM_RPI = y for 32-bit ARM and CONFIG_PLATFORM_ARM_AARCH64 = y for 64-bit ARM. For Raspberry Pi it repeats the instruction to set CONFIG_PLATFORM_I386_PC = n and CONFIG_PLATFORM_ARM_RPI = y in the Makefile.

The reason this is called out is that the shipped Makefile has CONFIG_AUTOCFG_CP = n and the platform flags default to the x86 configuration, so on a Raspberry Pi or an ARM board you get a build that fails or a module that loads and does nothing. The fix is two lines in the Makefile, but only if you know to look.

The second is monitor mode, which is enabled by setting CONFIG_WIFI_MONITOR = y in the Makefile. That is the feature that turns the adapter into something usable for packet capture and network analysis, and it is off by default.

Secure Boot is the third thing, and it is a genuine obstacle on a modern distribution. The README says that if Secure Boot in deployed mode is enabled, you must enroll the public key mentioned during the install process once, which may require installing additional packages like mokutil, keyutils and openssl. The enrollment command is:

sudo mokutil --import [public_key]

After a reboot you can enroll the key. And there is an escape hatch: you can temporarily switch to audit mode in the BIOS and use the driver normally.

The audit mode option is the pragmatic route for a lot of people, since it stops the signature check without permanently weakening the machine, but it does mean the module is running unsigned, which is the trade you are making with Secure Boot in the first place.

Troubleshooting, and what the maintainer needs from you

The Troubleshooting section tells you exactly what to attach to a bug report, and reading it tells you what the failure modes actually are.

If you open an issue because the driver is not working, you should post the kernel version and distribution name and version, the output of the make.log file if it does not compile, the output of lsusb and of lsmod | grep 8192eu if it compiles but does not work, and a limited output of sudo dmesg | grep -i 8192eu.

That list is a good map of the problem space. A build failure is a make.log problem, which points at the toolchain, the headers or the Makefile configuration, and the first two items in the list are the ones to check. A module that compiles and loads but does not work is a different class entirely, and lsusb is there to establish whether the device is even enumerating on the bus, since a device that does not enumerate is a hardware or USB problem rather than a driver problem. dmesg is the last resort, and the README asks for it in brackets, meaning only the matching lines.

The other thing worth noting is what the README does not ask for and does not promise. There is no mention of a working range of USB devices, no list of adapter models known to work, and no statement about which USB 3 chipsets have the well-known dual-device problems that affect this class of hardware. The scope is the rtl8192eu chipset, and the troubleshooting guidance is organised around the kernel and the module rather than around the adapter.

The repository is not archived, but it also has no GitHub releases, so the version history is the branch names. The default branch is 5.11.2.3, master carries 5.2.19.1, and the additional versions sit in their own branches. There is no changelog file, so reading the commit history is the way to see what a given branch contains.

Editorial conclusion

rtl8192eu-linux is a good fit for a Linux user with a USB adapter based on the RTL8192EU whose chipset is not supported by the in-kernel driver, because the patches here cover kernel versions up to 7.3 and the DKMS packaging rebuilds the module on every kernel upgrade. It is a poor fit if your kernel already ships a working rtl8xxxu driver, since the README's own manual procedure begins by removing competing modules and blacklisting rtl8xxxu, and a poor fit if you need Secure Boot to stay in enforcing mode without enrolling a third-party key. Before installing, check which driver is currently bound to your adapter, since the automatic install script path and the manual path both assume this one is the one you want, and read the Makefile platform settings if you are not on x86, because the default configuration targets the i386 platform.

Frequently asked questions

Official sources

1. clnhub/rtl8192eu-linux on GitHub
2. Issues
3. README