Driver rtl8821cu in raspberry

  • Some wireless devices mount as a read-only CDROM (so Windows drivers can be installed) and they need to be modeswitched or the "CD" needs to be ejected before the actual NIC shows up. See what happens in dmesg if you "eject /dev/sr0" from the command line. If that works (and the NIC appears) it's an easy task to write a udev rule that does this automagically when the USB ID is seen. Some/most of devices that do this also have a Windows utility app that allows the initial CDROM mode to be permanently disabled.

  • I was going to ask about this device also! I just bought this USB Wi-Fi device which does 5GHZ hoping to get some speed improvement for a RPi3 at locations not easy to use a RJ45 cable. A Fire Stick running Kodi at the same location as the RPi3 gives very good download speed for playback as it uses 5GHZ but the RPi3 only uses 2.4 GHZ which gives too much buffering. This device has external aerial which I hoped would give better performance than the RPi3 internal 5GHZ aerial!

    As has been said the supplied Linux drivers dont work with recent versions of Linux but I found the modified drivers on Github mentioned in the first post. On my Ubuntu 18.04 PC the driver installed without error and finds the USB Wi-Fi device which runs at 5GHZ. The default platform to make a driver for is a PC but there are numerous other options including to make for a RPi and RPi3 so I created a Raspbian SD card and tried to install the driver as mentioned above by Iridium. Making for RPi3 the first error was that /lib/modules/4.14.79-v7+/build could not be found so created the "build" directory which was not a good start!!

    Typing "make " again:-

    pi@raspberrypi:~/Downloads/rtl8821CU-master $ make

    /bin/sh: 1: bc: not found

    make ARCH=arm64 CROSS_COMPILE= -C /lib/modules/4.14.79-v7+/build M=/home/pi/Downloads/rtl8821CU-master modules

    make[1]: Entering directory '/lib/modules/4.14.79-v7+/build'

    make[1]: *** No rule to make target 'modules'. Stop.

    make[1]: Leaving directory '/lib/modules/4.14.79-v7+/build'

    Makefile:1923: recipe for target 'modules' failed

    make: *** [modules] Error 2

    This error exceeds my level of incompetence on the subject so gave up!!

    Chris

  • In raspbian is working, compiling and using the command 'sudo usb_modeswitch -KW -v 0bda -p 1a2b'

    In this repo GitHub - uzh-rpg/rpg_dwa171_wifidongle: Realtek 802.11ac USB WLAN driver there is a script to not use previous command.

    Install bc, and use 'make ARCH=arm'

  • Well I have my rtl8821CU USB Wi-Fi device working on a RPi3 running Raspbian! The first problem is that Raspbian has no source code installed needed to build modules! Luckily someone on Stack Exchange had a similar problem and was given a list of 10 lines of commands to solve the problem which I copied and pasted into a terminal. That still gave an error then noticed the advice to use 'make ARCH=arm'. I had selected the RPi3 option in the Makefile which selected Arm64 which I did wonder about as I didnt think there was 64bit Raspbian. Using the "arm" option the driver was created and installed.Both versions of the driver on Github seemed to work exactly the same.

    It seems much more sensitive than the Wi-Fi built in RPi3B+ as it finds many more local Wi-Fi routers. However when it switches to 5GHz the signal strength drops dramatically and the connection drops out after a few minutes. Although its better than the 5GHZ Wi-Fi in the RPi3 the 5GHZ signal strength in that particular location is just too low so will find another solution to get more speed at that location.

    Thanks for your help!

    Chris

  • It seems much more sensitive than the Wi-Fi built in RPi3B+ as it finds many more local Wi-Fi routers. However when it switches to 5GHz the signal strength drops dramatically and the connection drops out after a few minutes. Although its better than the 5GHZ Wi-Fi in the RPi3 the 5GHZ signal strength in that particular location is just too low so will find another solution to get more speed at that location.

    Interesting. So, receiving signals works fine, but sending signals fails. Because sending signals needs more wattage, it might be a PSU issue.