Hardware support on Linux OSs is one of the most "sensitive" topics for new users transitioning from Windows. Troubleshooting can be quite difficult, as most hardware works in a plug-and-play manner on Windows, leading its users to not have any idea about how exactly hardware works even approximately.
I want to make one important point clear from the start: labeling Linux as a badly-done because of some hardware issues you’ve encountered and concluding that Windows is better is a VERY WRONG MINDSET TO START WITH. First of all, Windows is not a free OS. While it’s not crazily expensive for personal use, the costs escalate significantly in enterprise setups. Windows OS is developed and maintained by people, whoa are paid for it, while most Linux OSs are developed and maintained by the community. Please respect their work and remain polite and humble in the discussions — no one guaranteed you that everything will work perfectly out of the box.
Moreover, I want to explain another point: some troubles with Linux hardware support don’t arise because Linux developers are not skilled enough or don’t care. In fact, it’s quite the opposite. The issue with hardware support is that a VERY large share of hardware manufacturers simply don’t care about Linux users. They only ship drivers and firmware for Windows and provide warranties for that platform. For Linux, it's not just that they provide a driver with no warranty—in the most cases, there’s nothing at all. That’s half of the problem. The other half is that their firmware and drivers are often closed-source. It’s one thing to have open-source code that was written for Windows and it is available for everyone in an official Git repository, so Linux devs can just adapt this code for Linux, and another entirely when Linux developers have to reverse-engineer the closed code and then rewrite it for Linux OS.
This article will be dedicated to two problematic devices: Wi-Fi USB sticks and Bluetooth dongles. Support for Wi-Fi and Bluetooth devices is, I think, one of the most discussed topics on forums, Reddit threads, etc., across all Linux distros. I know that laptop touchscreens also cause troubles sometimes, but I don’t have a device with such functionality to write about it. However, what I do have is a Wi-Fi USB stick that doesn’t work out of the box and Bluetooth dongles that also don’t work out of the box.
Returning to the statement above about manufacturers not caring about users, a good example is Realtek. Chances are, you'll have to deal with them, because no matter the brand of your Wi-Fi device, most likely the core of it will be Realtek (chipset). You’re welcome to visit their website and try to download a driver that you need (Spoiler: UX of this site is -1000000/10, and for someone without a solid understanding of hardware, it will seem like reading Arabic—even if the site is in English).
However, I have written this article to shed light on many details related to hardware support on Linux, and I will show you how I get non-functioning Wi-Fi and Bluetooth devices to work with some tweaking.
The main objective of this article is to provide an explanation of logic behind of how hardware works on Linux, not to make something work at all costs, especially if it risks the stability of the system or involves installing questionable packages. There will be none of that in this article.
Here’s the road map for this article:
➀ Hardware Support: The Role of the Linux Kernel vs. Debian OS
➁ Clarifying the Difference Between Firmware and Drivers
➂ Troubleshooting Step #1: How to Identify the Root Cause – Missing Firmware or Missing Driver?
➃ Troubleshooting Step #2: Leveraging Debian repository's components to fetch missing firmware drivers
➄ "Why is it, when something happens, it is always you TWO?" - An Answer.
➅ Troubleshooting Step #3: Fetching missing WiFi drivers: Upgrading Kernel vs Manual installation
➆ Troubleshooting Step #4: Fetching missing Bluetooth firmware from web vs Replacing Bluetooth dongle
➀ Hardware Support: The Role of the Linux Kernel vs. Debian OS
You may have noticed that the title states this article will be about troubleshooting Bluetooth and Wi-Fi devices on Debian, but in the introduction, I spoke about Linux in general. You might wonder why. Debian has unfairly earned the reputation of being an OS that isn’t for beginners, especially regarding the fact that getting some hardware to work always requires tweaking (which is certainly not true starting from Debian 12).
It often takes the heat for the fact that Ubuntu—a Debian-based distro—supports something while Debian does not. People question how this is possible and throw accusations like, "Debian is bad," and so on.
And here’s the crucial point: hardware drivers are NOT THE RESPONSIBILITY OF THE OS in most cases. Hardware drivers are parts of the Linux kernel, and more specifically, they are kernel modules.
However, for the proper functioning of hardware on the OS, not only drivers are needed, but also firmware. Despite the common mixing of terms (when problems related to drivers being reported as missing firmware, and vice versa), Firmware ≠ Drivers!.
➁ Clarifying the Difference Between Firmware and Drivers
Firmware refers to embedded software which controls electronic devices. Well-defined boundaries between firmware and software do not exist, as both terms cover some of the same code. Typically, the term firmware deals with low-level operations in a device, without which the device would be completely non-functional (Source)
The key takeaway about firmware is that without it, hardware is completely non-functional. Without a correct firmware, it’s just a piece of microchip, and no driver will be able to send the correct signal to it. When we’re talking about USB devices—like Bluetooth and Wi-Fi dongles—once connected to USB ports, if the situation with their firmware is very bad, they will be detected as just unknown USB devices. This can happen with improperly produced hardware purchased from no-name brands or from unsuccessful replicas of existing hardware from renowned brands.
Device drivers are available as kernel modules (in most cases).
Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality (Source).
So, now you know that drivers and firmware are not the same thing. The first step in troubleshooting is to understand what exactly the problem is with your non-functioning device—missing firmware or missing driver. Once identified, you can move on to resolving the issue.
➂ Troubleshooting Step #1: How to Identify the Root Cause – Missing Firmware or Missing Driver?
The troublesome devices that you will see in this article (TP-Link Archer T3U Plus WiFi USB Adapter and ASUSTek Broadcom BCM20702A0 Bluetooth dongle) I use solely for the purposes of this article; they are quite dinosauric and were originally purchased without any thought regarding their Linux compatibility. Keep that in mind, as I will elaborate more on this later. The truth is that far from all devices need troubleshooting on Linux—there are plenty of Bluetooth and Wi-Fi USB devices that work in plug-and-play mode, meaning no additional configuration is needed beyond plugging them into the USB port (I will share the lists later on in the article).
The first command that will give me an overview of the plugged-in devices is:
$ lsusb
# I will not be providing the list of full devices attached to my PC, just the 2 that are in question for this article
# Bluetooth dongle:
Bus 001 Device 009: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
# Wi-Fi USB stick
Bus 001 Device 003: ID 2357:0138 TP-Link 802.11ac NIC
How do I know that these devices are not functioning? With the Wi-Fi device, it's easy. When I run a command to list available network interfaces, I do not see a wireless network interface, which should be presented, because previous command demonstrated that my WiFi USB device is not broken, it is attached and identified correctly by Debian.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> .... state UNKNOWN
......
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> ..... state UP .....
I also have Network Manager installed, which handles my wireless network interface. When I try to activate a Wi-Fi connection using nmtui
, I see that the list of available connections is empty:
With Bluetooth dongle, instead, I see a quick log pop up when booting into my Debian—an error related to Bluetooth. These boot logs are usually displayed very quickly, and if they’re not critical for the boot process, your system will boot anyway. However, you can (and should!) always review all the logs if during the booting process you saw some warning/error message. You can do it using the dmesg
command.
$ sudo dmesg #| grep Bluetooth
Here is the log, which is very self-explanatory as to why the Bluetooth dongle does not work properly:
Okay, for the Bluetooth dongle, the first troubleshooting step is done—the problem is with the missing firmware.
However, dmesg
did not give me any error messages regarding the Wi-Fi USB stick. I just see that it was correctly identified (the same output as from lsusb
), so I have to continue with further investigation.
There are two commands that can give you more technical details about your connected USB devices:
$ usb-devices
# Output for Broadcom Bluetooth dongle:
T: Bus=01 Lev=01 Prnt=03 Port=07 Cnt=01 Dev#= 9 Spd=12 MxCh= 0
D: ....
P: Vendor=....
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=5CF37094AE3A
C: ....
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
...
...
...
# Output for TP-Link WiFi USB stick:
T: Bus=01 Lev=01 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: ....
P: Vendor=.....
S: Manufacturer=Realtek
S: Product=802.11ac NIC
S: SerialNumber=123456
C: ....
I: If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
....
....
....
So, the Bluetooth Broadcom dongle has missing firmware, but the driver (Driver=btusb) is loaded for it. Meanwhile, the TP-Link Realtek Wi-Fi Adapter shows Driver=(none), meaning the Wi-Fi USB stick has a missing driver.
$ lsusb -v
#outputs of this command are quite long for each USB device
# output for TP-Link Wi-Fi USB stick:
Bus 001 Device 003: ID 2357:0138 TP-Link 802.11ac NIC
Couldn't open device, some information will be missing
idVendor 0x2357 TP-Link
idProduct 0x0138
iManufacturer 1 Realtek
iProduct 2 802.11ac NIC
#output for Broadcom Bluetooth:
Bus 001 Device 009: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
Couldn't open device, some information will be missing
idVendor 0x0b05 ASUSTek Computer, Inc.
idProduct 0x17cb Broadcom BCM20702A0 Bluetooth
iManufacturer 1 Broadcom Corp
iProduct 2 BCM20702A0
From the lsusb -v
, I also pasted details about the product ID, vendor, and manufacturer, as this information is very important for later if none of the other methods work and I have to manually search for a driver for the Wi-Fi and firmware for the Bluetooth.
However, before rushing into digging the internet for manually fetching drivers and firmware—which is the least optimal solution, as it is not the "Debian way" at all and could break your system or create a security breach if the driver/firmware is acquired from a "questionable" source—it's important to consider alternatives. If you're not familiar with the "Debian way" of administering your system and don't understand the risks of breaking your system, I advise you to read this article. For security-related threats when installing anything on your system, you can read this.
However, Debian offers a reliable potential solution for missing firmware and drivers directly from the Debian package repositories!
➃ Troubleshooting Step #2: Leveraging Debian repository's components to fetch missing firmware drivers
Before we start with this troubleshooting step, I want to make it clear where firmware and Linux drivers come from to your OS. Let’s start with firmware.
Historically, firmware would be built into the device's ROM or Flash memory, but more and more often, a firmware image has to be loaded into the device RAM by a device driver during device initialization. (Source)
The problem is, as I mentioned before, that many hardware manufacturers target ONLY Windows users, so the firmware shipped together with the drivers will be for Windows. And Linux users?
Free software based systems such as Debian depend on the cooperation between manufacturers and developers to produce and maintain quality drivers and firmware. Drivers and firmware are what determine if, and how well, your hardware works.
Non-free drivers and firmware are produced by entities refusing or unable to cooperate with the free software community. With non-free drivers and firmware support is often unavailable or severely constrained. For instance features are often left out, bugs go unfixed, and what support does exist from the manufacture may be fleeting.
Most of the firmware comes bundled with the Linux kernel in Linux distros. And often we have to praise the brilliant minds of Linux/Debain developers, when manufacturers refuse to cooperate. However, firmware can end up in your system not only as a part of Linux Kernel. This brings us back to Debian and its package repositories.
What about drivers? Well, it's the similar scenario:
Most of WWAN and WLAN dongles (USB devices) have their proprietary Windows drivers onboard. When plugged in for the first time, they act like a flash storage and start installing the Windows driver from there. If the driver is installed, it makes the storage device disappear and a new device, mainly composite (e.g. with modem ports), shows up (Source).
As I mentioned before, drivers are, in most cases, shipped with the Linux kernel. Device drivers are kernel modules, which are essentially reworked and adapted Windows drivers for the Linux kernel, in cases where the manufacturer didn't bother releasing drivers for Linux.
When you install Debian, it comes with the Linux kernel, which is actually a large package (and indeed it is handled as a package on your Debian) called linux-image-*
(in my case, for example, linux-image-amd64
). This package is fetched from the Debian repository, not from the Linux upstream. That's why the kernel version may vary. For instance, Debian Bookworm stable comes with kernel version 6.1.x, while the current latest release of the Linux kernel is 6.13. The Linux kernel package on Debian comes with many built-in kernel modules (drivers) that serve most of your hardware. Generally, if the Linux kernel doesn't have a kernel module (device driver) for a particular hardware device, Debian won't have it either. However, keep in mind the kernel version. The most accurate way to say the previous phrase would be that if the Linux kernel of version 6.1.x doesn't have some drivers, Debian Stable will not have them either. If you don’t understand why Debian won’t just upgrade the kernel to the latest version, then I recommend reading this article to better understand the Debian distro.
However, there are exceptions, and Debian doesn't always lack drivers that the Linux kernel doesn't have. A famous example is the Nvidia driver. It’s a proprietary driver for Nvidia GPUs that can be installed from the Debian repository, while the Linux kernel only offers the open-source Nouveau driver for Nvidia graphics cards. Another example is iwlwifi.
So, let's start with first attempt of troubleshooting. The probability of getting a kernel module-driver for my Realtek Wi-Fi USB from any Debian repository component is quite low— iwlwifi
, mentioned earlier, is for Intel Wi-Fi adapters, not Realtek. However, the missing firmware can be fetched with a much higher chance!
Troubleshooting Step #2: execution
Debian, as a distro, has more than one package repository from which it can install and update packages and software. If you don’t understand what a package repository is and which repositories Debian has, I strongly recommend this article and this article. Debian has one main repository for each of its releases, and this repository also has repository components, one of which is specifically called non-free-firmware
. The term "non-free" doesn’t mean you have to pay someone somewhere to use the software from there. It means that this component contains proprietary, closed-source software that has been carefully analyzed and rewritten for Debian OS to function well and harmoniously with the rest of the system, ensuring maximum possible support for various hardware devices.
Here is the list of repository components:
main consists of DFSG-compliant packages, which do not rely on software outside this area to operate. These are the only packages considered part of the Debian distribution.
contrib packages contain DFSG-compliant software, but have dependencies not in main (possibly packaged for Debian in non-free).
non-free contains software that does not comply with the DFSG.
non-free-firmware provides firmware that is needed by some hardware, but does not comply with the DFSG.(SourcesList — Debian Wiki).
So, the troubleshooting is very simple—you just have to ensure that apt
can fetch packages from these repository components. To do so, you'll probably need to modify the list of sources for apt
. Just to remind you, I am using the Debian Stable release, not Sid or Trixie.
$ cat /etc/apt/sources.list
# this is what I have:
#first, main repository of Debian stable
deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware
#repository for security updates
deb http://security.debian.org/debian-security bookworm-security main non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main non-free-firmware
# repository bookworm-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian/ bookworm-updates main non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main non-free-firmware
What you need to look at is the first line, related to the main repository of your Debian release. If it, for some reason, only has the main
component and contrib
, you will need to add non-free
and non-free-firmware
: deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
.
After modifying sources.list
, you'll need to run sudo apt update
so that apt
becomes aware of the updated sources list.
After this, I run:
$ sudo apt install firmware-misc-nonfree
#for double check:
$ sudo apt install firmware-realtek
The firmware-misc-nonfree
package will bring this firmware. I can see the following files:
/lib/firmware/brcm/BCM-0a5c-6410.hcd
/lib/firmware/brcm/BCM-0bb4-0306.hcd
However, what the Broadcom Bluetooth dongle was looking for was a different version of firmware: BCM-0b05-17cb.hcd
.
To inspect which firmware is on your OS, you just can inspect the contents of /lib/firmware
. If I go into the subfolder /lib/firmware/brcm
, I can see the existing firmware. In my case, However, none of them matches the firmware version that appeared in the dmesg
error.
If you want to take a look at the existing device drivers, they are in a different location - /lib/modules/$(uname -r)/kernel/drivers/
. uname -r
command will show you the version of kernel in use by your Debian. You can find more than one kernel version in /lib/modules
if you regularly update your System and Kernel.
Bluetooth drivers can be found in /lib/modules/$(uname -r)/kernel/drivers/bluetooth.
Available Realtek Wi-Fi drivers are in /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtlwifi/
Anyway, the problem with both my troublesome devices still persists. There are Realtek drivers, but it seems none of them is suitable for my Realtek Wi-Fi device, and the same goes for the firmware for my Bluetooth dongle. So, I have to continue troubleshooting. As I mentioned earlier, what’s left for me is to fetch the driver and firmware from somewhere outside of Debian repositories.
Before proceeding with the last-resort troubleshooting solution, I want to remind you of what I said about these devices. They were acquired without any thought of their compatibility with Linux, and that’s where the problem starts. It’s not that Debian is a bad OS or Linux is a bad system—it’s just that both the manufacturer AND vendor of BOTH devices don’t care about Linux users. However, not all devices are like this on Linux OSs. I’m not saying that there are MANY other manufacturers that are better at supporting Linux (Broadcom and Realtek are very big players on the market of hardware, so the chances are high, that many pieces you buy, will be manufactured by them), but rather that MANY their devices already have drivers and firmware provided by Linux software engineers, just you were unlucky to get devices that are unsupported YET or ALREADY. Not many still, but there are also manufacturers that genuinely care about Linux users, and I believe they deserve your attention when you are about to buy a new hardware device.
The following section will be dedicated to existing Wi-Fi and Bluetooth devices that can work on Linux as plug-and-play. The reason you're reading this article is that your devices are not one of them, and most likely, you didn’t know how to choose the right devices when you bought them. It’s important to understand what exactly the support for a piece of hardware on Linux depends on (spoiler: NOT A BRAND/MODEL NAME).
➄ "Why is it, when something happens, it is always you TWO?" - An Answer.
Why exactly can Bluetooth and Wi-Fi hardware together cause some troubles? Do they have something in common? YES. If you didn’t know, Bluetooth is nothing else but a network—small, but still a network—a PAN (personal area network):
Bluetooth is a short-range wireless technology standard that is used for exchanging data between fixed and mobile devices over short distances and building personal area networks (PANs) (Source)
When you have a laptop, you have much less control over its hardware components compared to a PC (desktop setup), especially if you’ve built it yourself by selecting and assembling each part.
In terms of Wi-Fi and Bluetooth, it’s common to go for Bluetooth dongles or USB Wi-Fi sticks with antennas, or even dongles for Wi-Fi. But why are Wi-Fi cards so often overlooked and forgotten? These cards are essentially PCIe devices—in other words, just cards you attach to your motherboard.
Sure, they occupy a PCIe slot, which can be seen as a drawback. However, dongles occupy USB slots, and Wi-Fi PCIe cards don’t take up the precious PCIe slot reserved for your fancy GPU. Despite this, they’re still often avoided.
I bring this up because network cards highlight why Wi-Fi and Bluetooth issues often go hand in hand. If you look up network cards, you’ll find that most of them are "2-in-1" devices—combining both Wi-Fi and Bluetooth functionality.
Why Wi-Fi PCIe cards are often bundled with Bluetooth?
The primary reason is shared chipsets. Wi-Fi and Bluetooth are frequently integrated into a single chipset because both technologies use similar radio frequency (RF) components and they operate in the 2.4 GHz band. Combining them on a single card eliminates the need to duplicate components. Both Wi-Fi and Bluetooth require antennas to transmit and receive signals. By bundling the two, the same antenna(s) can often serve both purposes, reducing hardware requirements and saving space.
So, is a network PCIe card the panacea for all problems related to the lack of support for Bluetooth or Wi-Fi on Debian? NO. If you look at the image above, you’ll notice the antennas, metallic parts, and that green microcircuit board... that’s the guy! Whether it works out-of-the-box when attached to your motherboard, or requires extensive tweaking (and possibly still doesn’t work), depends entirely on it.
In the image above, the green microcircuit board belongs to Intel and is labeled with the model AX210. The crucial point is that whether a Wi-Fi or Bluetooth device works on Debian depends entirely on the available software support (drivers and firmware) for the chipsets used in those devices.
Please read the information from Debian developers, that I quoted below. You will most likely be confused by all the combinations of numbers and letters that are chipset names, but I will untangle it for you using the example of my Wi-Fi USB device later on in this article!
A WiFi device operates on an electronic chip called a "chipset". We can find the same chipset in several different devices. Consequently, the driver/module for one chipset will work for all wireless devices using that chipset.
Currently there are only a few modern wifi chipsets readily available that work with free software systems. For USB wifi devices this list includes the Realtek RTL8187B chipset (802.11G) and the Atheros AR9170 chipset (802.11N). For Mini PCIe all cards with an Atheros chipset are supported.
Wifi has always been a problem for free software users. USB Wifi cards are becoming less free. With the older 802.11G standard many USB wifi cards had free drivers and did not require non-free firmware. With 802.11N there are only a couple chipsets on the market, from Atheros, which are completely free.
One company which specializes in free software and sells 802.11N USB wifi cards, ThinkPenguin.com, has indicated the availability of free software supported 802.11N USB wifi cards is disappearing. Solving this problem will require more demand than currently exists. Next time you purchase a piece of hardware ask yourself if it is free software compatible. (Debian Wiki: WiFi)
Now that you are fully equipped with the theory behind hardware support on Linux/Debian, I will proceed with troubleshooting my USB Wi-Fi adapter.
➅ Troubleshooting Step #3: Fetching missing WiFi drivers: Upgrading Kernel vs Manual installation
I hope it’s clear now that there is no "safe for Linux" brand or manufacturer from which you can buy hardware—specifically Wi-Fi adapters—that will just work when you plug it in on Debian because it is THAT brand and THAT manufacturer. The quote I shared above may be confusing because it talks about chipsets with some alphanumerical names.
The support on Debian depending on the chipset makes it more complicated to choose the correct Wi-Fi device if you’re planning to buy one with the goal of making it work seamlessly on your Debian system. However, it’s not that bad. Remember, in the world of Linux, you always have a community that has your back.
Identifying the chipset and it's driver
What information do I have for now about my Wi-Fi USB adapter?
These are the details about my devices that I extracted with lsusb -v
:
Device: ID 2357:0138 TP-Link 802.11ac NIC
idVendor 0x2357 TP-Link
idProduct 0x0138
iManufacturer 1 Realtek
iProduct 2 802.11ac NIC
Here’s the cornerstone—not all devices from the brand TP-Link are unsupported by Debian. It depends on the manufacturer of the chipset used in the TP-Link device, which in my case is Realtek. Not all Wi-Fi devices manufactured by Realtek will work seamlessly on Debian, because it depends on the specific chipset used. For my Wi-Fi adapter, it is known which wireless standards the chipset uses: it is 802.11ac. But chipset name still remains unknown.
That’s all. Oh, actually, look at the device ID numbers—they are meaningful, especially 0138, which is the product ID. I could technically find this on the web, specifically on the TP-Link site, as I definitely know the vendor.
However, I know the exact model of my Wi-Fi adapter—it is written on the metallic part of the USB stick, burned there, so I know it’s the TP-Link Archer T3U Plus.
Maybe, if you don’t recall the model name of your device that’s causing you problems and there’s no way to retrieve it, and you don’t have it written anywhere... well, you can try searching by the vendor ID and product ID first here and also here.
My Wi-Fi adapter is absent in both links—ID 0138 is not present. Indeed, there is an Archer T3U listed in the first link, but not the Plus version..
However, let’s look at the example of the Archer T3U first link:
012d Archer T3U [Realtek RTL8812BU]
The first part of this troubleshooting step is to find exactly this info—RTL8812BU. Does it remind you of something? No? Here’s a refresher:
$ ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtlwifi/
#this is the output of this command, that list all available drivers on my Debian
btcoexist rtl8192c rtl8192cu rtl8192ee rtl8723ae rtl8723com rtl_pci.ko rtlwifi.ko
rtl8188ee rtl8192ce rtl8192de rtl8192se rtl8723be rtl8821ae rtl_usb.ko
And none of these present drivers fits my Wi-Fi Adapter! So, what do I need, and why don’t they fit?
Let’s start with the first one: rtl8192cu.
Running sudo modinfo rtl8192cu
will show me the details about which device this driver is suitable for.
The key thing that is important for my troubleshooting—and actually gives a hint as to why this driver is not suitable for my device—is this line:
description: Realtek 8192C/8188C 802.11n USB wireless
My Wi-Fi adapter uses 802.11ac wireless standard. For more details, check here: IEEE 802.11ac on Wikipedia.
I can enrich modinfo
output by checking the Realtek website, specifically the page dedicated to Wi-Fi device chipsets (there is also a page for combined Wi-Fi and Bluetooth). Here’s the link: Realtek Wi-Fi Chipsets.
Why rtl8192cu is not my Wi-Fi adapter's chipset based on the Realtek description?
General Description:
The Realtek RTL8811CU-CG is a highly integrated single-chip that supports 1-stream 802.11ac, bla bla bla...
I know that my Wi-Fi adapter supports 2 streams.
Host interface:
USB 2.0 for WLAN and BT controller.
I know that my Wi-Fi adapter uses USB 3.0.
So, I can continue exploring the Realtek list of chipsets. There’s no need to examine other existing drivers with modinfo
because they definitely won’t fit.
I could say that I examined the Realtek list of chipsets and matched the parameters, hehe. Actually, I did out of curiosity, but in reality, I just Googled my model to find which drivers I need. However, the Realtek information card for this chipset looks exactly like the one in my Wi-Fi adapter.
So, to make my Wi-Fi adapter work I need the rtl8812bu driver, and it is definitely currently missing on my Debian. Don’t worry if your device is more complicated and you find it difficult to figure out which driver you need, I have an amazing GitHub repository for you, which can be considered as a bible of a Wi-Fi adapters support on Linux.
I strongly recommend to check USB WiFi Adapter Information for Linux and USB WiFi adapters that are supported with Linux in-kernel drivers and USB WiFi adapters with Linux out-of-kernel drivers.
I started with USB WiFi adapters with Linux out-of-kernel drivers since my current Debian kernel definitely does not have the driver I need—rtl8812bu. However, I found some interesting information on this link:
chipsets - rtl8812bu and rtl8822bu - AC1200 - USB 3
As of kernel 6.2, the above chipsets have an in-kernel driver. It is located in the rtw88 in-kernel driver. I invite all to test the new in-kernel driver and use it if it meets your needs.
I know that my kernel version is inferior to this, however here is the preciese info:
$ uname -r
6.1.0-28-amd64
Troubleshooting Step #3: implementation
So, here is where the troubleshooting starts—I have two choices:
upgrade the kernel
install the kernel module manually using the code kindly provided by the gentleman who maintains this Wi-Fi adapters compatibility "bible": Linux Driver for USB WiFi Adapters that use the RTL8812BU and RTL8822BU Chipsets.
I will use both methods just for the purpose of this article.
Personally, I would go for a kernel upgrade, and I do this on my personal setup. However, the issue is that Debian Stable ships with kernel 6.1.x, so I actually have the maximum version available from the Debian stable main package repository. The unique, quite safe way to update the kernel is using Debian backports. If you don’t know what that is, you can read this article.
What are the risks of this method (you may also face them)? I have NVIDIA drivers installed. They are installed from the Debian stable repo. Nvidia drivers require kernel headers, the version of which should match the kernel version. So, I will have to upgrade those from the backports as well. Additionally, MAYBE I will need to reinstall the Nvidia driver from the Debian backports repository. (If all of this doesn’t make sense to you and you don’t understand what I’m talking about, I recommend you read this article.
The second option is manual installation. What are the drawbacks? I don’t like this method because it’s less the Debian way, and that’s all. Want to know my policy on it? I’d rather buy a new, compatible plug-and-play Wi-Fi USB adapter—or actually, not even that, but a PCIe network card. For me, it’s not worth installing a kernel module manually and potentially destabilizing my system, even slightly. But this is just my point of view. I’ll let you decide, as I will show you both examples. Please note, my concerns are not related to the developer/maintainer of driver I will be manually installing, he is doing a tremendously great job, it is just me, I manage my system in a particular way. By the way, I use a snapshotting tool, so I can try both. If you don’t know anything about snapshotting, I recommend this article. Using snapshot tool can make the procedure of troubleshooting much less problematic.
Method 1: upgrading kernel version from bookworm-backports repo
I start with a kernel upgrade from Bookworm backports.
The first thing to do is to make sure that the Bookworm backports repo is enabled and accessible for your apt
to fetch packages:
$ sudo vim /etc/apt/sources.list
#append these lines:
#bookworm-backports
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free
$ sudo apt update
If you're worried that Debian will now update everything from there when you run sudo apt update
, don’t worry—it won’t do this unless you explicitly ask for it.
Next, I search for the available kernel versions in the bookworm-backports repo:
$ apt search linux-image*
# I cannot install linux kernel 6.2, the minimum version available is 6.9, I am fine with it
linux-image-6.9.7+bpo-amd64/stable-backports 6.9.7-1~bpo12+1 amd64
Linux 6.9 for 64-bit PCs (signed)
$ sudo apt install -t bookworm-backports linux-image-6.9.7+bpo-amd64
#if you want to fetch the latest available version from bookworm-backports use
# sudo apt install -t bookworm-backports linux-image-amd64
#immediately after I install Linux headers as well
$ sudo apt install -t bookworm-backports linux-headers-6.9.10+bpo-amd64
$ sudo reboot
During the installation of the kernel headers, I got these messages on logs:
dkms: running auto installation service for kernel 6.9.10+bpo-amd64.
Sign command: /lib/modules/6.9.10+bpo-amd64/build/scripts/sign-file
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der
nvidia-current.ko.xz:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/6.9.10+bpo-amd64/updates/dkms/
nvidia-...................
.....
DKMS is rebuilding the NVIDIA kernel modules, which was triggered by the kernel upgrade. That’s quite good and convenient—it seems that I don’t need to reinstall the NVIDIA drivers. Moreover, DKMS is rebuilding the NVIDIA kernel modules signing them after for UEFI Secure Boot, because I have it enabled on my machine, and everything is going as configured. If you also use Secure Boot on your PC but have only a vague idea about it, I recommend reading this article.
The first thing I do after rebooting is run sudo apt autoremove
to remove the old kernel packages.
The NVIDIA drivers are in place, as I can see from the nvidia-smi
output. uname -r
displays expected version of kernel in use.
I use sudo nmtui
to activate Wi-Fi connection, and this time I have the complete list of detected Wi-Fi networks.
Let’s check if the wireless interface is present in the list of network interfaces and is UP.
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> ...state UNKNOWN ...
.....
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> .... state UP ....
....
3: wlx984827dd37bb: <NO-CARRIER,BROADCAST,MULTICAST,UP> ...state UP ...
Voila!
Additional commands to control drivers in use:
$ usb-devices
T: Bus=01 Lev=01 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=2357 ProdID=0138 Rev=02.10
S: Manufacturer=Realtek
S: Product=802.11ac NIC
S: SerialNumber=123456
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw_8822bu
....
$ ls /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek/rtw88
rtw88_8723de.ko.xz rtw88_8821c.ko.xz rtw88_8822b.ko.xz rtw88_8822c.ko.xz rtw88_pci.ko.xz
rtw88_8723d.ko.xz rtw88_8821cs.ko.xz rtw88_8822bs.ko.xz rtw88_8822cs.ko.xz rtw88_sdio.ko.xz
rtw88_8723du.ko.xz rtw88_8821cu.ko.xz rtw88_8822bu.ko.xz rtw88_8822cu.ko.xz rtw88_usb.ko.xz
rtw88_8821ce.ko.xz rtw88_8822be.ko.xz rtw88_8822ce.ko.xz rtw88_core.ko.xz
Manual installation/building of Realtek driver.
So far, I am satisfied. I have a well-configured system, my NVIDIA drivers were built with DKMS, and I also have Secure Boot enabled and configured on my system. Actually, if your Debian setup wasn’t configured as well and precisely, some things could go wrong—especially with the NVIDIA drivers. That’s why I will also show another method for manually installing the driver for Realtek as an alternative without doing anything with your system's kernel version.
I am precisely following this guide:
$ sudo apt update
$ sudo apt upgrade
# First, my Debian should have installed some packages. (actually, this is what i do not like about manual installation of drivers, it is not installation but rather building, so it requires to have a lot of software to be installed for building
Mandatory packages:
gcc make bc kernel-headers build-essential git
Highly recommended packages:dkms rfkill iw ip
$ sudo apt install -y linux-headers-$(uname -r) build-essential bc dkms git libelf-dev rfkill iw
# in my case it will install this
#The following NEW packages will be installed:
#bc git git-man iw libelf-dev liberror-perl rfkill zlib1g-dev
# Create a directory to hold the downloaded driver
mkdir -p ~/src
# Move to the newly created directory
cd ~/src
# Download the driver
git clone https://github.com/morrownr/88x2bu-20210702.git
# Move to the newly created driver directory
cd ~/src/88x2bu-20210702
# Run the installation script (install-driver.sh)
sudo sh install-driver.sh
# When I was prompted to edit the config, I chose "no" and then I chose "yes" to reboot.
After rebooting, the results are exactly the same as the first method's ones, so I will not repeat the proves.
The problem with Wi-Fi USB Adapter is resolved. The one that is left is with the Bluetooth Broadcom device.
➆ Troubleshooting Step #4: Fetching missing Bluetooth firmware vs Replacing Bluetooth dongle
I’ll start again by analyzing what I have on my device (output of lsusb -v).
Bus 001 Device 009: ID 0b05:17cb ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth
idVendor 0x0b05 ASUSTek Computer, Inc.
idProduct 0x17cb Broadcom BCM20702A0 Bluetooth
iManufacturer 1 Broadcom Corp
iProduct 2 BCM20702A0
I checked the details about my Bluetooth device by ID on the previously shared link:
This time, my device is present:
17cb Broadcom BCM20702A0 Bluetooth
But this time, I do not need a driver; I need firmware. Again, I turn to community support, as the Debian repository component non-free-firmware
could not provide the required Bluetooth Broadcom firmware.
The firmware that dmesg
reported my Bluetooth dongle is searching for is BCM-0b05-17cb.hcd
. Here is the GitHub repository from where I can get it.
Will I install the firmware from there? No. Is it because I don’t trust the maintainer? No. It’s because I don’t trust the old firmware from Broadcom. Why? Because the repository maintainer generously shared this information:
Recently several vulnerabilities have been discovered in the Bluetooth stack such as CVE-2018-5383, CVE-2019-9506 (KNOB), CVE-2020-10135 (BIAS) and more. Since Broadcom has stopped active support for its consumer devices, your system may be subject to security risks. You will have to use these devices at your own risk. As a repository maintainer, I cannot provide security fixes.(Source)
Am I sure that the firmware my Bluetooth dongle is seeking is not suffering from reported vulnerabilities? I can’t know for sure. But knowing that this dongle is quite dinosauric, the chances are that it could be. So, the solution I see for me is to replace it with another Bluetooth dongle.
My alternative Bluetooth dongle was purchased recently and works perfectly on Debian—truly plug and play. There’s no need for configuration, installation of drivers/firmware, or any tweaks; it just works. This Bluetooth dongle is from the brand Edimax, purchased on Amazon for around $10 (Edimax BT-8500). It supports the Bluetooth 5.0 protocol.
Here are the outputs of the commands:
$ lsusb
Bus 001 Device 009: ID 7392:c611 Edimax Technology Co., Ltd Edimax Bluetooth Adapter
$ sudo dmesg
1178.132034] Bluetooth: hci1: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761
[ 1178.133013] Bluetooth: hci1: RTL: rom_version status=0 version=1
[ 1178.133024] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_fw.bin
[ 1178.144494] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_config.bin
[ 1178.202622] Bluetooth: hci1: RTL: cfg_sz 6, total sz 27814
[ 1178.342160] Bluetooth: hci1: RTL: fw version 0x09a98a6b
Even if it may seem unpleasant to you that I opted for such a solution, that is my choice. I would never compromise my system just to make a device, priced no more than $20, work. However, I’ve shared the GitHub repo, and if you have the same devices, you are free to use it at your own risk.
I’ve achieved the objective of this article: I resolved the problems with my troublesome hardware - Bluetooth Dongle and Wi-Fi USB adapter. The notable solution was with the Broadcom Bluetooth issue. Really, no such inexpensive devices are worth compromising your system for. If your Wi-Fi and Bluetooth hardware pieces are very hard to troubleshoot, just consider replacing them. I’ve shared links, and I will repeat them here. Always remember, if you can, support vendors that care about Linux users, even if sometimes they are a bit overpriced.
Feel free to ask the questions on Reddit, and feel free to share with Linux community any Wi-Fi & Bluetooth device that worked seamlessly on your Debian/Linux setup!
Top comments (0)