rtl8192cu module for Edimax EW-7811n WiFi dongle

[TheOnly]

Greetings.

It seems that many people have been using this dongle for various purposes to connect their Pi in a wireless fashion. However, the module shipped with the Raspberry Pi kernel (located at: https://github.com/raspberrypi/linux) named 8192cu is different from the one in the mainstream kernel release (namely, rtl8192cu).

I am sure there is a good reason for this, however, the 8192cu module has very limited functionality. For example, it is not compatible with the "new" Linux wireless API - cfg80211. In turn, it is not compatible with nl80211 which makes it impossible to use hostapd to force the device into a soft wireless access point mode. Also, one cannot force the device into Monitor mode with this driver.

I have tried the Edimax dongle on my laptop with the rtl8192cu driver that ships with the Linux kernel itself and I can definitely confirm that it works absolutely fine in both AP mode as well as Monitor mode, and for general purpose WiFi use.

Does anyone know why the original rtl8192 kernel module has been blocked and replaced with this 8192cu one? I would also be really grateful if someone could shine some light on unblocking the rtl8192cu module so that it can be used with the Pi. I have a cross-compile environment already set up, so it won't be a big deal for me to recompile the kernel.

Cheers!

[ronmorell]

This is not a direct answer to your post, but still relevant and I'm having an issue getting wifi to work on my raspberry. So maybe this is a good start...
root@ka7u-pi:/etc# cat debian_version
wheezy/sid
root@ka7u-pi:/etc# cat /proc/version
Linux version 3.2.27+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #250 PREEMPT Thu Oct 18 19:03:02 BST 2012
root@ka7u-pi:/etc# lsmod
Module Size Used by
mkiss 9071 0
rose 40053 0
ax25 54760 2 rose,mkiss
snd_bcm2835 12808 0
snd_pcm 74834 1 snd_bcm2835
snd_page_alloc 4951 1 snd_pcm
snd_seq 52536 0
snd_seq_device 6300 1 snd_seq
snd_timer 19698 2 snd_seq,snd_pcm
snd 52489 5 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_bcm2835
8192cu 485042 0
root@ka7u-pi:/etc# dmesg |grep usb
...cut a bunch off...
[ 3.188080] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:c7:8a:37
[ 3.293020] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[ 3.414800] usb 1-1.3: New USB device found, idVendor=7392, idProduct=7811
[ 3.424470] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.442943] usb 1-1.3: Product: 802.11n WLAN Adapter
[ 3.450272] usb 1-1.3: Manufacturer: Realtek
[ 3.472919] usb 1-1.3: SerialNumber: 00e04c000001
[ 7.850145] usbcore: registered new interface driver rtl8192cu
root@ka7u-pi:/etc#

You will notice in the lsmod list the module shows up as 8192cu, but when the EW-7811Un is discovered by udev it shows up in the dmesg listing above has using the rtl8192cu. So are the two modules the same?

Now for my question, The wifi dongle is found by udev and with the network config for wlan0 the blue light blinks once during bootup and that is it. wlan0 is changed to wlan1 and no network connection. Anyone here have an answer that will make the Edimax wifi dongle work on the raspberry pi?
Ron

[TheOnly]

No, the two modules are definitely not the same. I believe that the 8192cu.ko that ships with the Raspberry Pi kernel is the open-source driver provided by Realtek and not the one that ships with the mainstream kernel.

Anyway, to answer your query, the dongle should work just fine with the 8192cu driver as a wireless client to any wireless network within range. I cannot tell for certain why your device gets renamed from wlan0 to wlan1 but it might be worth looking into "/etc/udev/rules.d/70-persistent-net.rules". This file is created by udev to store the names of network interfaces and keep them consistent throughout the system. Udev should automatically put a comment before each rule, saying which driver is responsible for the interface. My only explanation to your issue would be that your dongle was discovered by one driver and assigned the name wlan0, but another driver has assigned it a name wlan1. It may have been a one-off thing, so what you could try is remove the 70-persistent-net.rules file and reboot your Pi. Since udev will not be able to find the file at boot it will re-create it, and re-assign interface names.

