Linux Wi-Fi Drivers: Getting Difficult Chipsets Working

1 Aug 2026

Linux Wi-Fi support has improved enormously, and many wireless adapters work immediately after installation. Connect to a network, enter the password and carry on.

Unfortunately, not every chipset behaves that well.

Some adapters require non-free firmware. Others depend on a newer kernel, an out-of-tree driver or a distribution-specific package. USB Wi-Fi dongles can be particularly awkward because two products sold under the same retail name may contain completely different chipsets.

When Linux detects the wireless device but no networks appear—or the adapter disappears entirely—the right approach is to identify the hardware first and install only the driver or firmware it actually needs.

This guide explains how to diagnose difficult Linux Wi-Fi chipsets, install missing support safely and avoid common fixes that create more problems than they solve.

Start With the Chipset, Not the Brand Name

The name printed on the laptop or USB adapter is often not enough to identify the driver.

A manufacturer may sell several hardware revisions under the same product name. One revision might use a Realtek chipset, another MediaTek and another Broadcom.

The driver depends on the chipset inside the device, not the logo on the box.

For an internal PCIe Wi-Fi adapter, run:

lspci -nnk | grep -A3 -i network

Typical output might look like:

Network controller [0280]: Intel Corporation Wireless-AC 9560 [8086:a370]

Subsystem: Intel Corporation Device [8086:0034]

Kernel driver in use: iwlwifi

Kernel modules: iwlwifi

For a USB adapter, use:

lsusb

Example:

Bus 001 Device 006: ID 0bda:c811 Realtek Semiconductor Corp.

The hexadecimal vendor and device identifiers are particularly useful:

0bda:c811

Those IDs are often more reliable than the retail model name when researching driver support.

Check Whether Linux Can See the Device

Before installing anything, confirm that the hardware is visible.

For PCIe devices:

lspci

For USB devices:

lsusb

For network interfaces:

ip link

You may see a wireless interface named something like:

wlan0

wlp2s0

wlx0013ef123456

If the device appears in lspci or lsusb but no wireless interface exists, the driver may be missing, failing to load or waiting for firmware.

If the device does not appear at all, the problem may involve:

A disabled radio in BIOS or UEFI
A physical wireless switch
A faulty USB port
A damaged adapter
A virtual machine without USB or PCI passthrough
A loose internal card
Hardware blocked by firmware settings

Check the Current Driver

Use:

lspci -nnk | grep -A3 -i network

Look for:

Kernel driver in use:

and:

Kernel modules:

For a USB adapter, inspect loaded modules with:

lsmod

You can also check the driver attached to a network interface:

sudo ethtool -i wlp2s0

Replace wlp2s0 with the actual interface name.

Example output:

driver: iwlwifi

version: 6.x

firmware-version: ...

bus-info: 0000:02:00.0

If the driver field is present, Linux has attached a driver. That does not necessarily mean the device is working correctly, but it narrows the investigation.

Check for Missing Firmware

Many Linux Wi-Fi drivers are included in the kernel, but the adapter also needs a separate firmware file.

The driver loads first, then requests firmware from userspace. If the firmware is missing, the device may appear in the hardware list but fail to initialise.

Check the kernel messages:

sudo dmesg | grep -i firmware

You can also search for wireless-related errors:

On systemd-based distributions:

sudo journalctl -k | grep -iE "firmware|wifi|wireless|wlan"

Typical missing-firmware messages include wording such as:

failed to load firmware

Direct firmware load failed

firmware: failed to load

When you see a specific filename, note it exactly. That is usually the clearest indication of what the driver expects.

Install the Distribution’s Firmware Package First

Before downloading drivers from GitHub or running random installation scripts, install the firmware package provided by your Linux distribution.

Ubuntu and Debian

Start with:

sudo apt update

sudo apt install linux-firmware

On Debian, some wireless firmware may be supplied through packages in the non-free-firmware repository.

Useful packages may include:

sudo apt install firmware-iwlwifi

sudo apt install firmware-realtek

sudo apt install firmware-atheros

sudo apt install firmware-brcm80211

sudo apt install firmware-mediatek

Package names vary by distribution release.

Fedora

Update the firmware packages with:

