If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.
So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.
Plug and Pray
The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.
The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.
Internet to the Rescue?
My first attempt to install a Realtek driver from GitHub failed because it was for what turned out to be the wrong chipset. But I did find info that the adapter had an RTL8832CU chip inside. Armed with that nugget, I found [morrownr] had several versions, and I picked up the latest one.
Problem solved? Turns out, no. I should have read the documentation, but, of course, I didn’t. So after going through the build, I still had a dead dongle with no driver or blinking lights.
Then I decided to read the file in the repository that tells you what USB IDs the driver supports. According to that file, the code matches several Realtek IDs, an MSI device, one from Sihai Lianzong, and three from TP-Link. All of the TP-Link devices use the 35B2 vendor ID, and the last two of those use device IDs of 0101 and 0102.
Suspiciously, my dongle uses 0103 but with a vendor ID of 37AD. Still, it seemed like it would be worth a shot. I did a recursive grep for 0x0102 and found a table that sets the USB IDs in os_dep/linux/usb_intf.c.
Of course, since I had already installed the driver, I had to change the dkms source, not the download from GitHub. That was, on my system, in /usr/src/rtl8852cu-v1.19.22-103/os_dep/linux/usb_intf.c. I copied the 0x0102 line and changed both IDs so there was now a 0x0103 line, too:
{USB_DEVICE_AND_INTERFACE_INFO(0x37ad, 0x0103, 0xff, 0xff, 0xff), .driver_info = RTL8852C},
/* TP-Link Archer TX50U */
Now it was a simple matter of asking dkms to rebuild and reinstall the driver. Blinking lights were a good sign and, in fact, it worked and worked well.
DKMS
If you haven’t used DKMS much, it is a reasonable system that can rebuild drivers for specific Linux kernels. It basically copies each driver and version to a directory (usually /usr/src) and then has ways to build them against your kernel’s symbols and produce loadable modules.
The system also maintains a build/install state database in /var/lib. A module is “added” to DKMS, then “built” for one or more kernels, and finally “installed” into the corresponding location for use by that kernel. When a new kernel appears, DKMS detects the event — usually via package manager hooks or distribution-specific kernel install triggers — and automatically rebuilds registered modules against the new kernel headers. The system tracks which module versions are associated with which kernels, allowing parallel kernel installations without conflicts. This separation of source registration from per-kernel builds is what allows DKMS to scale cleanly across multiple kernel versions.
If you didn’t use DKMS, you’d have to manually rebuild kernel modules every time you did a kernel update. That would be very inconvenient for things that are important, like video drivers for example.
Of course, not everything is rosy. The NVidia drivers, for example, often depend on something that is prone to change in future Linux kernels. So one day, you get a kernel update, reboot, and you have no screen. DKMS is the first place to check. You’ll probably find it has some errors when building the graphics drivers.
Your choices are to look for a new driver, see if you can patch the old driver, or roll back to a previous working kernel. Sometimes the changes are almost trivial like when an API changes names. Sometimes they are massive changes and you really do want to wait for the next release. So while DKMS helps, it doesn’t solve all problems all the time.
Extras and Thoughts
I skipped over the part of turning off secure boot because I was too lazy to add a signing key to my BIOS. I’ll probably go back and do that later. Probably.
You have to wonder why this is so hard. There is already a way to pass the module options. It seems like you might as well let a user jam a USB ID in. Sure, that wouldn’t have helped for the enumeration case, but it would have been perfectly fine to me if I had just had to put a modprobe or insmod with a parameter to make the card work. Even though I’m set up for rebuilding kernel modules and kernels, many people aren’t, and it seems silly to force them to recompile for a minor change like this.
Of course, another fun answer would be to have vendors actually support their devices for Linux. Wouldn’t that be nice?
You could write your own drivers if you have sufficient documentation or the desire to reverse-engineer the Windows drivers. But it can take a long time. User-space drivers are a little less scary, and some people like using Rust.
What’s your Linux hardware driver nightmare story? We know you have one. Let us hear about it in the comments.
Great article Al! We’ve probably all had to dig around for old dongles that worked in Vista or XP to verify a network connection was possible before digging further… Also used to have to worry about drivers for the built-in keys on laptops that can leave the internal network card disabled… Between that and the hdajackretask (iirc) method of rearranging the audio ports and default states to correct the port assignments, etc, there’s always something to tinker with!
Realtek always has been difficult on Linux and more recently they took a page from ye old USB Modems guidebook: ModeSwitch, basically, your USB dongle has an identity crisis, it’s either a mass storage device or a networking interface. At least in the old days you could force one mode using AT commands
My current driver issue? Google Coral TPU via PCI-E.
Google has an install guide for it but everything it depends on is so out of date that you can’t follow it. Here I was thinking that Google would be avid users of Linux…
Saving grace was finding the gasket-dkms repo on Github.
I thought that GH user looked familiar. I wound up testing – successfully, I might add – his rtw88 driver for an old usb dongle connected to a risc-v board I have here. It works quite well, whereas some other old, long-stable drivers in the kernel for older hw fell over when presented with the risc-v arch.
I got a realtek pcie card working in linux once. It entailed digging forums and running a random sh script with my fingers crossed, and it actually worked. I dont dongle anymore, SS USB 3.0 13mbps is far superior to those tiny things.
There is actually an established method for adding IDs to a driver after load. This snippet adds the DLink DWM-222A USB VID:PID to the Option driver, so that it will bind when inserted:
echo “2001 7e3d” > /sys/bus/usb-serial/drivers/option1/new_id
There is probably an equivalent for the Realtek driver as well that could save you from having to recompile it.
A slightly more direct path that excludes having to figure out what sort of device it is (using an actual network driver as an example):
$ ls -l /sys/bus/usb/drivers/rtw_8821au/
total 0
–w——- 1 root root 4096 Mar 5 10:11 bind
lrwxrwxrwx 1 root root 0 Mar 5 10:11 module -> ../../../../module/rtw_8821au
-rw-r–r– 1 root root 4096 Mar 5 10:11 new_id
-rw-r–r– 1 root root 4096 Mar 5 10:11 remove_id
–w——- 1 root root 4096 Mar 5 10:11 uevent
–w——- 1 root root 4096 Mar 5 10:11 unbind
I had to make usb modem working on linux embedded in consumer appliance for one client. We got a batch of a hundred of the cheapest lte modem. After many tries, it worked somewhat reliably. Then the client ordered another hundred after several months. We ordered some new modems and it turns out that despite being exactly the same model on label, those modems used entirely new chip and I had to make a new configuration because that modem worked entirely different. Then we had third batch of the same modem and of course this one worked in entirely different way using different driver and required configuring in entirely different way (and of course even dedicated windows app couldn’t get signal strength from this one). Now I hate usb cellular modems.
I think it would be fair to say that you hate the cheapest LTE modems :-)
And the best thing (at least from customers perspective) is that you got paid at best 1/30th of what they’d have to pay engineer in Germany, UK, France, Canada or United States for doing exact same job. Capitalism baby!
If they had to actually pay that much, the project wouldn’t be done at all and some old people would not have their homes secured against gas leaks and fire. Sometimes you have to take pay cut to work on interesting projects. Besides, for my region I earn in the top end anyway and I have enough money as is :)
2026 is definitely the year of the Linux desktop!
D-e-f-i-n-i-t-e-l-y !
In the words of Jensen : “It just works!”
So you finally you’ve set up rtl8852 driver to work with rtl8832 chip, right? 🤔
My laptop runs Fedora Silverblue. So, if I buy any NEW-ISH device to connect to my laptop, the description must explicitly say, “Linux compatible.” Seems almost too simple, but it’s actually works quite well for me.
Generally speaking, any OLD-ISH device will be Linux compatible by now.
Obviously, simply looking for a “good bargain” is buying strategy that only works for MS Windows.
TL;DR
Long ago in the WinXP days I remember it opposite… I was given a box full of discarded assorted computer stuff. It included a teal USB stick like a USB drive, but with 2 LEDs and a label with a MAC address (no vendor information let alone model number).
So not knowing that there’s a tab in device manager where you can get the entire devuid/vendor ID (I still haven’t checked if WinXP even has that feature), all I could have gotten was the vendor by the first digits of the MAC address (which back then I didn’t know either).
So on WinXP, you would have to google for a driver, but without even knowing what to google for, tough luck.
I plugged the stick into my Ubuntu workstation and it just worked. I still don’t know make or model (because I don’t care as in Linux it just works).
My experience is that unless it’s a graphics card, pretty much any device just works with Linux (and graphics cards work, albeit often without or with poor acceleration). Except… I have two Canon LIDE scanners that look very similar, both have been paperweighted by Windows 10 a couple of years ago. One works in Linux, the other doesn’t. (although my main scanner is an ancient Agfa that only works with a proprietary Win98 app that barely still works in WinXP. In Ubuntu, that thing works native.)
And a couple years ago I pulled a Pentium 3 laptop out of e-waste when that was still considered entry-level-if-you’re-a-masochist and found out that the onboard video card support was dropped from the kernel a few versions back. I didn’t know Linux also paperweighted hardware.
(I still prefer Linux to Windoze)
I thought that github user looked familiar – I tested his rtw88 driver on a risc-v board.
Unlike some older, stable drivers in the kernel, his driver compiles and works on risc-v.
On a tangent topic: How on earth this person managed to get all that code? Did he write it himself? Reverse engineering? IA Agents? It’s a geniune question as the repo it’s 3 weeks old (altough the guy itself seems to be into this kind of thing judging by the other repos). I’m in now way judging but puzzled by the size and loc’s