Now, for your connectivity issue - how do you connect to your network? Do you use a network client (e.g. network-manager, or wicd?) or do you use the command line? You can try using the command line and setting up your interface with 'ifconfig' and 'iwconfig' and see if it works. Or you could use the /etc/network/interfaces to set up the device.

[Raspberryuser2000]

I have the same problem on Raspberry.

However, this dongle works fine on PandaBoard as AP.

[TheOnly]

@Raspberryuser2000,

Do you know which driver it uses on the PandaBoard? If it uses the mainstream kernel driver you should get something like this in the output of 'lsmod':

Code: Select all

rtl8192cu              58172  0 
rtl8192c_common        33116  1 rtl8192cu
rtlwifi                53840  1 rtl8192cu
mac80211              189904  4 rtl8192cu,rtl8192c_common,rtlwifi,iwlwifi
firmware_class          5128  5 rtl8192cu,rtlwifi,snd_hda_codec,r8169,iwlwifi
cfg80211              144096  3 rtlwifi,iwlwifi,mac80211
usbcore               122888  12 rtl8192cu,rtlwifi,uvcvideo,btusb,rts5139,hid_sony,sl811_hcd,usbhid,ohci_hcd,uhci_hcd,usb_storage,ehci_hcd

[/size]

Keywords to look for: rtl8192cu, rtlwifi, cfg80211 (in use by the former)

[ronmorell]

to TheOnly.
I'm trying to establish the network using the command line via SSH terminal. I have an Ethernet connection established. I moved the file /etc/udev/rules.d/70-persistent-net.rules and the wlan0->wlan1 problem went away. Here is the network startup info:
root@ka7u-pi:/# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface eth0 inet dhcp
auto wlan0
iface wlan0 inet dhcp
pre-up wpa_supplicant -Dwext -i wlan0 -c /etc/wpa_supplicant.conf -B
root@ka7u-pi:/#
root@ka7u-pi:/etc# cat wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
ap_scan=2
network={
ssid="myqwest3613"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
psk=FFD9C9ADFFECF714F68DC77F48
}
root@ka7u-pi:/etc#
root@ka7u-pi:/# ifup wlan0
Line 11: Invalid PSK 'FFD9C9ADFFECF714F68DC77F48'.
Line 11: failed to parse psk 'FFD9C9ADFFECF714F68DC77F48'.
Line 12: WPA-PSK accepted for key management, but no PSK configured.
Line 12: failed to parse network block.
Failed to read or parse configuration '/etc/wpa_supplicant.conf'.
Failed to bring up wlan0.
root@ka7u-pi:/#

The psk passkey is cut and pasted from the wireless security screens in the router. The blue light on the Edimax is not lit. This is quite a way off from your original post, but if you would advise and help, I could sure use it!

No, the two modules are definitely not the same. I believe that the 8192cu.ko that ships with the Raspberry Pi kernel is the open-source driver provided by Realtek and not the one that ships with the mainstream kernel.

Anyway, to answer your query, the dongle should work just fine with the 8192cu driver as a wireless client to any wireless network within range. I cannot tell for certain why your device gets renamed from wlan0 to wlan1 but it might be worth looking into "/etc/udev/rules.d/70-persistent-net.rules". This file is created by udev to store the names of network interfaces and keep them consistent throughout the system. Udev should automatically put a comment before each rule, saying which driver is responsible for the interface. My only explanation to your issue would be that your dongle was discovered by one driver and assigned the name wlan0, but another driver has assigned it a name wlan1. It may have been a one-off thing, so what you could try is remove the 70-persistent-net.rules file and reboot your Pi. Since udev will not be able to find the file at boot it will re-create it, and re-assign interface names.

Now, for your connectivity issue - how do you connect to your network? Do you use a network client (e.g. network-manager, or wicd?) or do you use the command line? You can try using the command line and setting up your interface with 'ifconfig' and 'iwconfig' and see if it works. Or you could use the /etc/network/interfaces to set up the device.

