Remove the old rtl8192cu proprietary driver, and re-enable the upstream RTLWIFI driver instead

[piso77]

From a discussion on the raspberry forum:

https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=147635

Around 2012 (~3.2.x Linux) the rtlwifi and rtl8xxxu drivers weren't up to the task, so it was decided to import the proprietary Broadcom driver instead, and disable RTLWIFI.

Fast forward 4 years, RTLWIFI and RTL8XXXU received hundreds of commit, left staging and are now the default upstream supported driver for rtl819xxx chipset, plus the proprietary rtl8192cu driver uses old legacy code, and some wireless commands simply don't work with it (e.g. iw phy, part of openwrt, etc)

For these reasons, i'm proposing to drop the proprietary 8192cu (reverting the original import commits), and enable the upstream drivers.

[clivem]

Have you actually done any testing wrt speed and throughput, the upstream driver vs the Realtek one? Because if you haven't, you should, before proposing this! ;)

[piso77]

Nope, simply because i can't get my wifi dongle to work with rtl8192cu driver, while it works fine with the upstream driver (so in that regards it would be 0 KB/s vs $some MB/s).

Moreover, reliably benchmarking a wireless driver supporting a wide range of chips is a tricky job: you need a noise free environment, a testbench network and even then, the result of the driver on a single silicon chip (like in my case) won't mean that the driver X is better than the driver Y, since with different silicons the results may vary again.

My comment was more in line with:

-part of the de facto standard wireless tools don't work with the 8192cu driver (iw phy, etc)
-it relays on a deprecated interface
-it's the exact same driver that was imported years ago, no bugfixes since then, no security updates, etc

if you look around, Raspbian is the only distro shipping the 8192cu driver instead of rtlwifi / rtl8xxxu:

-Ubuntu is not shipping it [1]
-CentOS / Redhat is neither [2]
-Arch Linux is neither [3]
-Debian is neither [4]
-OpenWRT is neither [6]

so either the entire Linux world doesn't support Realtek 8192 chips and it's relaying on a broken upstream driver, or Raspbian is shipping a stale piece of software that it's already lacking in some areas.

1: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/tree/drivers/net/wireless
2: http://vault.centos.org/7.2.1511/os/Source/SPackages/kernel-3.10.0-327.el7.src.rpm
3: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux
4: https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches
5: https://dev.openwrt.org/browser/branches/chaos_calmer/target/linux?order=name#generic/patches-3.18

[popcornmix]

We did drop the non-upstream driver for BRANCH=next a while back (I think 4.0) for these reasons but had to add it back in after complaints from users.

More recently OSMC dropped the non-upstream driver, but again had to revert back after complaints from users.

So, without much wider testing I don't think we can do this now.

It may make sense to build both modules, and work out a scheme where users can choose which one to use (e.g. through blacklisting) but we'd like to maintain the current behaviour by default.

I could try dropping the non-upstream driver on the 4.6 branch, which may get some BRANCH=next test builds in the future and see whether there are complaints.

[samnazarko]

Unfortunately it is still the case that the upstream driver performs suboptimally. When I tested it on OSMC in Feb/March 15 with 3.18, we didn't see improvements in throughput (quite the opposite actually) over the downstream driver that Raspberry Pi have added. Our plan to move to the upstream driver was for similar reasons: greater vendor compatibility, benefit of upstream maintenance and a better quality driver. My understanding however is that maintenance of this driver only goes as far as keeping it synced with 80211cfg changes upstream and no improvements have been made for some time.

OSMC now uses a different rtl8192cu driver which has had good reports from users. Open/LibreELEC similarly build with an out of tree module and complaints seem to be sparse. https://github.com/osmc/rtl8192cu-osmc may be of use to you. You could use this driver with DKMS for now.

If your dongle isn't detected please give me the output of lsusb so I can add support for it

[fran6co]

Wouldn't it better to move rtl8192cu to a different repository as a dkms and put back rtlwifi and block it with a blacklist? This way people that want to use rtl8192cu driver with different kernels can and maybe it could merge all the repositories that already do that.

[fran6co]

Or get the best of 2 worlds and use git submodule to have the driver in another repository and at the same time have it here as in kernel module. It would require to add --recursive to the git clone in the scripts that build the kernel.

[fran6co]

This PR #1489 fixes some of the concerns with the old driver (now it works with iw).
The good thing about the old driver is the concurrent mode that lets you create a repeater or other possibilities.

[mi-hol]

WiFi performance seems to be a sticky point for some time but the topic seems to have gone off the radar currently.
@popcornmix @clivem @samnazarko @piso77 @fran6co
Would it be worth to resume this work?

[piso77]

My position is that, there's an upstream driver, it's maintained and constantly updated so we better stick to it - using a stale, out of tree driver is really a bad choice IMO.

[samnazarko]

I think RPF should stay with the upstream version too. It's on the distribution to choose what they ship and what works best for them. Currently, it's easy for us to drop our version and swap out to the upstream version if things improve in the future.

It's also good to have a kernel tree that is as vanilla as possible: it will reduce time to move forward (no constant bodging of cfg80211() changes) and keep things simple.

As we can see: despite the original PR targeting 4.4 which is LTS, the tree has diverged enough that there are now conflicts. This looks like a support burden.

[Ruffio]

@piso77 @samnazarko can this PR be closed? As far as I read it can, but I could be mistaken. Please close this PR if it is not going to be fixed and thereby be a candidate to be merged...

[Techwolfy]

I needed to use 802.11s mesh networking, which isn't supported by the current driver, so I had to manually recompile and install the rtlwifi drivers. The lwfinger/rtlwifi_new repository contains a version of the drivers updated for the current kernel. I'm currently only using the rtl8192cu drivers out of that repository (kernel modules rtlwifi.ko, rtl_usb.ko, rtl8192c-common.ko, and rtl8192cu.ko), but they work well on v.4.4.50+ (current stable).

If anyone is interested in adding these into the kernel (blacklisted by default), I would appreciate it; I haven't done much kernel work before and I don't currently have time to work on it.

[JamesH65]

Does updating to the latest kernel release fix any issues that remain on this? My suspicion is that we can close this issue due to improvements in the upstream driver codebase.

[popcornmix]

@JamesH65
Unfortunately the upstream driver is still not usable for most users.
We do now build both upstream and proprietary driver with the upstream one blacklisted by default (in /etc/modprobe.d/blacklist-rtl8192cu.conf), so users can remove the blacklist if they want to use the upstream driver.
I'll close this as it shouldn't be required any more.

[popcornmix]

See: #1866