Driver install for RTL8192FU on RPi2B?


I have been banging my head against a brick wall trying to build a captive portal for a friend. I am worn out and keep hitting brick walls (incomplete or old forum posts) and can't seem to get wireless working at all.

I read the official documentation... :confused:

And tried to catch-up on wifidog...

However, when I try to use them, they appear to be quite devoid of information. Perhaps I am doing something wrong?

~4 years ago, I built a wifidog captive portal on a RPi1. It was there for around 2-3 years, working fine. And now? I can't even get Linux to see the damned USB wireless controller.

Recently, I had been asked again to build a captive portal for another friend. However, when I tried wifidog this time, which hasn't been updated for years and did not want to work on the latest kernels, I couldn't even make it work on the Pi2B after building from source. I can't remember the specific error text I was getting, but the issues included configuring a wireless network which would shortly disappear, never to broadcast again.

Anyway, I decided to try OpenWRT as the CP platform as it supports wifidog and CoovaChilli.

Incidentally, I had previously tried a 'CoovaChilli' install script, which fell on it's face at the end.

After wifidog, coova chilli and OpenWRT failed to give me any functional wireless with the previous RTL8188RU USB wi-fi controller, I decided to order a different, SUPPORTED controller.

Anyway, turns out (contrary to the item description and packaging) it's not a Ralink RT3070, but another ***** Realtek monstrosity. This time, it's an RTL8192FU.

However, unlike previous occasions, I have the Linux drivers and these drivers are supposed to fully support AP mode, high power, etc.

So, my question is: How do I install this USB wireless driver on OpenWRT?

If this is simply not feasible, I can return the adapter as it was incorrectly advertised, but I've been trying to get this finished for about a month now and I'm starting to wish I'd never volunteered in the first place. If so, can anyone suggest (and provide a link to) a compatible USB wi-fi controller?

I have read posts which suggest that successfully installing a driver manually is sporadic, which is rather disappointing to read.

There is a bash script on the accompanying driver CD to actually build the driver from source... I am apprehensive about trying it out in case it fails, too.

If anyone has any ideas on how to get this **** wireless controller to work with OpenWRT, I will be eternally grateful.


For the price of Pi + SD card + USB wifi + case + power supply you could buy a midrange desktop router or a low-end wall mounted AP. This application doesn't need the large CPU and RAM of the Pi, but reliable wifi is of course vital.

1 Like

Buy a GLiNet MT300n-v2, flash with OpenWrt, install openNDS. ~$20 total project cost, job done.
You could choose just about any openwrt supported device other than a pi and you will have no problems.
openNDS is downloadable from OpenWrt Snapshots currently but is a stable release ready for OpenWrt 20.x.x when it comes out but runs fine on 19.x with a simple config option.

I've seen that comment quoted everywhere whilst doing my due diligence an searching for my issue on the forum.

I was hoping having the 'official' Linux driver files meant I could get it working.

If it's not possible to get ANY RTL adapter to work with it's respective driver, then I must have gotten the wrong idea about how drivers work :confused:

That is very true. I do like to have control over the specification. It needs to be able to take a high-gain antenna to cover the desired area.

Not densely populated with devices, but range is important.

I'm not used to buying solutions that other people have made - They usually fall short of my impression (overselling), which is why I make things myself, plus it's more fun.

The thing that hasn't been fun was ordering one thing and getting the other. I have started to expect to not receive what I purchased when I buy on-line. I just laugh now.

"Official" would be what's in Linus' tree on, out-of-tree (vendor) drivers always come with their own share of nightmares. In this case no nl80211 (only a kernel 2.6.16 era crude ieee80211softmac fork, with an extremely basic and limited cfg80211 emulation) == no AP mode. Maintenance, which includes both integrating this …thing into OpenWrt's buildsystem just as well as keeping it working with future kernel versions, is the other big topic with an easy answer - 'no'.

1 Like