[Raspberryuser2000]

@ TheOnly

On the PandaBoard I have the mainstream kernel module: rtl8192cu, rtlwifi, cfg80211

[TheOnly]

@ronmorell,
Try having this instead of pre-up in your /etc/network/interfaces:

Code: Select all

auto wlan0
iface wlan0 inet dhcp
        ## WPA
        wpa-ssid        <Your network ESSID>
        wpa-psk         <Your network password (need not be encrypted)>

[/size]
@Raspberryuser2000,
That explains everything. The question now remains how to get rid of the 8192cu module and enable the original rtlwifi/rtl8192cu module

[TheOnly]

Right, so I managed to unblock the rtlwifi/rtl8192cu module in the kernel source so that it compiles with this module instead of the supplied 8192cu. However, the device does not seem to be working for some reason. However, when I type in "modprobe rtl8192cu", the shell freezes and I get the following message from "dmesg":

Code: Select all

[  194.099389] cfg80211: Calling CRDA to update world regulatory domain
[  194.198990] rtl8192cu: Chip version 0x10
[  360.738593] INFO: task modprobe:1788 blocked for more than 120 seconds.
[  360.741262] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  360.746456] modprobe        D c03a3414     0  1788   1729 0x00000000
[  360.746592] [<c03a3414>] (__schedule+0x310/0x618) from [<c03a20e0>] (schedule_timeout+0x1c0/0x23c)
[  360.746647] [<c03a20e0>] (schedule_timeout+0x1c0/0x23c) from [<c03a3a54>] (wait_for_common+0xd4/0x1b0)
[  360.746686] [<c03a3a54>] (wait_for_common+0xd4/0x1b0) from [<c027b7bc>] (usb_start_wait_urb+0x60/0xcc)
[  360.746728] [<c027b7bc>] (usb_start_wait_urb+0x60/0xcc) from [<c027b9fc>] (usb_control_msg+0xbc/0xe0)
[  360.746873] [<c027b9fc>] (usb_control_msg+0xbc/0xe0) from [<bf115b58>] (_usb_read_sync+0xcc/0x144 [rtlwifi])
[  360.747020] [<bf115b58>] (_usb_read_sync+0xcc/0x144 [rtlwifi]) from [<bf115bf8>] (_usb_read8_sync+0xc/0x14 [rtlwifi])
[  360.747146] [<bf115bf8>] (_usb_read8_sync+0xc/0x14 [rtlwifi]) from [<bf11285c>] (read_efuse_byte+0x58/0x1c4 [rtlwifi])
[  360.747261] [<bf11285c>] (read_efuse_byte+0x58/0x1c4 [rtlwifi]) from [<bf112bd0>] (read_efuse+0x208/0x4cc [rtlwifi])
[  360.747370] [<bf112bd0>] (read_efuse+0x208/0x4cc [rtlwifi]) from [<bf112ed0>] (efuse_read_all_map+0x3c/0x54 [rtlwifi])
[  360.747483] [<bf112ed0>] (efuse_read_all_map+0x3c/0x54 [rtlwifi]) from [<bf112f40>] (rtl_efuse_shadow_map_update+0x58/0x90 [rtlwifi])
[  360.747643] [<bf112f40>] (rtl_efuse_shadow_map_update+0x58/0x90 [rtlwifi]) from [<bf13f838>] (_rtl92cu_read_adapter_info+0x448/0xdb4 [rtl8192cu])
[  360.747751] [<bf13f838>] (_rtl92cu_read_adapter_info+0x448/0xdb4 [rtl8192cu]) from [<bf14022c>] (rtl92cu_read_eeprom_info+0x88/0x230 [rtl8192cu])
[  360.747866] [<bf14022c>] (rtl92cu_read_eeprom_info+0x88/0x230 [rtl8192cu]) from [<bf116840>] (rtl_usb_probe+0x1bc/0x744 [rtlwifi])
[  360.747958] [<bf116840>] (rtl_usb_probe+0x1bc/0x744 [rtlwifi]) from [<c027e1cc>] (usb_probe_interface+0xfc/0x1bc)
[  360.748017] [<c027e1cc>] (usb_probe_interface+0xfc/0x1bc) from [<c023f738>] (driver_probe_device+0x7c/0x208)
[  360.748052] [<c023f738>] (driver_probe_device+0x7c/0x208) from [<c023f950>] (__driver_attach+0x8c/0x90)
[  360.748080] [<c023f950>] (__driver_attach+0x8c/0x90) from [<c023e04c>] (bus_for_each_dev+0x54/0x80)
[  360.748122] [<c023e04c>] (bus_for_each_dev+0x54/0x80) from [<c023eea0>] (bus_add_driver+0x9c/0x230)
[  360.748155] [<c023eea0>] (bus_add_driver+0x9c/0x230) from [<c023fea8>] (driver_register+0x78/0x144)
[  360.748184] [<c023fea8>] (driver_register+0x78/0x144) from [<c027d6f0>] (usb_register_driver+0x6c/0x128)
[  360.748213] [<c027d6f0>] (usb_register_driver+0x6c/0x128) from [<c0008594>] (do_one_initcall+0x34/0x180)
[  360.748255] [<c0008594>] (do_one_initcall+0x34/0x180) from [<c005f7c4>] (sys_init_module+0xe0/0x19d8)
[  360.748292] [<c005f7c4>] (sys_init_module+0xe0/0x19d8) from [<c000dd20>] (ret_fast_syscall+0x0/0x30)

