Package Details: rtl8821au-dkms-git 5.1.5.r59.gaf07b27-1

Git Clone URL: https://aur.archlinux.org/rtl8821au-dkms-git.git (read-only, click to copy)
Package Base: rtl8821au-dkms-git
Description: rtl8821AU, rtl8812AU and rtl8811AU chipset driver with firmware v5.1.5
Upstream URL: https://github.com/zebulon2/rtl8812au/tree/v5.1.5
Licenses: GPL2
Conflicts: rtl8821au
Submitter: zebulon
Maintainer: zebulon
Last Packager: zebulon
Votes: 45
Popularity: 0.000019
First Submitted: 2017-09-12 06:28
Last Updated: 2018-04-03 08:35

Dependencies (3)

Required by (0)

Sources (2)

Pinned Comments

zebulon commented on 2019-10-01 06:18

To all having an issue with this driver: please try https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git alternatively.

solstice commented on 2019-03-17 10:59

a patch to make it work for rpi and may be other ARM device:

--- PKGBUILD.old    2019-03-15 20:08:05.345042676 +0100
+++ PKGBUILD    2019-03-15 20:04:24.390294977 +0100
@@ -32,4 +32,10 @@
         sed -e "s/@_PKGBASE@/${_pkgbase}-dkms/" \
                         -e "s/@PKGVER@/${pkgver}/" \
                         -i "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
+
+   # patch Makefile for RPI
+   sed -i '/^CONFIG_PLATFORM_I386_PC/s/y/n/' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/Makefile
+   sed -i '/^CONFIG_PLATFORM_ARM_RPI/s/n/y/' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/Makefile
+   # disable debug code with __DATE__ macro (TODO: proper fix ?)
+   sed -i '/__DATE__/s/^/\/\//' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/core/rtw_debug.c
 }

Note: I am seeing the interface of the usb wifi key marketed as DEEPOW dongle (from amazon) changing MAC address at every boot even though I have not set up anything like that in netctl, here.

I don't know if it's a hardware problem or driver problem. However, it's the same with rtl88xxau-aircrack-dkms-git driver

Latest Comments

1 2 3 4 5 6 ... Next › Last »

jonathon commented on 2020-11-18 23:18

@zebulon, you could always change the upstream to one that works rather than remove the package? And, so there's no conflict with rtl88xxau-aircrack-dkms-git this one could provide the v5.3.4 branch?

zebulon commented on 2020-08-24 11:18

Hello everybody, I think it is time to retire this package and direct users to the more recent rtl88xxau-aircrack-dkms-git package. Any suggestion against this?

longboardtard commented on 2020-04-05 06:06

Based on @solstice's pinned comment and as of today, this is a working patch for the RBPI. I'm simply adding 'armv7h' to the architecture list:

patch

--- PKGBUILD.orig       2020-04-05 00:37:13.005642118 -0500
+++ PKGBUILD    2020-04-05 00:38:58.003792205 -0500
@@ -6,7 +6,7 @@
 pkgver=5.1.5.r59.gaf07b27
 pkgrel=1
 pkgdesc="rtl8821AU, rtl8812AU and rtl8811AU chipset driver with firmware v5.1.5"
-arch=('i686' 'x86_64')
+arch=('i686' 'x86_64' 'armv7h')
 url="https://github.com/zebulon2/rtl8812au/tree/v5.1.5"
 license=('GPL2')
 depends=('dkms' 'bc')
@@ -32,4 +32,10 @@
         sed -e "s/@_PKGBASE@/${_pkgbase}-dkms/" \
                         -e "s/@PKGVER@/${pkgver}/" \
                         -i "${pkgdir}"/usr/src/${_pkgbase}-${pkgver}/dkms.conf
+
+   # patch Makefile for RPI
+   sed -i '/^CONFIG_PLATFORM_I386_PC/s/y/n/' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/Makefile
+   sed -i '/^CONFIG_PLATFORM_ARM_RPI/s/n/y/' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/Makefile
+   # disable debug code with __DATE__ macro (TODO: proper fix ?)
+   sed -i '/__DATE__/s/^/\/\//' ${pkgdir}/usr/src/${_pkgbase}-${pkgver}/core/rtw_debug.c
 }

I used a RPI 4 model B rev 1.1, with archlinuxarm (Linux rpi4 4.19.108-1-ARCH #1 SMP PREEMPT Tue Mar 10 02:06:04 UTC 2020 armv7l GNU/Linux) and an Ourlink AC600 Wireless USB adapter:

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 0bda:a811 Realtek Semiconductor Corp. RTL8811AU 802.11a/b/g/n/ac WLAN Adapter
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmesg

[ +25.852656] usb 1-1.4: new high-speed USB device number 7 using xhci_hcd
[  +0.140550] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=a811, bcdDevice= 2.00
[  +0.000042] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000030] usb 1-1.4: Product: 802.11ac WLAN Adapter 
[  +0.000024] usb 1-1.4: Manufacturer: Realtek 
[  +0.000022] usb 1-1.4: SerialNumber: 00e04c000001
[  +0.113350] usbcore: registered new interface driver 8812au

mrpanda commented on 2019-10-01 17:48

@zebulon Thanks already tried it same issue , for now I'm using different usb wifi module. If you can make the patch that will be awesome.

zebulon commented on 2019-10-01 06:18

To all having an issue with this driver: please try https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git alternatively.

zebulon commented on 2019-10-01 06:17

It looks like all rtl88xx drivers are having problem with 5.3.1 kernel. I am looking into this to see if we need a patch to handle a kernel API change.

henno commented on 2019-10-01 06:05

@mrpanda: I can confirm I am having the same experience.

mrpanda commented on 2019-09-30 22:36

Not working with Qoltec 57010 rtl8811au hardware on 5.3.1 no installation problems , but it seems that it has no power the indicator is dead. It seems that no Aur package is working for rtl8811au on 5.3.1.

zebulon commented on 2019-04-09 07:34

@jschuster: you are right, those are not even installed, they just stay in the src tree and are not used. The problem you describe is indeed very strange. You may want to ask on the forums, or on the ip developers mailing list.

jschuster commented on 2019-04-09 02:09

@zebulon I temporarily moved those files out from my /usr/src/rtl8821au-5.1.5.r78.gecd3494 directory (where pacman says they were installed) - is that what you meant? I can't tell if there's another step where they're "installed" from here, since I would expect this directory is only used for building source code, but I can't seem to find any step beyond this.

In any case, rebooting after moving those files didn't seem to affect anything. I'm connected to the network just fine, and I don't see anything suspicious in the system logs.