Welcome to the most active Linux Forum on the web.
Go Back > Blogs > linux-related notes
User Name


Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Rate this Entry

How I got my obscure Realtek USB wireless adapter to work

Posted 09-27-2019 at 04:07 PM by the dsc
Updated 11-05-2020 at 03:40 PM by the dsc (more relevant things to add)

The device is " 0bda:f179 Realtek Semiconductor Corp. 802.11n," per lsusb. Using this driver:

Not the deb files, the dkms path. (Speaking of path, I have the impression it has explicitly coded paths and needs to be installed from /usr/src)

Including the added settings regarding USB plugging and power management issues, AND the advice on this forum:

The "symptom" wasn't the same, I don't have Windows installed to tell. What was happening is that the wifi would "see" many networks (to my surprise it works more or less immediately after the dkms commands, but requires to unplug and plug the thing, then iwconfig will show it's alive), but I wouldn't be able to connect to the one(s) I'm supposed to be able to. No obvious hint from any kind of normal-verbose-level messages. Assuming it wouldn't hurt to try, I decided to try two of the suggestions at once:

Originally Posted by tbg
The firmware appeared to be loading properly, but there were still driver errors that I could not find any information about in your dmesg logs. Perhaps it would be worth attempting to load the driver sooner.

To load the module sooner create a new configuration file:

echo 'rtl8188fu' | sudo tee /etc/modules-load.d/rtl8188fu.conf

Originally Posted by tbg

Is it possible you have MAC address filtering enabled in your router. Windows could theoretically be connecting because it has the correct MAC address programed, but Manjaro is blocked because of MAC randomization.

Try this:

Disable MAC Address Randomization with the following command:

echo -e "[device]\nwifi.scan-rand-mac-address=no" | sudo tee /etc/NetworkManager/conf.d/disable-random-mac.conf
After creating the new conf file, reboot both your router and your computer.

How is your network set up. Static IP address?

Any chance you have an IP address or hostname conflict happening.
I didn't reboot the router, which maybe hints just the first thing that was the solution.

Thanks to this "tbg" dude.


I was for some reason thinking it would only work for kernels 5 and later, but I also got it to work for 4.19, just by telling dkms to build and install it (while I was running 5.2 though, but that shouldn't matter, I guess):

dkms build rtl8188fu/1.0 -k 4.19.0-6-amd64

dkms install rtl8188fu/1.0 -k 4.19.0-6-amd64
After having installed its headers, since I was previously using an even older one that didn't have headers available.

Kernel 5 is giving me some video/screen artifacts (black rectangles), at least with "glamor" acceleration, and if "glamor" has it, I believe "sna" would have even more. 4.19.0-5 didn't have them, let's hope 0-6 doesn't as well.


Had to install it again, on a different computer.

Somehow it behaved differently, without that whole thing of detecting the wireless networks and yet not connecting, it instead didn't show anything at all detected (I mean, networks; the device itself was visible on lsusb and iwconfig). At least on the Wicd GUI. But then apparently these commands fixed it:

rfkill unblock wlan
sudo service network-manager restart

At first it was apparently something I needed to do every reboot, but somehow that's not it anymore. I guess maybe I tweaked Wicd's config just enough, I don't even understand it.


What's the deal with "echo whatever-config | sudo tee file" method , versus the old fashioned and plain simple "[sudo] echo whatever-config >> file"?

Somehow it seems a common thing to stumble when looking for wifi stuff.


Apparently changing wicd's wpa-supplicant driver from WEXT (default) to nl802011 makes it connect somewhat faster, not taking as long to get an IP and whatnot. Arch-linux wiki suggests that, even though they don't mention this effect. Maybe this is not restricted to this particular hardware, but something more general.

Wicd still suggests to "almost always" use Wext as WPA supplicant driver and defaults to it. This is outdated behavior. One should use nl80211 instead, except with old drivers that do not support it. The relevant option is located in Preferences > Advanced Settings.
Posted in Uncategorized
Views 3451 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 09:06 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration