# lwfinger/rtw88 WiFi 5 Drivers for Linux

> lwfinger/rtw88 provides out-of-tree Realtek rtw88 drivers for selected USB, PCIe, and SDIO WiFi 5 adapters running Linux 5.4 or newer. It suits systems whose distribution kernel lacks working support for a listed chipset.

**lwfinger/rtw88** — A backport of the Realtek Wifi 5 drivers from the wireless-next repo.

- Repository: https://github.com/lwfinger/rtw88
- Stars: 1,672 · Forks: 321
- Language: C
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/lwfinger-rtw88

## The Hardware Gap Addressed by lwfinger/rtw88

lwfinger/rtw88 is an out-of-tree driver repository for Linux systems that need support for selected Realtek WiFi 5 adapters. Its stated purpose is development, testing, and maintenance of the Realtek rtw88 series. It is intended for users whose distribution kernel does not provide a working driver for their adapter, rather than people looking for a WiFi configuration application.

The supported hardware is specific. For PCIe, the README lists RTL8723DE, RTL8812AE, RTL8814AE, RTL8821AE, RTL8821CE, RTL8822BE, and RTL8822CE. For SDIO, it lists RTL8723CS, RTL8723DS, RTL8821CS, RTL8822BS, and RTL8822CS. Its USB list includes RTL8723DU, RTL8811AU, RTL8811CU, RTL8812AU, RTL8812BU, RTL8812CU, RTL8814AU, RTL8821AU, RTL8821CU, RTL8822BU, and RTL8822CU.

An adapter's marketing name is not enough to establish compatibility. Its USB or PCI identifier should correspond to a chipset in the README list. The project also calls for testing of newer RTL8814AU support and asks for reports from users of RTL8814AE, RTL8812AE, and RTL8821AE. Those statements show that inclusion in the driver family does not remove the need to verify behavior on a particular card.

The stated operating-system boundary is Linux 5.4 and newer, but only where the distribution has not changed the relevant kernel APIs. The README specifically warns that RHEL and RHEL-derived distributions are unlikely to work with this downstream driver.

## Shared Core and Chipset-Specific rtw88 Modules

The repository layout shows a shared driver core with separate modules for chipset families and Linux transport types. The Makefile builds `rtw_core` as an object module and also defines groups for `rtw_pci`, `rtw_sdio`, and `rtw_usb`. Device-specific entries include modules such as `rtw_8814ae`, `rtw_8821cu`, and `rtw_8723de`.

The README's RTL8821CU example demonstrates that module dependencies are part of normal operation. After loading `rtw_8821cu`, its documented `lsmod` output includes `rtw_usb`, `rtw_8821c`, and `rtw_core`. Removing the driver requires the device-specific module to be unloaded before the shared core:

```bash
sudo modprobe -r rtw_8821cu
sudo modprobe -r rtw_core
```

The ordering is relevant. The README attributes the two-step removal partly to `modprobe` behavior and says that users can inspect currently loaded modules with:

```bash
lsmod | grep -i rtw
```

The C source is divided by responsibility. Files such as `mac80211.c`, `mac.c`, and `phy.c` cover Linux wireless integration and hardware operations. `rx.c` and `tx.c` separate packet reception and transmission. `ps.c` handles a power-management area, while `fw.c` relates to firmware. Other files include dedicated modules for radio coexistence, regulatory data, hardware values, LEDs, security, and SAR handling.

This is a compiled Linux kernel module package. Firmware and configuration are also required, so copying source files or enabling one line in a distribution package configuration would not constitute an installation.

## Installing lwfinger/rtw88 with DKMS

The README calls DKMS installation the preferred method because it rebuilds and re-signs modules after kernel updates. This matters particularly when Secure Boot is enabled. DKMS itself must first be installed through the distribution's package manager.

On Ubuntu, install the documented compilation prerequisites before cloning the repository:

```bash
sudo apt install linux-headers-generic build-essential git
```

The missing generic headers package command shown in the README is preceded by a package update command, but only the documented install command is needed here. The reader should see packages for headers, the build toolchain, and Git installed without errors.

Clone the exact downstream repository, change into it, and pass the checkout path to DKMS:

```bash
git clone https://github.com/lwfinger/rtw88
cd rtw88
sudo dkms install $PWD
```

This invocation asks DKMS to build, sign, and install the modules for the running kernel. It can fail if the headers do not match that kernel. The README gives this missing build-tree error as an example:

```text
make[1]: *** /lib/modules/5.17.5-300.fc36.x86_64/build: No such file or directory.
```

The README instructs users encountering that message to stop and install kernel headers. It should not be interpreted as evidence that the rtw88 source itself is incomplete.

Module installation and firmware installation are separate operations. Run:

```bash
sudo make install_fw
```

The Makefile declares `/lib/firmware/rtw88` as the firmware destination. Finally, install the supplied module configuration:

```bash
sudo cp rtw88.conf /etc/modprobe.d/
```

The resulting system state should include DKMS-managed modules, firmware under the declared path, and `rtw88.conf` in `/etc/modprobe.d/`.

## Secure Boot and rtw88 Module Signing

DKMS handles rebuilding and signing across kernel updates, but an enrolled Machine Owner Key is still required when Secure Boot is enabled. The README gives this command for systems using the standard DKMS public-key location:

```bash
sudo mokutil --import /var/lib/dkms/mok.pub
```

It provides a second path for Ubuntu-based systems that use a shim-managed certificate:

```bash
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
```

Only the path that exists on the system should be used. The command requests a password, and the README requires the user to enter that password after rebooting to complete UEFI key enrollment. A successful key-import command alone does not complete enrollment if the machine has not been rebooted into the MOK interface and confirmed the key.

The driver configuration also changes which rtw88 implementation Linux is permitted to load. According to the README, `rtw88.conf` blacklists all in-kernel rtw88 drivers. That is how the downstream modules take priority over corresponding kernel modules.

There is a boundary here. The config does not blacklist out-of-tree vendor drivers. A separately installed Realtek package can therefore remain active and conflict with this installation. The README says to uninstall such conflicting vendor drivers.

The README does not provide a full rollback procedure for restoring every replaced kernel module, removing firmware, or reversing Secure Boot enrollment. The documented uninstall-related operation is module unloading, not a complete reversal of the installation.

## Manual Compilation and Arch-Based Installation

The Makefile supports direct installation, but the maintenance burden is greater than with DKMS. The driver must be rebuilt and reinstalled after every kernel update. The README does not recommend this method when Secure Boot is enabled because the direct sequence does not handle the same automatic module lifecycle.

The documented manual installation is:

```bash
git clone https://github.com/lwfinger/rtw88
cd rtw88
make
sudo make install
```

The build selects `uname -r` unless `KVER` is supplied and looks for kernel sources under `/lib/modules/$(KVER)/build`. It also defines `KSRC`, which defaults to `/lib/modules/$(KVER)/build` and can be overridden through `KERNEL_SRC`. The central requirement remains valid headers or source for the target kernel.

After module installation, firmware and configuration still need to be installed:

```bash
sudo make install_fw
sudo cp rtw88.conf /etc/modprobe.d/
```

Arch-based systems have a separate package route. The README points to the AUR repository and gives this sequence:

```bash
git clone https://aur.archlinux.org/rtw88-dkms-git.git
cd rtw88-dkms-git
makepkg -si
```

On an Arch-based system with Secure Boot enabled, the README still requires Machine Owner Key enrollment. The AUR package is therefore not a shortcut around Secure Boot. The repository's own documentation does not specify the AUR package's internal build commands, so its `PKGBUILD` would need to be inspected separately before relying on details not stated in the README.

## Sleep, Hibernation, and Driver Recovery

Some BIOS implementations have difficulty changing power state from D3hot to D0. The README connects this hardware behavior with rtw88 recovery problems after sleep or hibernation. For affected systems, it supplies a systemd system-sleep script:

```bash
sudo cp reload_rtw88.sh /usr/lib/systemd/system-sleep/
```

The README states that `reload_rtw88.sh` unloads the driver before sleep or hibernation and loads it again after resumption. Installing it in `/usr/lib/systemd/system-sleep/` places the script where systemd executes hooks around those transitions.

