Odroid XU4 + WiFi USB dongle Realtek RTL8812AU

[Alex Kholodkov]

Hello,

I had succeeded install last version of Armbian on Odroid XU4.
I have WiFi USB dongle Realtek RTL8812AU chipset (ID = 0bda:8812)

I see it  

$ lsusb
Bus 003 Device 003: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
$ dmesg | grep -i usb
[    9.630704] [c5] RTL871X: rtl8812au v4.2.5_10143.20140103_ASUS
[    9.887562] [c5] usbcore: registered new interface driver rtl8812au
[18812.680134] [c2] RTL871X: nolinked power save leave

but no Wifi interface

Could anyone please help solve it

[BigG2017]

Did you figure out this issue?  I have been considering buying this dongle since my current Realtek N dongle intermittently drops the signal on Armbian Ubuntu zenial mainline...not sure if the OS is actually the problem.

[Igor]

6 hours ago, BigG2017 said:

not sure if the OS is actually the problem.

In most cases, problems are drivers and WiFi drivers are among most critical ones. It's actually hard to find a good working one.  RTL8812AU was working fine on my brief testing ... but don't actually use it.

 

Not with build in driver, but with this one: https://github.com/gnab/rtl8812au It's easy to compile within armbian, just blacklist the on which is build in if necessary. And make sure you have good - original power supply, USB3 powering is a must.

[BigG2017]

Thanks!  I appreciate your help.

[tkaiser]

This should work in both Debian Jessie and Ubuntu Xenial:

git clone https://github.com/gnab/rtl8812au
sed -i -e 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/' \
    -e 's/CONFIG_PLATFORM_ARM_RPI = n/CONFIG_PLATFORM_ARM_RPI = y/' rtl8812au/Makefile
sudo apt install build-essential dkms
sudo mv rtl8812au /usr/src/8812au-4.2.2
sudo dkms add -m 8812au -v 4.2.2
sudo dkms build -m 8812au -v 4.2.2
sudo dkms install -m 8812au -v 4.2.2

And this is the result:

root@clearfogpro:~# iwconfig wlan0
wlan0     IEEE 802.11an  ESSID:"Snort-Honeynet 5GHz"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.2 GHz  Access Point: BC:05:43:BE:C1:E3   
          Bit Rate:300 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=68/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

 

[BigG2017]

Thanks again.  On a separate but related note, I'm having issues maintaining wifi connectivity using the latest Armbian mainline (zenial based) with the Airlink101 Wireless N 150 Mini USB Adapter.  It worked fine with my Raspberry Pi3, but it frequently disconnects, and I have to manual reconnect frequently.  'lsusb' identifies it as "Realtek RTL8188CUS".  Any ideas on how to fix this issue?

[BigG2017]

Well, I couldn't determine the cause of signal dropping with the Airlink (RTL 8188CUS), so I took the somewhat easier way out and purchased a similar USB wifi adapter used on this thread with the RTL8812AU.  So far, I haven't experience any drops.

 @tkaiserThanks for the command line help!

[vitaly]

I did not tested myself yet, but RTL8811AU is more cheap alternative to RTL8812AU.

 

My devices are listed as "0bda:a811 Realtek Semiconductor Corp.", this id already exists in driver, discussed in this thread.

[Igor]

With Hardkernel driver, 8811AU is not working, while it works with ours. In Odroid 4.9 kernel it was added 10 days ago and is only present in automated nightly builds.

[AlexisTM]

@Igor Does that means this issue https://github.com/gordboy/rtl8812au/issues/1 is not present on armbian with the rtl8814AU driver? 

 

Is there any other way to obtain the used rtl8814AU driver than applying the patch to the Odroid kernel? 

 

I have both rtl8811au and rtl8821au devices having a glitch.

[Igor]

3 minutes ago, AlexisTM said:

is not present on armbian with the rtl8814AU driver?

I haven't noticed anything like that but this doesn't mean it is not present. There is only one way - to test closely but I can do that fastest once next week.

Odroid kernel doesn't have support for 8814au either IIRC, only 8812au.

[AlexisTM]

Thanks

 

I just installed one armbian image on one of the odroids and will test the dongles. 

 

NOTE: I use DKMS to install the modules missing. 

[AlexisTM]

@Igor Sad news. Same glitch on the armbian image. :/ 

 