Thank you for your suggestion. I am looking at one on their website right now.

It's very yellow lol

I've never seen one of these before so I'm not sure if it would be suitable.

The spec on the site doesn't answer some of my questions:

Electrically it looks ideal but what kind of range (on average) will it reach with it's internal antenna?

My friend is using a standard wi-fi router in the middle of his plot, but it doesn't even reach the boundary. :confused:

Also, what about with a 12dBi-gain antenna? (I have little confidence in my knowledge of RF calculations.) I can't see an external antenna connector on the photos, but the spec says it 'supports' one. (I've gotten really apprehensive about buying on-line now.)

If I order one (They're ~£20 in UK), would you be able to give me a few pointers on configuring the CP and bandwidth management within OpenWRT?

How many concurrent users/sessions can the GL-MT300N support?

I was jumping into known waters and did not succeed on this occasion, jumping into unknown waters doesn't seem any more promising to me lol

Many thanks for taking the time to answer my query.

Wow, that was most informative (I haven't said that much in recent years lol) thank you for the very understandable explanation - I am ashamed to say that I am quite surprised that I got such a valuable response in a support forum. :slight_smile:

Yeah, so **** Realtek (and those on-line box-shifters.)

I suppose my idea of 'official' is different to that. I have always thought that the creator of the hardware/chip/controller writes the 'official' driver, since they know the feature set better than anyone else, but if RTL aren't following best practices for writing an official driver then I would say that there are, in fact, no RTL drivers. Other people would then write the 'compatible' driver, which would have bugs and unsupported features.

If 'official' Linux means 'in Linus' tree' then wouldn't that mean almost nothing for Linux is official? Though, this really does explain the varied troubles I've had with Linux over the years.

Companies like Intel, AMD (nowadays including their graphics department/ ATi) are actively contributing drivers for their hardware to the linux kernel, often before said hardware even hits the shelfs (which does occasionally lead to the situation that they've written and got merged drivers for hardware that never sees the light of day). They are not alone in this, QCA/ Atheros, Mediatek and many other companies do the same, incidentally so does Realtek for their ethernet chipsets and even their PCIe based WLAN devices (I still wouldn't recommend those for running in AP mode), their USB wireless devisions (RealSIL) is another topic though. nVidia long condemned the independently developed (and merged into mainline) forcedeth drivers for their ethernet chipsets, until they noticed that their users were both predominantly using forcedeth (which came/ comes with the mainline kernel and all the distributions by default) and that it was actually better than their own out-of-tree vendor driver, sadly the graphics divisions don't quite agree with that yet. what are official drivers?
I stand by my opinion that whatever is mainline, part of Linus' tree, gets that label - and yes, the linux kernel does ship with more drivers by default than both MacOS and windows (not always for the very latest hardware or for devices where vendors actively won't cooperate, but it does ship with a lot of drivers, including ones that are no longer available for current windows versions. You have an older printer/ scanner/ wireless- or graphics card that's no longer supported by windows 10? Chances are quite good that it's still fully supported and available by default on your next best contemporary linux distribution, no driver downloads or -installations necessary).


I regularly use MT300N-v2 to achieve 200 metres clear line of sight range so it all depends on the venue but you can add cabled APs or a Mesh.
You can modify the device to add external antennas, but to be honest, what you gain from the external, you loose (mostly) from cable losses - we are talking about microwave frequencies here :wink: so the AP or Mesh approach is far better.

All easy for a network engineer level of knowledge or if you want to learn as a part of the project.
Alternatively you can purchase the hardware with custom CP/Mesh firmware ready to plug and play with exterior grade (weather proof) options if required. (PM me if interested)

For openNDS, see:

1 Like


  1. Don't use a Raspberry Pi;

  2. Don't use Realtek;

tl;dr: Just no.

Coming from a techie who doesn't give up that easily (or, at least, never used to) this hill was a bit too steep to climb and my expectations of the Pi (and Realtek) may have been too high.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.