Monitor mode not working on wireless adapters with RTL8192CU / RTL8192CUS chipsets

[Noki]

It seems that the wireless driver for RTL8192CU / RTL8192CUS chipsets is different from the driver distributed with the standard linux kernel. Due to this the functionality for this chipset is highly limited. Putting devices with this chipset into monitor mode is not possible at all.

I suggest to switch to the driver from the standard linux kernel. Many people bought adapters using this driver. Especially the EDIMAX EW-7811UN was mentioned and bought a lot and even made it to the bestseller lists of Amazon.

[moonman]

And why do you think this driver was included? Probably because the one that comes included doesn't work well?

[Noki]

I don't know why the driver was replaced. I just know that on other platforms I can use the device with all features because the standard kernel driver is infact perfectly working there. On the raspberry pi I can't due to the replaced driver. So probably previous problems were already fixed.

[DirtyJerz]

If memory serves me correct, I remember the standard driver did not work/dropped TONS of packets for the edimax branded RTL8192CU/S. I did have this problem at release and had to resort to a bridge for a while until the 8192CU.sh scripts came out for building and installing the, now included, driver. Also, I remember the adafruit occidentals version of Debian (Wheezy) had a stable driver while the Raspbian (Squeeze) one was having difficulty. Although advanced functionality, such as monitor mode, is lost using the current module, managed mode seems to be very stable (IMO). I have to agree that a stable managed mode is more important in a daily driver. There is an issue (or a few) in here that attest to the troubles. I'll look back and see if I can reference them.

EDIT:
#96

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=6256&p=165139#p165139

[Blender3D]

So for those of us who do need monitor mode for this device, what do we do?

[popcornmix]

You'll need to build a custom kernel:
http://elinux.org/RPi_Kernel_Compilation

If there is strong evidence that the upstream driver is now usable and the out of tree driver is no longer required that can be reconsidered, but when we were using the upstream driver there was a 1000+ post thread about how to switch to the out of tree driver.
So there would be a lot of upset people if we switched and the situation was still bad.

It may be possible to build both kernel modules, and blacklist the upstream one, so switching between them is easier than a kernel rebuild. It would be useful if someone could test if this scheme works.

[tfgg]

Are there any good guides for how to enable the module with working monitor mode for the EW-7811UN when building a custom kernel? I'm not clear how I'd do it.

[acidjazz]