TP-Link Archer T4U AC1200 (RTL8821au) on armbian: https://pastebin.com/6erHF6wY

Odroid Module 4 (RT5572N) has horrible bad results on both images, this sample is on armbian:  https://pastebin.com/Rp64npD2

This glitch is not happening on the Odroid Module 3 (RTL8188CUS) on Kernel 4.15.103.

[Igor]

 

Thanks. We are using those sources: https://github.com/aircrack-ng/rtl8812au ... check if its already fixed, then we can bring them into the kernel and push an update.

[Igor]

@AlexisTM

Odroid XU4 4.9.y

Spoiler

64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=1.35 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=1.47 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=1.55 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=1.24 ms
64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=1.25 ms
64 bytes from 172.16.100.1: icmp_seq=7 ttl=64 time=1.25 ms
64 bytes from 172.16.100.1: icmp_seq=8 ttl=64 time=1.47 ms
64 bytes from 172.16.100.1: icmp_seq=9 ttl=64 time=1.60 ms
64 bytes from 172.16.100.1: icmp_seq=10 ttl=64 time=1.21 ms
64 bytes from 172.16.100.1: icmp_seq=11 ttl=64 time=1.94 ms
64 bytes from 172.16.100.1: icmp_seq=12 ttl=64 time=1.28 ms
64 bytes from 172.16.100.1: icmp_seq=13 ttl=64 time=1.41 ms
64 bytes from 172.16.100.1: icmp_seq=14 ttl=64 time=1.16 ms
64 bytes from 172.16.100.1: icmp_seq=15 ttl=64 time=1.52 ms
64 bytes from 172.16.100.1: icmp_seq=16 ttl=64 time=1.18 ms
64 bytes from 172.16.100.1: icmp_seq=17 ttl=64 time=1.18 ms
64 bytes from 172.16.100.1: icmp_seq=18 ttl=64 time=1.25 ms
64 bytes from 172.16.100.1: icmp_seq=19 ttl=64 time=1.21 ms
64 bytes from 172.16.100.1: icmp_seq=20 ttl=64 time=1.17 ms
64 bytes from 172.16.100.1: icmp_seq=21 ttl=64 time=1.18 ms
64 bytes from 172.16.100.1: icmp_seq=22 ttl=64 time=2.20 ms
64 bytes from 172.16.100.1: icmp_seq=23 ttl=64 time=1.25 ms
64 bytes from 172.16.100.1: icmp_seq=24 ttl=64 time=1.24 ms
64 bytes from 172.16.100.1: icmp_seq=25 ttl=64 time=1.15 ms
64 bytes from 172.16.100.1: icmp_seq=26 ttl=64 time=1.19 ms
64 bytes from 172.16.100.1: icmp_seq=27 ttl=64 time=1.34 ms

 

 

 

Cubox 4.14.18

Spoiler

