Fix RTL8723BS Wi-Fi Not Working on Linux: Full Guide

Your tablet or cheap SBC updated its kernel, rebooted, and now Wi-Fi just isn't there. No error dialog, no obvious crash, just a network menu with nothing in it. If that machine has an Allwinner or Intel Atom SoC and cost under $150, there's a good chance you're dealing with the RTL8723BS chipset, and its driver has been a known source of pain since it landed in the Linux kernel's staging tree back in 2017.

That driver has stayed in staging for nine years and counting, still getting cleanup patches every kernel cycle instead of graduating to mainline. Staying in staging matters practically because it means the driver doesn't get the same stability guarantees as mainline code, and distro maintainers sometimes exclude or downgrade it. Here's how to confirm you're dealing with RTL8723BS, what actually breaks, and how to get it working again.

Confirm You're Actually Dealing With RTL8723BS

Before chasing the wrong fix, verify the chipset. Run lsusb if your device uses a USB-connected module, or lspci if it's soldered onto a PCIe or SDIO bus. Look for vendor ID 0bda (Realtek) paired with device strings mentioning 8723bs, 8723bu, or similar.

On many SBCs and budget tablets, the chip connects over SDIO rather than USB or PCIe, so it won't show up in lsusb or lspci at all. In that case, run dmesg | grep -i rtl or check /sys/class/net for an interface, then cross-reference with cat /sys/class/mmc_host/mmc*/mmc*/uevent to spot SDIO device IDs. You can also check dmesg | grep -i sdio for lines referencing the Realtek vendor.

The chip is common in a specific hardware niche: sub-$100 Windows tablets converted to run Linux, early Raspberry Pi competitors, and combo Wi-Fi/Bluetooth modules bundled with Allwinner A64 and A33 boards. If your device falls into one of those categories and Wi-Fi vanished after a kernel or distro upgrade, RTL8723BS is the prime suspect.

Why This Chipset Fails So Often After Updates

The RTL8723BS driver lives in drivers/staging/rtl8723bs in the kernel source tree, and staging drivers don't follow the same API stability rules as the rest of the kernel. When kernel internals shift, staging drivers sometimes lag behind or break outright until someone submits a fix. That's the structural reason this chipset breaks disproportionately often compared to hardware with mainline drivers.

There's also a firmware dependency problem. The driver needs a matching firmware blob, typically named something like rtl8723bs_nic.bin or rtl8723bs_wifi_bt.bin, loaded from /lib/firmware/rtlwifi/ or a similarly named directory. If a distro update strips out the linux-firmware package's non-free components, or if the firmware version mismatches the driver version bundled in a new kernel, the module loads but the card never associates with a network. See related: freebsd 14.5-rc1: upgrade now or wait for ga? for additional background.

A third failure mode involves the SDIO bus itself. Some device trees, especially on Allwinner-based boards, define SDIO timing parameters that newer kernels interpret differently. This can cause the card to enumerate but never actually bring up an interface, which is why dmesg sometimes shows the module loading successfully while ip link shows nothing usable.

Kernel Module and Firmware Fixes That Actually Work

Start with the basics before assuming the driver is unfixable. Run lsmod | grep rtl8723bs to confirm the module loaded. If it didn't, force it with sudo modprobe rtl8723bs and check dmesg immediately afterward for error messages.

If the module loads but no interface appears, or the interface appears but never connects, check firmware placement. Realtek firmware blobs need to live in the exact path the driver expects, and a version mismatch produces silent failures rather than clear errors.

• Verify firmware presence: ls /lib/firmware/rtlwifi/ or ls /lib/firmware/rtl_bt/ depending on your distro's packaging
• Reinstall the firmware package: on Debian/Ubuntu, sudo apt install --reinstall firmware-realtek; on Fedora, sudo dnf reinstall linux-firmware; on Arch or Manjaro, sudo pacman -S linux-firmware-realtek
• Check dmesg for firmware load failures: dmesg | grep -i firmware

