# 8814au: an out-of-tree Linux driver for RTL8814AU USB WiFi adapters > This repository is a maintained fork of the morrownr/8814au driver for Realtek RTL8814AU based USB WiFi adapters, supporting kernels 5.4 to 6.18.x on x86, ARM and ARM64 with DKMS rebuilds. It fits a Linux user whose adapter has no in-kernel driver, and it inherits the in-kernel rtw88 conflict that comes with recent kernels. **morrownr/8814au** — Linux Driver for USB WiFi Adapters that are based on the RTL8814AU Chipset - Repository: https://github.com/morrownr/8814au - Stars: 638 · Forks: 128 - Language: C - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/morrownr-8814au ## An out-of-tree driver, and the fork relationship to know about The repository is a Linux driver for USB WiFi adapters based on the RTL8814AU chipset. The README describes it as an actively maintained fork of morrownr/8814au, and it is worth reading the README rather than assuming which upstream you are looking at, because the install commands in it clone a different repository path, joseguzman1337/8814au. That detail matters practically. The clone URL in the install instructions, in the upgrade steps and in the removal steps points at joseguzman1337/8814au, and the badges in the README also link there, while the repository description names morrownr/8814au as the project being forked. Whichever you consider the upstream, the operational consequence is the same: the code you build comes from the joseguzman1337 repository, and that is the tree whose scripts you will be running. The driver supports kernels 5.4 through 6.18.x, and the README dates the state of it to February 2026. The last push to this repository was on 2026-08-19 and it is not archived, so the tree is current, though the project has no GitHub releases and you track versions by commit. The audience is narrow and identifiable: a Linux user with a USB WiFi adapter built on the Realtek RTL8814AU, on a kernel that does not ship a working driver for it, or on a kernel where the shipped driver is not doing what they need. The supported device list names the ALFA AWUS1900, the ASUS USB-AC68 AC1900, the Edimax EW-7833 UAC and the COMFAST CF-958AC, along with numerous other adapters on the same chipset, and a supported-device-IDs file in the repository holds the full list. The architecture coverage is x86 with i386 and i686 variants, x86-64 with amd64, ARM with armv6l and armv7l, and ARM64 with aarch64. ## What the driver actually supports on the wireless side The supported features table in the README is more informative than the marketing line, because it tells you what the driver can do once it binds. The standards are IEEE 802.11 b/g/n/ac. The security support covers 802.1x, WEP, WPA TKIP and WPA2 with AES or mixed mode, in both PSK and TLS or RADIUS flavours. Client mode includes site survey, manual connection and power saving. The interface modes are Managed, Monitor and AP, which is the important line for anyone who has used this hardware for packet capture or for setting up an access point. The controls list log level, LED, power saving, VHT at 80 MHz in AP mode, and USB mode. That last one is the sort of setting that only exists because these adapters present themselves over USB and the driver has to be told how to talk to it. The LED control is worth a sentence of its own, because for a USB adapter the LED is a physical indicator on the dongle and users tend to want it off. The Makefile in the repository shows the build flags behind these features, with separate defines for the software LED path, the LED control toggle and the LED enable, and the RTL8814 software LED variant. There is also a define that sets the wireless regulatory domain source to the operating system, and a comment on the channel plan flag saying it may be needed to ensure all channels are scanned. So the driver is configurable at build time as well as at runtime, and the Makefile is the place to look for what is compiled in. ## DKMS or a manual build, and the difference after a kernel upgrade The installation section is organised by distribution, and the pattern is the same everywhere: install the kernel headers and the build tools, clone the repository, and run the install script. On Ubuntu, Debian and Kali the command is: ```bash sudo apt install -y linux-headers-$(uname -r) build-essential dkms git libelf-dev rfkill iw git clone https://github.com/joseguzman1337/8814au.git cd 8814au sudo ./install-driver.sh ``` Arch, Garuda and Manjaro use pacman and a slightly shorter package list, openSUSE uses zypper with the devel_kernel pattern, Fedora and CentOS use dnf with kernel-devel, and Raspberry Pi OS and Void Linux each have their own variant. Two notes are worth carrying over to any other distribution. On Manjaro and Kali on a Raspberry Pi 4B or 5B you need the Raspberry Pi specific headers package rather than the generic linux-headers one. The manual path skips the script entirely: ```bash make clean make sudo make install # if Secure Boot is OFF sudo make sign-install # if Secure Boot is ON sudo reboot ``` And the README is explicit about the consequence of taking that path: manual installs must be repeated after each kernel upgrade, and the recommendation is to use install-driver.sh with DKMS for automatic rebuilds. That difference is the whole operational story of this driver. An out-of-tree module is compiled against one kernel's headers, and the next kernel update invalidates it. DKMS turns that into an automatic rebuild on the machine, and the install script does it for you. The dkms.conf and dkms-make.sh files at the repository root are the pieces that make that work. ## Secure Boot means you have to enrol a key, not just sign a module The Secure Boot section is the one most people hit on a modern distribution, and it is a two-stage process that the README explains in a way worth reading in order. First you install with the signing variant, sudo make sign-install, and you are prompted for a password. Then on reboot, the MOK management screen appears, and the steps are to enroll the key, continue, and answer yes, and finally to enter the password you chose during the install step. The Fedora case has an extra step, importing the key directly with mokutil: ```bash sudo mokutil --import /var/lib/dkms/mok.pub ``` The file path is the same one DKMS uses for the machine owner key, which is why the repository's dkms.conf and the MOK enrolment fit together. There is a FAQ.md in the repository with more detail on this. The runtime configuration is separate from all of this and is handled through a modprobe configuration file. The install script places 8814au.conf in /etc/modprobe.d/, and you edit it by running the edit script: ```bash sudo ./edit-options.sh ``` The 8814au.conf file at the repository root is the file the README says holds documentation for all options, so the module parameters are discoverable without digging through the source. ## The rtw88 conflict is the real problem on a modern kernel The troubleshooting section documents a conflict that has become the defining issue for this driver, and it is the first thing to check before installing. Some modern kernels include an in-kernel rtw88_8814au driver that may bind to the same USB IDs as this out-of-tree driver. If both are active, the README says behavior can be inconsistent. The first check it recommends is a runtime health check that changes nothing: ```bash ./tools/runtime-healthcheck.sh ``` If the report shows both 8814au and rtw88_8814au loaded, the system is in a mixed-driver state. The repository's answer is that install-driver.sh now installs a blacklist file for rtw88_8814au to avoid future conflicts. That is a blunt instrument, and it is worth understanding what it means. Blacklisting the in-kernel module means that on kernels where rtw88_8814au would have worked, you are deliberately choosing the out-of-tree driver instead, and the out-of-tree driver is the one that has to track kernel API changes across a 5.4 to 6.18.x range. A team that values the stability of an in-tree module is being asked to give that up for capabilities the in-tree driver may not have. For environments where rebooting is not an option, the repository ships a hot-switch path that rebinds the USB device between the native and out-of-tree drivers without changing the kernel version: ```bash sudo ./tools/hot-switch-driver.sh --to native sudo ./tools/hot-switch-driver.sh --to oot ``` The script captures pre and post snapshots for each step under /tmp/rtl8814au-switch-*, and a related tool, hotplug-issue-suite.sh, produces a Markdown report plus per-step artifacts under /tmp/rtl8814au-issue-suite-*. The repository also lists runtime-issue-suite.sh for reassessment of upstream reports focused on runtime failures, and injection-selftest.sh as a non-destructive monitor and injection smoke test with time-windowed kernel log checks. All of these preserve the current kernel version and avoid a reboot as part of normal operation. ## Upgrading and removing, and where this driver stops The upgrade path is a remove and reinstall, which is the honest shape for an out-of-tree module: ```bash cd ~/src/8814au sudo ./remove-driver.sh git pull sudo ./install-driver.sh ``` and the removal is the same script on its own: ```bash cd ~/src/8814au sudo ./remove-driver.sh ``` Note the path in both, ~/src/8814au, which tells you the install script expects the clone to live in a source directory under your home rather than anywhere on disk. Where this driver stops is the question to ask before investing in it. It is for one chipset on one bus, and its value over the in-kernel driver is not that it is faster or more capable in general, but that it offers a configuration surface the in-tree driver does not, in a set of adapters where the in-tree driver is missing or unreliable. It is also a GPL project with an out-of-tree kernel module, which means the licensing terms are the kernel's, and a Linux distribution that refuses out-of-tree modules will refuse this one. The README carries a GPL badge and a LICENSE file, while the platform metadata lists the licence as one GitHub cannot classify, so the file itself is the authority. There is more housekeeping in the repository than a typical driver needs. Alongside the source directories for the core, hal, include, os_dep and platform code, there is a Kconfig, a dkms.conf, a dkms-make.sh, a save-log.sh script for collecting diagnostics, a supported-device-IDs file, a default-editor.txt, and a set of markdown tracking documents: BACKLOG_MAINTENANCE.md, UPSTREAM_ISSUE_TRACKING.md and ISSUE_RESOLUTION_REPORT.md. That last cluster of documents is a good sign, because it means the maintainers record the upstream issues they are chasing rather than closing them silently. ## Conclusion The 8814au driver fits a Linux user with an RTL8814AU based USB adapter, on a distribution where the adapter has no working in-kernel driver, who accepts an out-of-tree module that has to be rebuilt against each kernel. It is the wrong choice on recent kernels where the in-kernel rtw88_8814au driver binds first, and the wrong choice for a machine where a signed, in-tree module is a requirement rather than a preference. Before installing, run the runtime health check the repository ships to see whether both drivers are loaded, and prefer the DKMS path over the manual build so that kernel upgrades do not leave you without a driver. ## FAQ ### What hardware does the 8814au Linux driver support? It is a driver for USB WiFi adapters based on the Realtek RTL8814AU chipset, with named examples including the ALFA AWUS1900, the ASUS USB-AC68, the Edimax EW-7833 UAC and the COMFAST CF-958AC, and a full list in the supported-device-IDs file. ### Which kernels and architectures does the 8814au driver support? The README states support for kernels 5.4 to 6.18.x, and the architecture table covers x86 with i386 and i686, x86-64 with amd64, ARM with armv6l and armv7l, and ARM64 with aarch64. ### How do I install the 8814au driver on Ubuntu or Debian? Install the packages with apt including linux-headers-$(uname -r), build-essential, dkms, git, libelf-dev, rfkill and iw, clone the repository, then run sudo ./install-driver.sh from inside the cloned directory. ### What is the rtw88_8814au conflict in the 8814au driver? Some modern kernels include an in-kernel rtw88_8814au driver that may bind to the same USB IDs, and if both are active the behavior can be inconsistent, so the repository ships a health check script and installs a blacklist file for rtw88_8814au during the install script. ## Sources - [Issues](https://github.com/morrownr/8814au/issues) - [morrownr/8814au on GitHub](https://github.com/morrownr/8814au) - [README](https://github.com/morrownr/8814au/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-8814au