linux-raspi2: rtl8192cu vs 8192cu

Bug #1577421 reported by Paolo Pisati
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux-raspi2 (Ubuntu)
Paolo Pisati

Bug Description

SRU justification:

Impact: as part of the RaspberryPI BSP we got an out of tree Realtek driver that predates the upstream rtlwifi driver:

commit 352ad803b031478b4f5ae55835225a699afa5ed3
Author: popcornmix <email address hidden>
Date: Mon Sep 3 17:10:23 2012 +0100

    Add non-mainline source for rtl8192cu wireless driver version v4.0.2_9000 as this is widely used. Disabled older rtlwifi dri

    8192cu needs old wireless extensions

    The obsolete WIRELESS_EXT configuration is used
    by the old Realtek code and is needed for AP support.

    8192cu: CONFIG_AP_MODE hardcoded in autoconf.h

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index f9f9422..cfb2280 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -278,7 +278,8 @@ source "drivers/net/wireless/orinoco/Kconfig"
 source "drivers/net/wireless/p54/Kconfig"
 source "drivers/net/wireless/rt2x00/Kconfig"
 source "drivers/net/wireless/mediatek/Kconfig"
-source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
+#source "drivers/net/wireless/realtek/rtlwifi/Kconfig"
+source "drivers/net/wireless/realtek/rtl8192cu/Kconfig"
 source "drivers/net/wireless/realtek/rtl8xxxu/Kconfig"
 source "drivers/net/wireless/ti/Kconfig"
 source "drivers/net/wireless/zd1211rw/Kconfig"

This driver not only predates Linux's rtlwifi driver, but it behaves differently too (the 'iw phy' commands doesn't work, AP is not working for some adapter, etc), it's stale (it's the same exact driver that was imported into the RaspberryPI BSP around Linux 3.2 and got no updates since then -, and is not widely used as rtlwifi is - every other big Linux distribution uses rtlwifi - Ubuntu, CentOS / RH, Debian, Gentoo, Arch, OpenWRT, etc except for the RaspberrPI kernel / Raspbian.

I've tried to convince upstream to remove this driver and revert to rtlwifi, but my suggestion was met with resistance:

Since we successfully use rtlwifi in every other architecture / branches, i'm proposing to drop this out-of-tree driver and bring the raspi2 kernel closer to the other Ubuntu kernels.

If we ever feel the need for an out of tree driver for this chipset, the driver should probably be imported into master and propagated from there to all the branches.

Fix: Revert the Realtek driver, and add back RTLWIFI to the build


check for the presence of the 8192cu.ko module:

$ find /lib/modules/`uname -r` -name 8192cu.ko

if it's present you have the out-of-tree driver,
while if it's missing and you have the rtl819cu.ko, you're running the upstream driver:

$ find /lib/modules/`uname -r` -name rtl8192cu.ko


As part of the RaspberryPI BSP we got this commit:


 Add non-mainline source for rtl8192cu wireless driver version v4.0.2_…

…9000 as this is widely used. Disabled older rtlwifi driver

8192cu needs old wireless extensions

The obsolete WIRELESS_EXT configuration is used
by the old Realtek code and is needed for AP support.

8192cu: CONFIG_AP_MODE hardcoded in autoconf.h


that disables the Realtek driver in drivers/net/wireless/realtek/rtlwifi from building, and instead pull in its own proprietary version in drivers/net/wireless/realtek/rtl8192cu.

This result in a difference in the number or rtl8192 drivers shipped with generic:


versus the only 8192 driver that we ship in linux-raspi2 due to the commit above:


Feature wise is not yet clear which of the two is preferable (and why), plus the raspi3 is shipping with a wifi chip and we should be careful not to break support for it.

Paolo Pisati (p-pisati)
Changed in linux-raspi2 (Ubuntu):
assignee: nobody → Paolo Pisati (p-pisati)
Revision history for this message
Alexander Sack (asac) wrote :

fwiw, on my realtek 8912 based dongle AP mode works pretty much fine in 4.4 kernel on beaglebone... maybe the mainline/staging driver has improved enough between 4.0 and 4.4?

Is there a way we cna have both modules and hint which will be picked with priority? If so we could allow device builders to just blacklist the one they dont want etc.

Paolo Pisati (p-pisati)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux-raspi2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Badri Varadarajan (vbadrin) wrote :

Hi, chiming in to record that this bug affects anyone who is trying to put the 8188CUS chipset into monitor mode.

Debian distrubutions for x86 use the driver rtl8192cu, and that works just fine in both managed and monitor modes.

Raspbian on Raspberry PI3 (I have tried many versions including 4.4.9) use the driver 8192cu, which as pointed out by Paolo, has problems. Specifically it works just fine in managed mode, but is not able to put the chipset correctly in monitor mode (for example, one cannot do a 802.11 packet captures or set the channel). I will try rebuilding linux with the 8192 suppressed, and post the results here.

Revision history for this message
Badri Varadarajan (vbadrin) wrote :

After rebuilding the kernel with only the rtlwifi source and object files, I am able to put the 8818CUS chipset in monitor mode. This is on 4.9.13-v7+

Revision history for this message
Badri Varadarajan (vbadrin) wrote :

..running on raspberry pi 3. Second Paolo -- this really should be the default since most folks who use a wifi dongle on a raspberry pi really want to use it for wifi analytics such as monitor mode sniffing.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.