If firmware is present and correctly named but the card still won't associate, try unloading and reloading the module with a specific parameter that disables power management, which is a known trigger for association drops on this chipset: sudo modprobe -r rtl8723bs && sudo modprobe rtl8723bs rtw_power_mgnt=0. Make this persistent by adding a file under /etc/modprobe.d/rtl8723bs.conf containing options rtl8723bs rtw_power_mgnt=0.

If you're running a kernel newer than what shipped with your distro's original image, and Wi-Fi broke specifically after a kernel bump, consider pinning back to the last known-working kernel version while you wait for staging fixes to land. On Debian and Ubuntu, dpkg --list | grep linux-image shows installed kernels, and GRUB's advanced boot menu lets you select an older one at boot.

Distro-Specific Quirks Worth Knowing

Ubuntu and Debian generally bundle the RTL8723BS driver as a module rather than compiling it in, which means it's easier to blacklist, reload, or replace without rebuilding the kernel. Check /etc/modprobe.d/blacklist.conf for any accidental blacklist entries left over from a previous troubleshooting session, since that's a common self-inflicted cause of "Wi-Fi just disappeared."

Fedora tends to ship more recent kernels faster than Ubuntu LTS releases, which means Fedora users often hit staging-driver regressions earlier, sometimes before community fixes have propagated back through stable kernel branches. If you're on Fedora and Wi-Fi broke right after a dnf upgrade, check whether a new kernel version installed alongside the old one, and test booting the previous kernel from the GRUB menu before doing anything else.

Arch and Manjaro users get bleeding-edge kernels fastest, which cuts both ways. You'll get staging fixes sooner, but you're also more likely to hit a temporary regression the day it lands. The Arch Wiki's Realtek wireless page tracks known issues for this chipset family and is worth checking before filing a bug.

Also read: why linux kernel cve counts are skyrocketing in 2025: the details

On any distro, if the device also uses the Bluetooth half of this combo chip, expect the two radios to fail somewhat independently. It's common to have working Wi-Fi with dead Bluetooth or vice versa, because they load through separate subsystems, hci_uart for Bluetooth and the rtl8723bs staging module for Wi-Fi, even though they share the same physical antenna and firmware family.

When to Give Up on the In-Tree Driver

If you've verified firmware, tried the power management workaround, and confirmed the module loads without errors, but the card still won't hold a connection reliably, the in-tree staging driver may just be too unstable for your specific board revision. This happens more often than distro maintainers like to admit, and it's a legitimate reason to look elsewhere rather than keep fighting kernel parameters.

The most reliable alternative is Realtek's own out-of-tree driver repositories, several of which the community has forked and kept updated on GitHub specifically for RTL8723BS and its siblings. These require DKMS to rebuild against your current kernel automatically, which you set up with sudo apt install dkms or the equivalent on your distro, then cloning the driver source and running its included install script. The tradeoff is that DKMS modules can break again on kernel updates until DKMS rebuilds them, so check dkms status after any kernel upgrade.

For SBCs specifically, check whether your board vendor ships a customized kernel or device tree overlay with SDIO timing fixes baked in. Armbian, for instance, maintains board-specific patches for several Allwinner boards that address SDIO enumeration issues the mainline staging driver doesn't handle well. Switching to a board-specific kernel build is often less work than debugging staging driver internals yourself.

As a last resort, a $10-15 USB Wi-Fi dongle with a mainline-supported chipset, such as anything using the Realtek RTL8188EU or MediaTek MT7601U, sidesteps this entire mess. It's not elegant, but it's often faster than waiting for the next round of staging cleanups to fix your specific failure mode.

The RTL8723BS situation isn't going to resolve itself soon. Nine years in staging with no clear graduation timeline means this chipset will keep producing these exact symptoms for as long as budget hardware manufacturers keep using it. Treat the fixes here as a working toolkit rather than a permanent solution, check firmware and power management settings first, verify you're not fighting a kernel-specific regression, and know when switching to a supported dongle is the more productive use of your time.