64 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=2.34 ms
64 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=2.47 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=2.70 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=2.27 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=2.55 ms
64 bytes from 172.16.100.1: icmp_seq=6 ttl=64 time=2.41 ms
64 bytes from 172.16.100.1: icmp_seq=7 ttl=64 time=2.63 ms
64 bytes from 172.16.100.1: icmp_seq=8 ttl=64 time=4.95 ms
64 bytes from 172.16.100.1: icmp_seq=9 ttl=64 time=2.57 ms
64 bytes from 172.16.100.1: icmp_seq=10 ttl=64 time=2.70 ms
64 bytes from 172.16.100.1: icmp_seq=11 ttl=64 time=2.89 ms
64 bytes from 172.16.100.1: icmp_seq=12 ttl=64 time=2.47 ms
64 bytes from 172.16.100.1: icmp_seq=13 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=14 ttl=64 time=2.33 ms
64 bytes from 172.16.100.1: icmp_seq=15 ttl=64 time=2.32 ms
64 bytes from 172.16.100.1: icmp_seq=16 ttl=64 time=2.54 ms
64 bytes from 172.16.100.1: icmp_seq=17 ttl=64 time=2.55 ms
64 bytes from 172.16.100.1: icmp_seq=18 ttl=64 time=2.58 ms
64 bytes from 172.16.100.1: icmp_seq=19 ttl=64 time=2.57 ms
64 bytes from 172.16.100.1: icmp_seq=20 ttl=64 time=2.40 ms
64 bytes from 172.16.100.1: icmp_seq=21 ttl=64 time=2.55 ms
64 bytes from 172.16.100.1: icmp_seq=22 ttl=64 time=2.54 ms
64 bytes from 172.16.100.1: icmp_seq=23 ttl=64 time=2.67 ms
64 bytes from 172.16.100.1: icmp_seq=24 ttl=64 time=2.38 ms
64 bytes from 172.16.100.1: icmp_seq=25 ttl=64 time=2.41 ms
64 bytes from 172.16.100.1: icmp_seq=26 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=27 ttl=64 time=2.43 ms
64 bytes from 172.16.100.1: icmp_seq=28 ttl=64 time=2.28 ms
64 bytes from 172.16.100.1: icmp_seq=29 ttl=64 time=2.54 ms
64 bytes from 172.16.100.1: icmp_seq=30 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=31 ttl=64 time=2.41 ms
64 bytes from 172.16.100.1: icmp_seq=32 ttl=64 time=2.72 ms
64 bytes from 172.16.100.1: icmp_seq=33 ttl=64 time=5.14 ms
64 bytes from 172.16.100.1: icmp_seq=34 ttl=64 time=2.32 ms
64 bytes from 172.16.100.1: icmp_seq=35 ttl=64 time=2.51 ms
64 bytes from 172.16.100.1: icmp_seq=36 ttl=64 time=2.46 ms
64 bytes from 172.16.100.1: icmp_seq=37 ttl=64 time=4.58 ms
64 bytes from 172.16.100.1: icmp_seq=38 ttl=64 time=2.47 ms
64 bytes from 172.16.100.1: icmp_seq=39 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=40 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=41 ttl=64 time=2.44 ms
64 bytes from 172.16.100.1: icmp_seq=42 ttl=64 time=2.38 ms
64 bytes from 172.16.100.1: icmp_seq=43 ttl=64 time=2.55 ms
64 bytes from 172.16.100.1: icmp_seq=44 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=45 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=46 ttl=64 time=2.53 ms
64 bytes from 172.16.100.1: icmp_seq=47 ttl=64 time=2.43 ms
64 bytes from 172.16.100.1: icmp_seq=48 ttl=64 time=2.44 ms
64 bytes from 172.16.100.1: icmp_seq=49 ttl=64 time=2.41 ms
64 bytes from 172.16.100.1: icmp_seq=50 ttl=64 time=2.28 ms
64 bytes from 172.16.100.1: icmp_seq=51 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=52 ttl=64 time=2.40 ms
64 bytes from 172.16.100.1: icmp_seq=53 ttl=64 time=2.61 ms
64 bytes from 172.16.100.1: icmp_seq=54 ttl=64 time=2.51 ms
64 bytes from 172.16.100.1: icmp_seq=55 ttl=64 time=2.41 ms
64 bytes from 172.16.100.1: icmp_seq=56 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=57 ttl=64 time=2.39 ms
64 bytes from 172.16.100.1: icmp_seq=58 ttl=64 time=2.43 ms
64 bytes from 172.16.100.1: icmp_seq=59 ttl=64 time=5.81 ms
64 bytes from 172.16.100.1: icmp_seq=60 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=61 ttl=64 time=2.54 ms
64 bytes from 172.16.100.1: icmp_seq=62 ttl=64 time=2.71 ms
64 bytes from 172.16.100.1: icmp_seq=63 ttl=64 time=3.32 ms
64 bytes from 172.16.100.1: icmp_seq=64 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=65 ttl=64 time=2.57 ms
64 bytes from 172.16.100.1: icmp_seq=66 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=67 ttl=64 time=2.45 ms
64 bytes from 172.16.100.1: icmp_seq=68 ttl=64 time=2.45 ms
64 bytes from 172.16.100.1: icmp_seq=69 ttl=64 time=2.57 ms
64 bytes from 172.16.100.1: icmp_seq=70 ttl=64 time=2.65 ms
64 bytes from 172.16.100.1: icmp_seq=71 ttl=64 time=2.45 ms
64 bytes from 172.16.100.1: icmp_seq=72 ttl=64 time=2.52 ms
64 bytes from 172.16.100.1: icmp_seq=73 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=74 ttl=64 time=2.45 ms
64 bytes from 172.16.100.1: icmp_seq=75 ttl=64 time=2.80 ms
64 bytes from 172.16.100.1: icmp_seq=76 ttl=64 time=2.72 ms
64 bytes from 172.16.100.1: icmp_seq=77 ttl=64 time=2.66 ms
64 bytes from 172.16.100.1: icmp_seq=78 ttl=64 time=2.31 ms
64 bytes from 172.16.100.1: icmp_seq=79 ttl=64 time=2.65 ms
64 bytes from 172.16.100.1: icmp_seq=80 ttl=64 time=2.54 ms
64 bytes from 172.16.100.1: icmp_seq=81 ttl=64 time=2.38 ms
64 bytes from 172.16.100.1: icmp_seq=82 ttl=64 time=2.29 ms
64 bytes from 172.16.100.1: icmp_seq=83 ttl=64 time=2.55 ms
64 bytes from 172.16.100.1: icmp_seq=84 ttl=64 time=2.27 ms
64 bytes from 172.16.100.1: icmp_seq=85 ttl=64 time=7.72 ms
64 bytes from 172.16.100.1: icmp_seq=86 ttl=64 time=2.31 ms
64 bytes from 172.16.100.1: icmp_seq=87 ttl=64 time=2.58 ms
64 bytes from 172.16.100.1: icmp_seq=88 ttl=64 time=2.29 ms
64 bytes from 172.16.100.1: icmp_seq=89 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=90 ttl=64 time=4.36 ms
64 bytes from 172.16.100.1: icmp_seq=91 ttl=64 time=2.73 ms
64 bytes from 172.16.100.1: icmp_seq=92 ttl=64 time=2.42 ms
64 bytes from 172.16.100.1: icmp_seq=93 ttl=64 time=2.30 ms
64 bytes from 172.16.100.1: icmp_seq=94 ttl=64 time=2.55 ms

 

 

 