BUMP. NEED THIS BAD. $40 in wifi adapters all around me and none of them go to monitor mode :(

[acidjazz]

please @popcornmix maybe just a walkthrough on kernel compilation w/ a regular driver?

[DirtyJerz]

@acidjazz

from my android experience, after you patch the kernel tree, adding the drivers source files & configs, you need to export ARCH=arm and export CROSS_COMPILE to something, I'm unclear but a quick google search should show the basic how-to on RPi kernel compilation.
before you do a 'make' do 'make menuconfig' and select the appropriate driver.

Not really an exact solution, sorry, but should get you on the right track at least.

[acidjazz]

@DirtyJerz I"m gonna need a lot longer tutorial than that, I finally did just finally grab the rasbpian source and was able to compile the kernel but i have no idea where I intercepts its drivers w/ the proper ones/etc. Going to seee how Pidora stands out.

[popcornmix]

You could try the "testing" 3.18 firmware. See:
http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=93015

I believe this uses the upstream RTL8192CU / RTL8192CUS driver.

[acidjazz]

Thank you @popcornmix I will try this tonight.

[pierz]

I'm not sure if people had seen this post from Jussi Kivilinna (Linux kernel driver maintainer of rndis_wlan) suggesting that the problems with the rtlwifi driver may be down to issues with USB driver (which seems to make sense as this rtlwifi driver works fine on x86 platforms):
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/105642

[P33M]

As far as I'm aware, the dwc_otg hardware requires 32bit alignment on the start of the URB transfer buffer. If transfers are passed in without such a constraint being fulfilled, the driver allocates a bounce-buffer (per-endpoint) so that DMA transfers work properly.

It's inefficient but works.

[cinhil]

Hello,
I would like to do some tests on upstream driver possibilities on 3.18.x.
What should I do to build my kernel with upstream driver instead of the out-of-tree driver ?
I usually build my kernels but did not find where the choice during the two drivers has been wired.
Thank you,

[popcornmix]

In drivers/net/wireless/Kconfig you should see:

#source "drivers/net/wireless/rtlwifi/Kconfig"
source "drivers/net/wireless/rtl8192cu/Kconfig"

rtlwifi is the upstream driver and rtl8192cu is the out-of-stream driver. Swap the commented out one, and make sure CONFIG_RTL8192CU is still enabled (they both use the same config option)

[pierz]

You also need to uncomment this line in drivers/net/wireless/Makefile:
#obj-$(CONFIG_RTLWIFI) += rtlwifi/
Then rerun menuconfig to select the options you want.

[sebastian-stephan]

Thanks, this worked for me. Also blacklisting rtlwifi allows me to switch back to the out-of-stream rtl8192cu driver.

[richiejp]

Can the rtlwifi driver please be included again? I have tested it with the RTL8192CU and the RTL8188CUS ICs and it appears to work fine. I think a lot has changed since it was removed and it has far more functionality (it is cfg80211 compliant) than the out-of-stream driver.

[popcornmix]

I don't believe it is reliable. OSMC chose to use upstream rtlwifi driver for OSMC RC1 and had lots of wifi complaints, and have moved back to out-of-tree 8192 driver for RC2.

See: osmc/osmc@5ef9430

[richiejp]

I think you are right. Perhaps this has something to do with it:

https://bugzilla.novell.com/show_bug.cgi?id=927786
http://www.spinics.net/lists/netdev/msg326380.html

[Lekensteyn]

The rtl8192cu patch (mentioned by @richiejp) is now upstream in v4.1-rc1-52-g414b7e3.

Let's see how this works out (https://git.lekensteyn.nl/peter/linux/log/?h=rpi-4.0.y-dev).

[cinhil]

Hello,
The rtl8192cu driver seems to work for me in promiscuous mode but I have another issue that I can not capture any data frame from wifi client associated with an AP. It captures only AP beacons frame and device probes frame... I also compile rtlwifi from 4.1rc5 code into 3.18.14 sources from raspberry github and found the same behaviour.

Edit : my mistake. It seems working ok after applying a filter ( iw dev [dev] set monitor otherbss )

[afaganga]

Hi.

I've compiled the 4.0.y branch of the kernel, including the rtlwifi.ko.
Even with
sudo modprobe rtlwifi --force
I get
ERROR: could not insert 'rtlwifi': Exec format error
I would really like monitor mode for this rtl8192cu adapter. I would like to see both rtl8192cu and rtlwifi included in raspbian by default, to ease install.

[afaganga]

So, @popcornmix said

In drivers/net/wireless/Kconfig you should see:

#source "drivers/net/wireless/rtlwifi/Kconfig"
source "drivers/net/wireless/rtl8192cu/Kconfig"

but I really don't like this way of editing Kconfig. I feel a better solution is to keep both drivers in the tree and default rtlwifi/Kconfig's RTLWIFI entry to not include the driver. I even prefer both drivers be compiled and installed, with rtl8192cu (and dependencies) being blacklisted by default if they are that buggy. In my case, I'm still struggling to get rtl8192cu to install in a clean Raspbian image...

[popcornmix]

I'm happy to accept a PR that builds both drivers as long as the default driver used remains the same. I'm not certain of the behaviour if there are two drivers in the kernel with the same VID/PID.

[Lekensteyn]

Blacklisting should be sufficient. Consider nouveau vs proprietary nvidia modules, or radeon and proprietary fglrx on desktop OSes. This requires additional files besides the kernel though.

[popcornmix]

We could make new raspbian images with both modules built and a blacklist in /etc/modprobe.d but it's trickier for people who update kernel in an existing install. If it turns out without the blacklist the behaviour is well defined and ideally the same module as before gets loaded, then no problem.
If you get the "other" module, then not so good.
If you a random module then even worse.
If the two modules conflict and break then worse still.

If someone can confirm what the behaviour is with both modules present and no blacklist, we can decide if building them both by default is safe to do.

[MattMacGillivray]

Any update on whether both drivers might be included by default?

Alternatively, would it be possible to enumerate the steps required to enable the right module/firmware to allow monitoring mode?

I read the thread, verified the USB fix was in, updated the Kconfig as noted above, recompiled the kernel (4.1.7), verified that the rtlwifi mods are loaded via lsmod, but am still unable to run in monitoring mode. Tested using tshark: 'That device doesn't support monitor mode'.

I must be missing something simple.

( full details available in stackoverflow post )

[booski]

I just tested compiling a new kernel from source, including both drivers. I followed the instructions here for the compilation. (I cross-compiled if that makes any difference.) I built only for rpi2.

My changes were minimal:

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 8e0a4bb..8918c41 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -278,7 +278,7 @@ 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/rtlwifi/Kconfig"
+source "drivers/net/wireless/rtlwifi/Kconfig"
 source "drivers/net/wireless/rtl8192cu/Kconfig"
 source "drivers/net/wireless/ti/Kconfig"
 source "drivers/net/wireless/zd1211rw/Kconfig"
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 8e007e3..1c9d0be 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_B43LEGACY)               += b43legacy/
 obj-$(CONFIG_ZD1211RW)         += zd1211rw/
 obj-$(CONFIG_RTL8180)          += rtl818x/
 obj-$(CONFIG_RTL8187)          += rtl818x/
