# The 8821au driver is obsolete on modern kernels, and the readme says so first > morrownr's out-of-kernel driver for Realtek RTL8811AU and RTL8821AU USB WiFi adapters opens with a notice that the in-kernel rtw88 driver has been of good quality since kernel 6.14, so there is no need to install it on a current system. What remains is the interesting part: a maintained out-of-tree driver with DKMS packaging for older kernels, monitor mode and AP mode support. **morrownr/8821au-20210708** — Linux Driver for USB WiFi Adapters that are based on the RTL8811AU and RTL8821AU Chipsets - v5.12.5.2 - Repository: https://github.com/morrownr/8821au-20210708 - Stars: 1,160 · Forks: 181 - Language: C - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/morrownr-8821au-20210708 ## The first paragraph tells you not to install it The readme opens with a notice, and it is unusual to find one this direct at the top of a driver repository. An updated standards compliant driver, in the mac80211 style and in the kernel, for adapters based on the rtl8821 and rtl8811au chipsets is available, and as of kernel 6.14 it is of good quality. If your distribution uses kernel 6.14 or later, there is no need to install this driver. The in-kernel driver is part of the rtw88 series of drivers, it is Linux Standards compliant, and the notice is blunt that it is a much better driver than this one. It then says what happens to the project: this driver will no longer get API related updates beyond kernel 6.14, unless provided by a user. And for a kernel prior to 6.14, the notice points to another repository, lwfinger/rtw88, where the new standards compliant driver can be used. So the whole first section is a handover plan. The author, who describes maintaining the driver as a pleasure over the last several years, is pointing people at the kernel driver where they can use it and at the backport repository where they cannot, and he notes that if you decide to use the in-kernel driver you should first remove the driver from this repository: ```bash sudo sh remove-driver.sh ``` For an adopter this is genuinely useful information, and it is also unusual. A project that tells you when to stop using it saves you from a support thread six months later. The rest of the readme makes the same point in a different register. Posting this driver is not a recommendation for Linux users to buy USB WiFi adapters based on the Realtek chipsets it supports. Realtek out-of-kernel WiFi drivers are not Linux Wireless Standards compliant and appear to be designed to be used by skilled programmers producing products such as embedded systems, and users of desktop and server distributions will likely find adapters with in-kernel drivers to be more stable and much more trouble-free. ## What the driver actually implements Setting the deprecation aside, the feature list is the reason this driver has survived for years, and it is a long one. The radio is IEEE 802.11 b/g/n/ac compliant, with 802.1x, WPA2 AES for PSK and TLS against a Radius server, and WPA3-SAE for personal networks. In client mode it supports wireless security with WPA2 AES PSK and WPA3-SAE, site survey scanning and manual connection, and a TLS client. Beyond that there is TDLS support, power saving modes, hostapd compatibility, and AP mode with DFS channel support. The interface modes are the interesting part for a security user: managed, monitor, AP, P2P-client and P2P-GO. Monitor mode is the one that turns a WiFi adapter into a packet capture device, and the project links to a separate repository of its own for that. AP mode comes with a separate guide for setting up a bridged wireless access point. The control surface is unusually rich for a driver: log level control, LED control, power saving control, VHT control, which allows 80 MHz channel width in AP mode, and AP mode DFS channel control. Two of those entries are worth a second look, because they are the ones a desktop user notices. LED control is the one that matters when the adapter has a physical status light, and the Makefile shows it is compiled in with a set of configuration flags rather than being a runtime option. And DFS channel control is what you need if you intend to run an access point on a channel that requires a radar check. So the driver is not a minimal client driver. It carries the full set of modes a Linux WiFi driver is expected to have, which is exactly why it is used with packet capture tools, and the repository topics reflect that audience with aircrack-ng and wireshark among them. ## The compatibility matrix, which is the part to read carefully The documentation gives three separate matrices, and each one has a caveat attached. Architectures: x86, i386 and i686, x86-64 and amd64, armv6l and armv7l, and aarch64. The note says additional CPU architectures may work but the author only has the hardware to test the ones listed, which is an honest and typical statement from a maintainer with a shelf of devices rather than a lab. Kernels: 5.4 to 5.11 from Realtek, and 5.12 to 7.2 with community support. Kernels earlier than 5.4 may work but are neither tested nor supported. Compilers: gcc 12, 13, 14 and 15, which is a recent set and a sign the build is being kept current against the compiler warnings that a large out-of-tree driver generates. Distributions: Arch Linux on kernels 5.4, 5.11 and 6.6, Debian on 5.10, 5.15, 6.1 and 6.6, Fedora 38 and 41 on kernel 6.11, Manjaro on 5.15, openSUSE Tumbleweed on 5.15, Raspberry Pi OS dated 2023-12-05 on 32 bit and 64 bit ARM, Raspberry Pi Desktop dated 2022-07-01 on 32 bit x86 with kernel 5.10, Ubuntu 22.04 on 5.15, 22.10 on 5.19 and 6.5, 24.10 on 6.11 and 26.04 on 7.0, and EL10 based systems on the ELRepo kernel-ml at 7.2.2. The readme is clear that this distribution information depends largely on user reports, which can be provided through a pull request or a message in issues. That is the model: the maintainer cannot test every distribution, so the list is a crowd sourced record of what works. The supported devices list names the usual suspects: the ALFA AWUS036ACS, the Buffalo WI-U2-433DHP, three Edimax models in the 7811 series, the ELECOM WDC-433DU2H, the GMYLE AC450, the Netgear A6100, the Netis WF2180, the Planex GW-450S, the EDUP EP-1607 and the TP-Link Archer T2U nano, plus numerous adapters based on the supported chipsets. And there is a file named supported-device-IDs whose stated purpose is to let you confirm that this is the correct driver for your adapter. ## The three platforms the maintainer explicitly does not own Three notes in the readme are about platforms the author supports in principle but does not maintain, and the way they are written is worth reading, because each one carries a different risk. For Red Hat Enterprise Linux and distributions based on it, the support is provided by Red Hat developers because of the way kernel patches are handled in Red Hat. The current RHEL maintainer is listed as none, the author says he supports knowledgeable RHEL developers if they want to merge the required support and keep it current, and he reserves the right to delete this support without notice if it causes problems. That last clause is the important one for anyone planning to use this on RHEL: the support can be withdrawn, and the person withdrawing it is not the person to complain to. For Android, the driver is supported according to Realtek. The author will support knowledgeable Android developers who want to merge and keep the required support current, most likely just instructions about how to compile and maybe a modification or two to the Makefile. The current Android maintainer is also none. For OpenWRT, the answer is flat: it is not supported. The reasoning given is that OpenWRT provides its own drivers for USB WiFi adapters, and that those include support for the MT7921au, the AXE3000, the MT7612u, the AC1200, and the MT7610u, the AC600. It is a challenge to use Realtek based adapters with out-of-kernel drivers on OpenWRT, so it is strongly advised to use the already supported chipsets. That last one is a complete answer rather than a caveat, and it is the clearest example of the general principle in the readme: for a platform with its own driver stack, an out-of-tree driver is the wrong tool. ## Installing: the script, the conflicts, and dkms The installation section is surrounded by warnings, and the warnings are about process rather than about the driver itself. The first is that you are recommended to follow the installation instructions, and that you should avoid installing by downloading the zip file if at all possible. Support can only be provided, on a best effort basis, if the instructions are followed. That is a fair rule for a driver whose build depends on a matching kernel tree, and it is also a warning about a specific failure mode, since a zip install skips the parts that make the module rebuild after a kernel update. The second is about conflicts. Installing multiple out-of-kernel drivers for the same hardware usually does not end well. The install-driver.sh script has the capability to detect and remove most conflicting drivers, but not all, and if the driver does not work well after installation and a previous driver was not removed, the suggested command to find out whether you need to act is: ```bash sudo dkms status ``` That is the diagnostic to run first when something is wrong, and the mention of dkms is the clue to how the packaging works. The repository has dkms.conf and a dkms-make.sh, and DKMS is what makes a kernel module survive a kernel upgrade, which is exactly the problem an out-of-tree driver has and an in-tree one does not. There is a third warning about distribution upgrades, which will likely install a new kernel version. The implication is the same one that dkms addresses: a kernel change means the module has to be rebuilt, and the packaging has to arrange that. The repository layout supports the reading. There is install-driver.sh, remove-driver.sh, dkms.conf, dkms-make.sh, an edit-options.sh, a save-log.sh, a Kconfig file, a 8821au.conf with additional documentation, the FAQ.md, the supported-device-IDs file, and the driver sources in core/, hal/, include/, os_dep/ and platform/. ## The Makefile shows how the driver is configured The Makefile is the most direct evidence of how this driver is put together, and it is a large set of compile time switches rather than a small set of runtime options. The optimisation level is set to -O1, with -O3 present but commented out, which is the setting you would expect from a driver that must build against a wide range of kernels and compilers. The link flags strip debug information, and the include path for the driver's own headers is set explicitly. The configuration flags are where the feature set comes from. There is a flag that sets the wireless regulatory domain source to the operating system, which is the correct behaviour for a modern driver because the kernel owns the regulatory database. Another ensures all channels are scanned. The LED control is a set of three flags together, for the software LED implementation, the enable and the realtek software LED path. A comment marks the concurrent mode flag as something you uncomment to activate it. Then there is a long series of warning suppressions, grouped by compiler version. There is a block for gcc 12 that disables the address warning and the frame-larger-than warning and the cast-function-type warning, and a block for gcc 13 that disables the enum-int-mismatch, stringop-overread, enum-conversion and int-in-bool-context warnings, plus the missing prototypes and missing declarations ones. And at the top there is a version check that tests the compiler version and applies a date-time suppression for gcc 4.9 and later. That block of suppressions is the real maintenance story of this project. A driver that has to compile cleanly across gcc 12, 13, 14 and 15, and across kernels 5.4 to 7.2, accumulates a list of warnings that the current compiler does not emit and the next one will. The fact that the list is organised by compiler version rather than a single blanket switch is the mark of a maintainer who has to keep it compiling on several distributions at once. The Kconfig file and the set of configuration variables, including the multi-driver and the RTL8188E options switched off, complete the picture of a driver with a large compile time surface. ## Licence, releases and where the knowledge lives The licence field on the repository is listed as a custom licence that GitHub cannot classify, with a LICENSE file in the repository root. For a driver that people compile onto their own machines, the licence text is the thing to read before you redistribute it or include it in a product image. There are no GitHub releases, so there is no version history to browse and nothing to pin a distribution package to. The last push was on 2026-09-11 and the repository is not archived, and the notice at the top of the readme says the driver will not receive API related updates beyond kernel 6.14 unless a user provides them. So the project is in maintenance, with the work focused on compatibility rather than on new features, which is the right shape for a driver that a kernel has caught up with. The knowledge, though, is substantial, and it is distributed across a few places rather than in one document. The readme is the reference for the feature list, the matrices and the platform notes. The FAQ.md in the repository is a separate document, and the readme asks you to read the FAQ and the main document before posting issues. The 8821au.conf file holds additional documentation. And several of the companion repositories hold the guides for the modes that need their own instructions, the monitor mode guide, the bridged wireless access point guide, and the two adapter reference lists, one for adapters supported by in-kernel drivers and one for general adapter information. The closing line of the notice is a good summary of how the project wants to be read: remember to ask not what your operating system can do for you, but what you can do for your operating system. For a driver whose successor is in the kernel, that is the right advice for anyone considering installing it. ## Conclusion This driver suits an owner of a specific Realtek based USB adapter on a kernel older than 6.14, and a monitor mode user who needs a chipset the in-kernel drivers do not cover. It is the wrong choice for a new purchase, because the project itself says posting it is not a recommendation to buy Realtek based adapters, and a poor match for a current kernel, where the in-kernel rtw88 driver is described as of good quality and the standards compliant option. Before installing, check the supported-device-IDs file to confirm the chipset, and read FAQ.md, because the project asks you to read it before opening an issue. ## FAQ ### Do I still need this driver on a modern Linux kernel? Probably not. The readme says an updated standards compliant in-kernel driver for the rtl8821 and rtl8811au chipsets is available and is of good quality as of kernel 6.14, so on kernel 6.14 or later there is no need to install this one. For earlier kernels the project points to the lwfinger/rtw88 repository. ### How do I remove this driver before switching to the in-kernel one? Run sudo sh remove-driver.sh, as the notice in the readme instructs, and remember to remove this driver first if you decide to use the in-kernel driver instead. ### Which kernels, compilers and architectures does the 8821au driver support? Kernels 5.4 to 5.11 from Realtek and 5.12 to 7.2 with community support, with earlier kernels untested and unsupported. Compilers gcc 12, 13, 14 and 15. Architectures x86 through i686, x86-64, armv6l, armv7l and aarch64, with other architectures possibly working but untested. ### Why is my WiFi adapter not working after installing the driver? The most likely cause is another out-of-kernel driver for the same hardware still installed, since installing multiple such drivers usually does not end well. The install-driver.sh script removes most conflicts but not all, and the readme suggests running sudo dkms status to find out whether you need to remove conflicting drivers manually. ## Sources - [Issues](https://github.com/morrownr/8821au-20210708/issues) - [morrownr/8821au-20210708 on GitHub](https://github.com/morrownr/8821au-20210708) - [README](https://github.com/morrownr/8821au-20210708/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/morrownr-8821au-20210708