This is a narrow workaround. The documentation does not say that every resume failure has the same cause, nor does it identify affected BIOS vendors or models. It also does not document automatic detection of the D3hot-to-D0 failure. Users need evidence that their system encounters the documented problem before treating the script as a general connectivity fix.

The same hardware can otherwise remain functional, so adding the script has an operational cost: the wireless module is deliberately removed during sleep and resume transitions. The README does not quantify network availability or connection recovery time in that interval. Based on its stated mechanism, the script trades uninterrupted driver persistence for a fresh load after resume on systems whose firmware cannot handle the transition correctly.

## Maintenance, Releases, and License Boundaries

The repository is not archived, and its last push was on 2026-05-21. It has no GitHub releases. That means there is no documented release artifact or tagged release series in the repository metadata, so users following `master` need to account for changes occurring outside a conventional binary release process.

The README says the code stays synchronized with `wireless-next`, while this repository includes changes for kernel API compatibility. It also distinguishes `wireless-next` as the source for the next kernel version. This downstream role explains why compatibility with a currently installed Linux kernel can change as kernel APIs move. It does not provide a promise that every driver revision works across every distribution kernel.

Upgrades have a measurable operational cost when DKMS is used: the modules must be rebuilt and re-signed after a kernel update, and firmware installation remains part of installation. Direct `make` users must repeat module compilation and installation after each kernel change. Conflict cleanup may also be required if another vendor driver has been installed.

The repository metadata provides no license identifier. The presence of `certificate.pem`, `key.pem`, `certificate.p12`, and `openssl.conf` does not by itself establish the licensing terms for the driver source. Code users who need an explicit source-license grant must verify that outside the README. No legal interpretation should be inferred from the signing files.

## Choosing rtw88 Instead of a Kernel Driver

The practical alternative for many users is the rtw88 implementation already supplied by their distribution kernel. That path normally avoids an out-of-tree source build, DKMS lifecycle, manually installed firmware, and replacement of in-kernel modules. It is the better first choice when the distribution recognizes the adapter and provides a working driver.

The approaches differ in ownership of updates. A distribution kernel driver follows the distribution's package and kernel maintenance process. lwfinger/rtw88 is a downstream checkout that stays synchronized with `wireless-next` and adds compatibility changes for older APIs. The downstream route offers device support when the distribution kernel lacks it, but it transfers more build, signing, and module-management work to the user.

A second alternative is a prebuilt vendor driver package. The README does not identify a particular package, so its compatibility and maintenance cannot be inferred here. What can be said from the project documentation is that any out-of-tree vendor driver may conflict with lwfinger/rtw88 because `rtw88.conf` does not blacklist vendor modules. Such a package would need separate review before installation alongside this repository.

rtw88 is the wrong tool for unlisted chipsets, RHEL-derived kernels with modified APIs, or systems where another driver must remain active. It is relevant when the exact adapter is listed and the distribution version of rtw88 is missing, incomplete, or unsuitable for the user's Linux kernel.

## Conclusion

Adopt lwfinger/rtw88 if you have one of its listed Realtek adapters, need an out-of-tree driver, and run Linux 5.4 or newer without modified kernel APIs. Do not assume support for unlisted hardware or RHEL-derived systems. Before installation, verify the exact chipset, matching kernel headers, Secure Boot requirements, firmware support, and successful DKMS compilation for your selected adapter.

## FAQ

### Which Linux kernels are compatible with lwfinger/rtw88?

The README states compatibility with Linux 5.4 and newer when the distribution has not modified relevant kernel APIs. It warns that RHEL and RHEL-derived distributions are unlikely to be compatible.

### Does lwfinger/rtw88 support my Realtek WiFi adapter?

Check the README's supported chipset list. Compatibility is chipset-specific across PCIe, SDIO, and USB, and an adapter outside that list should not be assumed to work.

### Why should I install lwfinger/rtw88 with DKMS?

The README says DKMS automatically rebuilds and re-signs the modules after kernel updates. This avoids manual recompilation and re-signing, especially on systems with Secure Boot enabled.

## Sources

- [Issues](https://github.com/lwfinger/rtw88/issues)
- [lwfinger/rtw88 on GitHub](https://github.com/lwfinger/rtw88)
- [README](https://github.com/lwfinger/rtw88/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lwfinger-rtw88