-#obj-$(CONFIG_RTLWIFI)         += rtlwifi/
+obj-$(CONFIG_RTLWIFI)          += rtlwifi/
 obj-$(CONFIG_RTL8192CU)                += rtl8192cu/

 # 16-bit wireless PCMCIA client drivers

I'm running identical raspbian images on two different rpi2:s, each with a d-link dwa-121 wlan dongle, and rebooted them both about 5 times each with the new kernel.

It looks like rtlwifi is being loaded by default each time. This is the relevant part of dmesg:

[    3.168671] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[    3.280424] usb 1-1.3: New USB device found, idVendor=2001, idProduct=3308
[    3.293862] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.307671] usb 1-1.3: Product: 802.11n WLAN Adapter
[    3.319859] usb 1-1.3: Manufacturer: Realtek
[    3.331020] usb 1-1.3: SerialNumber: 00e04c000001
[    3.428865] udevd[175]: starting version 175
[    3.867790] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    4.123310] cfg80211: Calling CRDA to update world regulatory domain
[    4.282017] rtl8192cu: Chip version 0x10
[    4.356412] random: nonblocking pool is initialized
[    4.444687] rtl8192cu: MAC address: 48:ee:0c:f2:ff:f8
[    4.456208] rtl8192cu: Board Type 0
[    4.466154] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[    4.478360] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[    4.492876] usb 1-1.3: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
[    4.515435] usb 1-1.3: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2
[    4.530592] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
[    4.544096] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
[    4.567984] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[    4.569740] usbcore: registered new interface driver rtl8192cu
[    4.634776] Error: Driver 'rtl8192cu' is already registered, aborting...

To me it looks like rtlwifi is loaded first, and then 8192cu fails because there is already a module named rtl8192cu loaded (why in the world do these names have to be so confusing?). I'm just guessing though, so don't take my word for it.

The driver still doesn't seem to be stable. Like I said I've rebooted both about 5 times each, and one of my pis wouldn't shut down once and another time it was impossible to bring up the interface on one of them.
dmesg had this to say when the interface couldn't be brought up:

[   87.933307] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready fail!! REG_MCUFWDL:0x00000006 .
[   87.933334] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not ready to run!
[  100.167695] rtl_usb: reg 0x870, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0x6
[  110.167725] rtl_usb: reg 0x824, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0x6
[  120.177792] rtl_usb: reg 0x820, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0x6
[  130.177843] rtl_usb: reg 0x8a0, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0x6

Unplugging the dongle at that point (to get out of a hanging 'ifconfig wlan0 down') caused the kernel to panic.

The usecase that I want this driver for is ad-hoc networking, which doesn't work with the 8192cu driver. The times that the module didn't break anything (see above), the ad-hoc link seems to work perfectly. I'm going to leave the two pis pinging each other over the weekend to see if it's reliable, but it looks promising, apart from there being some intermittent problem with enabling the dongle.

[popcornmix]

If you are building your own kernel, you could try the rpi-4.3.y tree which is newer and so may have additional fixes. But my experience is that rtlwifi is (or at least has been historically) less reliable than the out-of-tree driver.

[Ruffio]

@Noki has this issue been resolved? If yes, then please close this issue.

[Noki]

@Ruffio: No idea. I moved on and never looked back. I just close the issue.

[marktheunissen]

The problem is that Raspbian still uses a non-standard driver and thus monitor mode does not work unless you recompile the kernel. So it's not really fixed but I understand that it's a tiny fraction of users who want monitor mode so pretty low priority.