It looks normal, no glitch. This driver update was already pushed into most kernels. Same results with 8814 or 8812, both test were made on 2.4 band.

[AlexisTM]

@Igor Yours has no issue so far

Could you provide me with the details of the USB adapter you are using so that I can buy the same ones

[Igor]

Bus 001 Device 010: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Bus 001 Device 008: ID 0bda:a811 Realtek Semiconductor Corp.
Bus 001 Device 012: ID 0bda:8813 Realtek Semiconductor Corp.

Serial #

[ 1560.988790] usb 1-1.4.4.2: Product: 802.11ac NIC
[ 1560.988802] usb 1-1.4.4.2: Manufacturer: Realtek
[ 1560.988813] usb 1-1.4.4.2: SerialNumber: 123456

 

8814  https://www.gearbest.com/network-cards/pp_625323.html 

8811 https://www.gearbest.com/network-cards/pp_613225.html 

8812 is no name from eBay. It looks like this one.

 

Try again building from sources, Odroid XU4 NEXT ... I just pushed patches up. Those are tested.

[funkypunkskunk]

On 4/15/2017 at 12:50 PM, tkaiser said:

This should work in both Debian Jessie and Ubuntu Xenial:

git clone https://github.com/gnab/rtl8812au
sed -i -e 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/' \
    -e 's/CONFIG_PLATFORM_ARM_RPI = n/CONFIG_PLATFORM_ARM_RPI = y/' rtl8812au/Makefile
sudo apt install build-essential dkms
sudo mv rtl8812au /usr/src/8812au-4.2.2
sudo dkms add -m 8812au -v 4.2.2
sudo dkms build -m 8812au -v 4.2.2
sudo dkms install -m 8812au -v 4.2.2

And this is the result:

root@clearfogpro:~# iwconfig wlan0
wlan0     IEEE 802.11an  ESSID:"Snort-Honeynet 5GHz"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.2 GHz  Access Point: BC:05:43:BE:C1:E3   
          Bit Rate:300 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=68/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

 

 

Sorry if i'm an idiot but I can't compile that driver on my system. Relevant armbianmonitor -U https://pastebin.com/6Q9Rhjay

 

And this is the error log:

KMS make.log for 8812au-4.2.2 for kernel 4.4.167-rockchip64 (aarch64)
Fri Jan 11 10:06:21 UTC 2019
make ARCH=arm CROSS_COMPILE= -C /lib/modules/4.4.167-rockchip64/build M=/var/lib/dkms/8812au/4.2.2/build  modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.167-rockchip64'
  CC [M]  /var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o