[/size]

I'm using the 3.6.10+ version of the kernel from github cross-compiled on Gentoo Linux (amd64).

Linux pi 3.6.10+ #2 PREEMPT Fri Dec 14 14:58:13 GMT 2012 armv6l GNU/Linux

Linux version 3.6.10+ (root@orion) (gcc version 4.5.4 (Gentoo 4.5.4 p1.0, pie-0.4.7) ) #2 PREEMPT Fri Dec 14 14:58:13 GMT 2012

I should also mention that my Pi uses the Debian Wheezy with all package updates up to yesterday already applied. The "firmware-realtek" package is also installed.

Any ideas?

[hexameron]

I have found one bug in the kernel driver: "usb_control_msg" data needs to be 16-byte aligned, or it hangs. It does not help that the line calling "usb_control_msg" in drivers/net/wireless/rtlwifi/usb.c
has an infinite time-out setting, so you do not even get the "time-out" error message.

There may be other alignment issues, because it still does not work with my "fix", but the module will load and unload with that change.

[ 3.011093] hub 1-1.2.1:1.0: USB hub found
[ 3.011619] hub 1-1.2.1:1.0: 4 ports detected
[ 3.284811] usb 1-1.2.1.4: new high-speed USB device number 7 using dwc_otg
[ 3.386429] usb 1-1.2.1.4: New USB device found, idVendor=050d, idProduct=1102
[ 3.386456] usb 1-1.2.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.386472] usb 1-1.2.1.4: Product: 802.11n WLAN Adapter
[ 3.386485] usb 1-1.2.1.4: Manufacturer: Realtek
[ 3.386498] usb 1-1.2.1.4: SerialNumber: 00e04c000001
[ 6.975961] rtl8192cu: Chip version 0x10
[ 6.975989] RT_TRACE:cdb34ee0:rtl92c_read_chip_version:Chip Version ID: NORMAL_TSMC_CHIP_88C
[ 6.976002] RT_TRACE:cdb34ee0:rtl92c_read_chip_version:Chip RF Type: RF_1T1R
[ 6.976012] RT_TRACE:cdb34ee0:rtl92c_read_chip_version:VersionID = 0x 10
[ 6.976139] RT_TRACE:cdb34ee0:rtl92cu_read_eeprom_info:Boot from EFUSE
[ 6.976155] RT_TRACE:cdb34ee0:rtl92cu_read_eeprom_info:Autoload ERR!!
[ 6.976175] RT_TRACE:cdb34ee0:_rtl92cu_read_adapter_info:EEPROM ID(0xffff) is invalid!!
[ 6.976189] RT_TRACE:cdb34ee0:_rtl92cu_hal_customized_behavior:RT Customized ID: 0x00
[ 6.976204] RT_TRACE:cdb34ee0:_rtl_usb_init:USB EP(0x81), MaxPacketSize=512, Interval=0
[ 6.976216] RT_TRACE:cdb34ee0:_rtl_usb_init:USB EP(0x02), MaxPacketSize=512, Interval=0
[ 6.976227] RT_TRACE:cdb34ee0:_rtl_usb_init:USB EP(0x03), MaxPacketSize=512, Interval=0
[ 6.976239] RT_TRACE:cdb34ee0:_rtl_usb_init:USB EP(0x84), MaxPacketSize=64, Interval=1
[ 6.976515] RT_TRACE:cdb34ee0:_rtl_usb_init_tx:USB Max Bulk-out Size=512
[ 6.976531] RT_TRACE:cdb34ee0:_rtl_usb_init_tx:Invalid endpoint map setting!
[ 6.976545] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 6.979951] usbcore: registered new interface driver rtl8192cu