sudo dnf upgrade linux-firmware

Install it if missing:

sudo dnf install linux-firmware

Arch Linux

Use:

sudo pacman -Syu linux-firmware

openSUSE

Use:

sudo zypper refresh

sudo zypper install kernel-firmware-all

After installing firmware, reboot or reload the affected driver.

For example:

sudo modprobe -r iwlwifi

sudo modprobe iwlwifi

Do not remove a module while it is actively in use on your only network connection unless you have another way to regain access.

Check Whether the Radio Is Blocked

A driver can be working perfectly while the wireless radio remains disabled.

Check with:

rfkill list

Example:

0: phy0: Wireless LAN

Soft blocked: yes

Hard blocked: no

Remove a software block:

sudo rfkill unblock wifi

Or unblock everything:

sudo rfkill unblock all

A hard block usually means the radio has been disabled by:

A laptop function key
A physical switch
BIOS or UEFI
An airplane-mode control
Platform firmware

Software cannot normally override a genuine hardware block.

Check NetworkManager

Most desktop distributions use NetworkManager.

Check its status:

systemctl status NetworkManager

Restart it:

sudo systemctl restart NetworkManager

List detected devices:

nmcli device

Enable wireless networking:

nmcli radio wifi on

Scan for networks:

nmcli device wifi list

If the adapter appears as unavailable, inspect the logs:

sudo journalctl -u NetworkManager -b

If it appears as unmanaged, configuration elsewhere may be preventing NetworkManager from controlling it.

Confirm the Interface Is Up

List interfaces:

ip link

Bring the wireless interface up:

sudo ip link set wlp2s0 up

If that returns an error, check the kernel log immediately:

sudo dmesg | tail -50

Messages such as firmware failures, invalid calibration data or radio-kill errors can explain why the interface will not activate.

Update the Kernel

Some Wi-Fi chipsets require a newer kernel because their driver was added or improved after the distribution’s original release.

Check the current kernel:

uname -r

Install available updates through the distribution’s normal package manager.

On Ubuntu or Debian:

sudo apt update

sudo apt full-upgrade

On Fedora:

sudo dnf upgrade

On Arch:

sudo pacman -Syu

Reboot after a kernel update:

sudo reboot

Then confirm the new kernel:

uname -r

Avoid installing an unsupported mainline kernel simply because a forum post recommends it. Distribution-supported kernels are normally safer because they receive compatible security updates, packaging and bootloader integration.

Common Chipset Families

Different Wi-Fi vendors tend to have different Linux support patterns.

Intel

Intel wireless adapters are usually among the easiest to support.

Common drivers include:

iwlwifi

Most problems involve:

Missing or outdated firmware
A kernel that is too old for a new chipset
Power-management issues
Regulatory-domain configuration
Hardware or BIOS radio blocks

Check Intel driver messages with:

sudo dmesg | grep -i iwlwifi

Reload the driver:

sudo modprobe -r iwlwifi

sudo modprobe iwlwifi

Qualcomm Atheros

Common drivers include:

ath9k

ath10k

ath11k

ath12k

Older Atheros adapters often work well because support has been in the kernel for years.

Newer Qualcomm chipsets may need:

A recent kernel
Matching firmware
Board calibration files
Updated distribution packages

Inspect messages with:

sudo dmesg | grep -i ath

MediaTek

Common drivers include:

mt7601u

mt76

mt7921e

mt7921u

mt7922

Many newer MediaTek devices have good in-kernel support, but recent hardware may require a newer kernel and firmware package.

Check messages with:

sudo dmesg | grep -iE "mt76|mt79"

Broadcom

Broadcom is one of the more complicated Linux Wi-Fi families because different chipsets use different drivers.

Possible drivers include:

brcmsmac

brcmfmac

b43

The proprietary Broadcom STA driver is commonly exposed as:

On Ubuntu-based systems, it may be available through:

sudo apt install bcmwl-kernel-source

However, that package is not appropriate for every Broadcom device.

Identify the exact PCI ID before selecting a Broadcom driver:

lspci -nnk | grep -A3 -i network

Installing the wrong Broadcom module can blacklist or conflict with the correct one.

Realtek