gcc: error: unrecognized argument in option ‘-mabi=apcs-gnu’
gcc: note: valid arguments to ‘-mabi=’ are: ilp32 lp64
gcc: error: unrecognized command line option ‘-mapcs’; did you mean ‘--specs’?
gcc: error: unrecognized command line option ‘-mno-sched-prolog’; did you mean ‘-Wno-sign-promo’?
gcc: error: unrecognized command line option ‘-msoft-float’
scripts/Makefile.build:277: recipe for target '/var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o' failed
make[2]: *** [/var/lib/dkms/8812au/4.2.2/build/core/rtw_cmd.o] Error 1
Makefile:1493: recipe for target '_module_/var/lib/dkms/8812au/4.2.2/build' failed
make[1]: *** [_module_/var/lib/dkms/8812au/4.2.2/build] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.167-rockchip64'
Makefile:1064: recipe for target 'modules' failed
make: *** [modules] Error 2

Is this related to settings in gcc? I can't seem to find a google answer to the error message either. Any clue as where to begin reading?

 

 

 

 

[Igor]

14 minutes ago, funkypunkskunk said:

Sorry if i'm an idiot but I can't compile that driver on my system.

 

No, it's a known problem - driver compilation breaks on aarch64 kernel version 4.4.y only. We pack this driver (a better version of it) inside all kernels but 4.4.y since we don't have resources to fix 3rd party wireless drivers. Sometimes yes, but generally no.

[funkypunkskunk]

2 hours ago, Igor said:

 

No, it's a known problem - driver compilation breaks on aarch64 kernel version 4.4.y only. We pack this driver (a better version of it) inside all kernels but 4.4.y since we don't have resources to fix 3rd party wireless drivers. Sometimes yes, but generally no.

 

Thanks Igor for the answer. I've been reading a lot of other forum replies by you and tkaiser and you are generally helpful despite the overwhelming amount of questions you get on this forum.

 

I have a tinkerboard and my usb wifi works great there (with armbian) and i've been trying to figure out what the problem could be.

 

Is there a roadmap to up the kernel version or should i just go for another distro, or check if I can resolve it myself?

 

 

[Igor]

12 minutes ago, funkypunkskunk said:

Is there a roadmap to up the kernel version or should i just go for another distro

Other distros are far behind and they surely weren't able to solve such problems. Just to save you time lost on "distro hopping".  If you want to run this wireless chip OOB - all you need to do is to upgrade a kernel to 4.19.y. armbian-config -> beta repository (reboot and once again) -> alternative kernels -> DEV. But it is beta ... no need to search around. This is the best possible atm.

We will perhaps create roadmaps, when projects costs will not be almost fully on our private cash.

[funkypunkskunk]

6 minutes ago, Igor said:

Other distros are far behind and they surely weren't able to solve such problems. Just to save you time lost on "distro hopping".  If you want to run this wireless chip OOB - all you need to do is to upgrade a kernel to 4.14.y  or to 4.19.y (in a few days). armbian-config -> alternative kernels -> DEV. But it is beta ... 

We will perhaps create roadmaps, when projects costs will not be almost fully on our private cash.

 

Thanks! I've made a small donation for the effort you are doing. I'll be sure to try the devel-kernel in a few days.

[Igor]

On 1/11/2019 at 1:35 PM, funkypunkskunk said:

but I can't compile that driver on my system.

 

New driver is coming: https://github.com/armbian/build/commit/9758711ed42e345453eddc4b3314f8eaf81d01b5

 

Also working fine on 4.4.y kernels.

[funkypunkskunk]

On 2/7/2019 at 3:36 PM, Igor said:

 

New driver is coming: https://github.com/armbian/build/commit/9758711ed42e345453eddc4b3314f8eaf81d01b5

 

Also working fine on 4.4.y kernels.

 

I tried the tinkerboard and starting an access point via USB Wifi works just fine there. I've experienced no problems with different computers and phones.

 

Using the same dongle for Wifi to create an access point with the rock64 isn't really as stable.. don't know what the problem might be. Connections are broken for some devices, and sometimes it's impossible to log on to the access point.

 

So for the tinkerboard it works just fine, not so much for the rock64. If the drivers are fine then it's probably some other software related problems.

 

Thanks for the update Igor!