[hexameron]

My bad .. I had broken the driver, so that it was not getting to the part where it hangs.

Although ... it does now hang a lot quicker, without all the busy-waiting first, so I must have changed something.

[hexameron]

This is enough to bring-up the driver. It is not actually working, but it narrows down the problem.


--- a/drivers/net/wireless/rtlwifi/usb.c 2013-01-14 16:05:58.000000000 +0000
+++ b/drivers/net/wireless/rtlwifi/usb.c 2013-02-09 09:01:44.196641839 +0000
@@ -92,6 +92,21 @@
return rc;
}

+int _usbctrl_vendorreq_sync_write(struct usb_device *udev, u8 request,
+ u16 value, u16 index, void *pdata,
+ u16 len)
+{
+ unsigned int pipe;
+ int status;
+ u8 reqtype;
+
+ pipe = usb_sndctrlpipe(udev, 0);
+ reqtype = REALTEK_USB_VENQT_WRITE;
+ status = usb_control_msg(udev, pipe, request, reqtype, value,
+ index, pdata, len, 200); /*max. timeout*/
+ return status;
+}
+
static int _usbctrl_vendorreq_sync_read(struct usb_device *udev, u8 request,
u16 value, u16 index, void *pdata,
u16 len)
@@ -107,7 +122,7 @@

do {
status = usb_control_msg(udev, pipe, request, reqtype, value,
- index, pdata, len, 0); /*max. timeout*/
+ index, pdata, len, 200); /*max. timeout*/
if (status < 0) {
/* firmware download is checksumed, don't retry */
if ((value >= FW_8192C_START_ADDRESS &&
@@ -173,9 +188,15 @@
request = REALTEK_USB_VENQT_CMD_REQ;
index = REALTEK_USB_VENQT_CMD_IDX; /* n/a */
wvalue = (u16)(addr&0x0000ffff);
- data = cpu_to_le32(val);
+ data = (0xffffffff >> ((4 - len) * 8)) & cpu_to_le32(val);
+
+#if 1 // ARCH_BCM2708 - temporary fix do not merge.
+ _usbctrl_vendorreq_sync_write(udev, request, wvalue, index, &data,
+ len);
+#else
_usbctrl_vendorreq_async_write(udev, request, wvalue, index, &data,
- len);
+ len);
+#endif
}

static void _usb_write8_async(struct rtl_priv *rtlpriv, u32 addr, u8 val)

[stmayer]

Hi,

have you guys gone any further with this? I have a D-link DWA-121 (rev A1) which also need the rtl8192cu driver to be able to go in monitor mode.

br,

[hexameron]

It seems to be working, but I have not done much testing. I can bring up hostapd and ssh into it, and there is a monitor mode alongside the AP.


mon.wlan0 Link encap:UNSPEC HWaddr 94-44-52-C4-5E-A0-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:116 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13032 (12.7 KiB) TX bytes:0 (0.0 B)

[TheOnly]

@hexameron,
Thanks a lot for your effort in trying to correct the issue! I really wish I could help solve the problem but, unfortunately, my RPi is not at hand and neither is the dongle. I will try to test this and post some feedback as soon as I can, though I cannot yet give a specific date...

[Cloudcentric]

I have a generic USB WiFi Dongle RTL8188CUS which uses the 8192 Module and since a fresh install of Raspbian
with the latest .IMG 07/02/2013 it is working better than ever plugged into a Mains Powered USB Hub.

http://downloads.raspberrypi.org/images/raspbian

[ 7.086028] usbcore: registered new interface driver rtl8192cu

Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

wlan0 IEEE 802.11bgn ESSID:"TALKTALK-58B9C0" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.412 GHz Access Point: AC:E2:15:58:B9:C2
Bit Rate:150 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=62/100 Signal level=29/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

[TheOnly]

@Cloudcentric,
Are you using the 8192cu.ko module which ships with Raspbian or are you using the rtl8192cu module that's part of the rtlwifi set? This thread is about the latter, as it has been adapted to work with nl80211 allowing for bringing the device up in both monitor mode, as well as AP mode (with the help of hostapd) whereas the 8192cu module does not provide these features, unless hostapd is patched and recompiled.

If you're using rtlwifi, then I guess that's really good news if it works just out of the box. Please confirm if this is the case (you can check which module you're using with "lsmod").

[Cloudcentric]

Sorry, my bad, I just assumed that as the connection was more stable at a constant 150M b/s there would of been a new module

modinfo 8192cu
filename: /lib/modules/3.6.11+/kernel/drivers/net/wireless/rtl8192cu/8192cu.ko
version: v3.4.3_4369.20120622
author: Realtek Semiconductor Corp.
description: Realtek Wireless Lan Driver
license: GPL
srcversion: 323C69D9736BAE654F63B07



wpagui is at version 1.03 (testing)

[hexameron]

If it says ...Nickname:"<WIFI@REALTEK>"..., that is the 8192cu driver. The usb parts of rtl8192cu are based on the same code, but enable ASYNC writes, which seems to work on everything except a Raspberry Pi. It is quite easy to switch back to synchronous writes when you realise what they have done. I heard a rumor that there were some improvements to the RPi USB drivers coming soon, which may help .

Anyone who builds their own kernel can use the patch above, but there are some useful fixes in Linux 3.8 that you may also want. I will put some code on Github in a day or two.

[hexameron]

I have put my source code at " github.com/hexameron/rtlwifi ", but I have not been able to build modules against an existing Raspberry Pi kernel so I am only offering the source code.

All I can say is that it works for me.

[hexameron]

I have now built modules for current (3.6.11+) kernels. I get some warnings about unknown symbols, but that does not seem to be a problem. I was able to download/build aircrack_ng, and it is currently injecting packets into my network.

Kernel modules now included with source at: https://github.com/hexameron/rtlwifi/archive/master.zip

I am confident that the Raspberry Pi USB drivers will soon be fixed, and we will be able to use in-tree rtl8192cu modules without having to patch the driver.

[stmayer]

hexameron thank you for the usb issue patch!

I can confirm that it works for me in monitor mode (have not tested other modes yet).

I am running Arch linux:
Linux alarmpi 3.6.11-6-ARCH+ #2 PREEMPT Thu Feb 14 22:11:15 GMT 2013 armv6l GNU/Linux.

[hexameron]

I was right the first time .... it is a DMA alignment problem, not just on the Pi. There is a patch working it`s way into Linux; I will submit a pull request when I have looked into it further.

[stmayer]

Thank you!

Just a question, the trl8192cu is better than the one that comes with RPi because of many things it can run in monitor mode.

But what does monitor mode means exactly? I can only see beacon frame and data frames that are sent with broadcast address, why can't I see all traffic?

for example I only see ARP broadcast and no ARP reply. Why?

br,

[hexameron]

Sometimes it works well for a while, but it is still broken. I wasted a lot of time trying different things because I thought it was working better than it actually was.

One bug has been found, but there is still work to do.