Realtek adapters are responsible for many of the most difficult Linux Wi-Fi cases, particularly USB dongles.

Some Realtek chipsets are well supported by in-kernel drivers, while others depend on third-party modules.

Possible driver names include:

rtl8xxxu

rtw88

rtw89

rtl8192cu

rtl8812au

rtl8821cu

rtl88x2bu

The important point is that “Realtek Wi-Fi” is not a single driver family. A driver built for one chipset will not necessarily work with another.

Use the USB or PCI ID to identify the exact device:

lsusb

or:

lspci -nn

Then inspect the kernel messages:

sudo dmesg | grep -iE "rtl|rtw"

Installing an Out-of-Tree Driver

An out-of-tree driver is maintained outside the main Linux kernel.

This may be necessary for certain USB adapters, but it should be a last resort rather than the first step.

The risks include:

The driver breaking after a kernel update
Poor power management
Monitor-mode or access-point problems
Secure Boot blocking the module
Conflicts with an in-kernel driver
Unmaintained source code
Installer scripts making undocumented system changes

Before installing one, confirm:

The chipset ID matches exactly.
The repository supports your kernel version.
The project is actively maintained.
The installation method uses DKMS where possible.
You know how to remove it again.

Install Build Requirements

On Ubuntu or Debian:

sudo apt update

sudo apt install build-essential dkms git linux-headers-$(uname -r)

On Fedora:

sudo dnf install gcc make git dkms kernel-devel kernel-headers

On Arch:

sudo pacman -S base-devel git dkms linux-headers

The exact header package must match the running kernel.

Check:

uname -r

Why DKMS Matters

DKMS stands for Dynamic Kernel Module Support.

It automatically rebuilds compatible third-party modules when a new kernel is installed.

Without DKMS, Wi-Fi may work until the next kernel update and then disappear after rebooting.

Check registered modules with:

dkms status

Typical output might look like:

rtl88x2bu/5.x.x, 6.x.x-amd64, x86_64: installed

If a module fails to rebuild, inspect its log under:

/var/lib/dkms/

Search for build logs:

sudo find /var/lib/dkms -name make.log -print

Avoid Blind Installation Scripts

Some driver repositories recommend commands such as:

sudo ./install-driver.sh

An installation script may be legitimate, but review it before running it as root.

Check what it will do:

less install-driver.sh

Look for actions involving:

/etc/modprobe.d
/usr/src
/lib/modules
Secure Boot signing
Blacklisting
DKMS
Automatic downloads
Bootloader configuration

Do not pipe unreviewed internet content directly into a root shell.

Commands such as the following should be treated with extreme caution:

curl example.com/script.sh | sudo bash

Driver Conflicts and Blacklisting

Sometimes Linux loads a generic in-kernel driver that partially supports the adapter but conflicts with the third-party driver you intend to use.

Check loaded modules:

lsmod | grep -iE "rtl|rtw|8812|8821|88x2"

Check which driver is attached:

sudo ethtool -i wlan0

A third-party driver’s documentation may instruct you to blacklist another module.

A blacklist file might look like:

sudo nano /etc/modprobe.d/blacklist-wifi.conf

With a line such as:

blacklist rtl8xxxu

Rebuild the initramfs if required:

sudo update-initramfs -u

or:

sudo dracut --force

Do not blacklist a module merely because a forum post mentions it. Confirm that the module actually conflicts with the driver for your exact chipset.

Secure Boot Can Block Third-Party Drivers

Secure Boot allows the system firmware to reject unsigned kernel modules.

Distribution-supplied modules are normally signed appropriately. A locally compiled third-party driver may not be.

Check Secure Boot status:

mokutil --sb-state

You may see:

SecureBoot enabled

If the driver compiles and installs but refuses to load, inspect the kernel log:

sudo dmesg | grep -iE "secure|signature|verification|module"

Possible messages include:

module verification failed

Required key not available

Safer options include:

Enrolling a Machine Owner Key
Signing the module
Using a distribution-packaged driver
Replacing the adapter with one supported by an in-kernel driver

Disabling Secure Boot may make the module load, but it reduces an important boot-integrity protection. It should not be the automatic fix.

Check the Regulatory Domain

Wi-Fi channel availability and transmit power depend on the country’s radio regulations.

Check the current regulatory domain:

iw reg get

A generic or incorrect domain can cause:

Missing 5 GHz channels
Networks not appearing
Reduced transmit power
Connection instability
Access-point mode failures

Temporarily set the country code:

sudo iw reg set GB

For the United Kingdom, the country code is:

The permanent configuration method depends on the distribution and network stack.

Do not select a false country code merely to unlock channels or increase power. Radio regulations exist to prevent interference with radar, aviation and other licensed systems.

Disable Wi-Fi Power Saving for Testing

Power-saving features can cause disconnections, poor latency or a wireless adapter that fails to wake correctly.

Check the current state:

iw dev

For NetworkManager, you can test with:

sudo iw dev wlp2s0 set power_save off

Replace the interface name as required.

To make the change through NetworkManager, create:

sudo nano /etc/NetworkManager/conf.d/wifi-powersave.conf

Add:

[connection]

wifi.powersave = 2

Restart NetworkManager:

sudo systemctl restart NetworkManager

Use this as a diagnostic step. Disabling power saving can increase battery consumption.

USB Power Management Problems

USB Wi-Fi adapters may disconnect because of USB autosuspend.

Check for USB-related errors:

sudo dmesg | grep -i usb

Look for repeated disconnect and reconnect events:

USB disconnect

new high-speed USB device

device descriptor read error

Test the adapter in:

A different USB port
A USB 2.0 port instead of USB 3.x
A short extension cable
A powered USB hub
Another computer

USB 3.x interference can affect some 2.4 GHz adapters, particularly when the dongle sits close to a poorly shielded port or cable.

Connection Works but Is Unstable

When the adapter connects but drops frequently, collect more information before replacing the driver.

Check signal strength:

iw dev wlp2s0 link

List nearby networks:

nmcli device wifi list

Watch the logs live:

sudo journalctl -fu NetworkManager

Check kernel messages live:

sudo dmesg -w

Possible causes include:

Weak signal
Crowded 2.4 GHz channels
Driver power saving
Router compatibility
WPA3 compatibility
Bluetooth coexistence
USB power problems
Firmware crashes
Access-point band steering
Roaming between mesh nodes

A weak signal or poor router configuration cannot be fixed by repeatedly reinstalling the driver.

WPA3 and Security Compatibility

Some older drivers and firmware versions struggle with WPA3, particularly mixed WPA2/WPA3 transition networks.

As a test, connect to:

A WPA2-only network
A 2.4 GHz network
A 5 GHz network
A mobile hotspot

If one works and another does not, the problem may be compatibility rather than complete driver failure.

Do not permanently weaken business wireless security without understanding the trade-off. Use testing to identify the issue, then update the adapter, driver, firmware or access point.

The Adapter Sees No 5 GHz Networks

Possible causes include:

The adapter supports only 2.4 GHz.
The regulatory domain is wrong.
The router is using an unsupported channel.
The driver or firmware is too old.
The router is using a DFS channel.
The adapter supports 5 GHz but not the selected channel width.
The device is being forced into a restricted mode.

Check adapter capabilities:

iw list

Look for supported bands and frequencies.

The output can be long, so search for:

iw list | less

or:

iw list | grep -A20 -i frequencies

Monitor Mode and Packet Capture

A chipset working for ordinary Wi-Fi does not guarantee that it supports monitor mode or packet injection.

Those capabilities depend on:

The chipset
The driver
The firmware
The kernel version
The specific USB revision

Check supported interface modes:

iw list

Look for:

Supported interface modes:

Possible entries include:

managed

monitor

P2P-client

P2P-GO

Only test networks and devices you own or are explicitly authorised to assess.

Access-Point Mode

If you want Linux to act as a wireless access point, check whether the driver supports AP mode:

iw list

Look for:

An adapter may work perfectly as a client but fail as an access point.

USB adapters advertised as “Linux compatible” do not always support every wireless mode.

Recovering After a Driver Installation Breaks Networking

If an out-of-tree driver leaves the machine without Wi-Fi, boot with another connection method where possible:

Ethernet
USB Ethernet adapter
Phone USB tethering
A working older kernel
Recovery mode
A live Linux USB

Check DKMS:

dkms status

Remove the faulty module using its documented DKMS name and version:

sudo dkms remove module-name/version --all

Remove any blacklist file it created:

sudo rm /etc/modprobe.d/blacklist-wifi.conf

Rebuild the initramfs:

sudo update-initramfs -u

or:

sudo dracut --force

Reboot and allow the original in-kernel driver to load again.

Review the Driver After Kernel Updates

After a kernel update, confirm:

uname -r

dkms status

ip link

If a third-party module did not rebuild, reinstall the matching headers:

sudo apt install linux-headers-$(uname -r)

Then rebuild the DKMS module according to its package or project instructions.

Keep an older working kernel installed until the new kernel and Wi-Fi driver have been tested successfully.

When Replacing the Adapter Is the Best Fix

There comes a point where replacing a troublesome adapter is more sensible than maintaining a fragile third-party driver.

Replacement is worth considering when:

The driver has been abandoned.
Every kernel update breaks Wi-Fi.
Secure Boot must remain disabled.
The adapter regularly crashes under load.
Power management does not work.
The device lacks modern WPA support.
The chipset has poor Linux support.
The adapter is inexpensive and easily replaced.

For desktops and laptops with replaceable Wi-Fi cards, adapters using well-supported Intel chipsets are often a practical option, subject to hardware compatibility.

For USB adapters, confirm the chipset revision before buying. Marketing descriptions such as “Linux supported” may refer only to a vendor driver on an old kernel.

A Practical Diagnostic Order

When Linux Wi-Fi is not working, use this order:

Identify the exact PCI or USB chipset.
Confirm that Linux can see the hardware.
Check the driver currently in use.
Search the kernel log for firmware errors.
Install the distribution’s official firmware packages.
Check rfkill.
Check NetworkManager and interface state.
Install normal kernel and firmware updates.
Test the regulatory domain and power saving.
Investigate USB power or signal problems.
Use an out-of-tree DKMS driver only when necessary.
Check Secure Boot before assuming the driver failed.
Keep a working kernel and recovery connection available.
Replace poorly supported hardware when maintenance becomes excessive.

This order avoids unnecessary driver compilation and starts with the safest fixes.

Common Mistakes

Installing a Driver Based Only on the Product Name

Different hardware revisions may use different chipsets.

Always check the PCI or USB ID.

Assuming Every Realtek Adapter Uses the Same Driver

Realtek produces many unrelated wireless chipsets.

A driver for one family will not necessarily support another.

Downloading Drivers Before Checking Firmware

The in-kernel driver may already be correct and simply waiting for a missing firmware file.

Disabling Secure Boot Without Investigating

The real problem may be an unsigned module. Signing or replacing the driver may be better than weakening boot security.

Running Unreviewed Scripts as Root

Driver installation scripts can change module blacklists, initramfs files and kernel directories.

Review them first.

Forgetting Kernel Headers

A third-party driver cannot compile correctly without headers matching the current kernel.

Removing the Working Kernel

Keep a known-good kernel available until the new driver has been tested.

Blaming the Driver for a Weak Signal

Connection drops can be caused by interference, poor access-point placement or mesh roaming rather than the Linux driver.

Final Thoughts

Difficult Linux Wi-Fi problems become much easier when you stop treating the adapter as a brand-name product and start treating it as a specific chipset.

The most reliable process is to identify the hardware, inspect the kernel logs, install official firmware and update the supported kernel before considering third-party code.

Out-of-tree drivers can make unsupported adapters usable, but they also introduce maintenance, Secure Boot and kernel-update complications. In business environments, a well-supported replacement adapter may be cheaper than repeatedly repairing a fragile driver.

Linux Wi-Fi troubleshooting is ultimately about matching four things correctly:

The exact chipset
The kernel driver
The required firmware
The running kernel version

Once those pieces align, even many difficult adapters can work reliably.

Need Help Getting Linux Wi-Fi Working?

Hamilton Group can help diagnose Linux wireless problems, identify unsupported chipsets, install suitable drivers and firmware, and resolve unstable network connections.

We can also advise on replacement hardware, business Wi-Fi coverage and secure wireless infrastructure when the existing adapter is no longer practical to maintain.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT specialists.