Package Details: rtl8814au-dkms-git 5.8.5.1.r98.gc5fd13c-2

Git Clone URL: https://aur.archlinux.org/rtl8814au-dkms-git.git (read-only, click to copy)
Package Base: rtl8814au-dkms-git
Description: RTL8814AU and RTL8813AU chipset driver with firmware v5.8.5.1
Upstream URL: https://github.com/morrownr/8814au
Licenses: GPL2
Conflicts: rtl8814au
Submitter: zebulon
Maintainer: zebulon (Frost)
Last Packager: zebulon
Votes: 22
Popularity: 0.71
First Submitted: 2017-09-18 20:21 (UTC)
Last Updated: 2021-06-06 20:15 (UTC)

Pinned Comments

zebulon commented on 2019-10-01 06:19 (UTC) (edited on 2022-05-02 09:13 (UTC) by zebulon)

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

Latest Comments

zebulon commented on 2022-05-02 09:13 (UTC)

@antoniovazquez: you are correct, aircrack have now split the repository for rtl8814au. I had updated the wiki page, but not the note above. I kept this PKGBUILD because it may be useful for people using an rtl8813au. I am unsure about the aircrack version in this aspect. But if they are redundant then I would seriously consider deprecating this one.

antoniovazquez commented on 2022-04-28 21:48 (UTC)

It seems this package rtl8814au-dkms-git suggests using rtl88xxau-aircrack-dkms-git although aircrack people have deprecated rtl8814 support from it and that package suggests using rtl8814au-aircrack-dkms-git. In the comments of the later, using this package is suggested which is confusing.

From what I have read either https://aur.archlinux.org/packages/rtl8814au-dkms-git or https://aur.archlinux.org/packages/rtl8814au-aircrack-dkms-git should be used. Please, remove pinned comments pointing to rtl88xxau-aircrack-dkms-git.

Thanks

zebulon commented on 2022-02-09 08:36 (UTC)

@nxsols and @antoniovazquez: many thanks for your feedback. Indeed these mistakes perpetuate in many repositories. I will try to correct them soon. Regarding ARM, unfortunately this is only 3rd party patches, since I do not own ARM based devices. Will look into the scripts though.

nxsols commented on 2022-02-04 18:14 (UTC)

The provided ARM patch is broken on Raspberry Pi and package build fails. Instead the repository provides scripts raspi32.sh and raspi64.sh for toggling build flags. I don't know how this affects other ARM platforms.

Also, the PKGBUILD tries to sed @_PKGBASE@ but it's set as @PKGBASE@ in the dkms.conf so that never actually gets replaced with anything.

antoniovazquez commented on 2021-07-15 20:33 (UTC)

This driver crashes for me while the aircrack version seems more stable. I will be patching the aircrack version with the following changes in order to keep using it with 5.12: https://github.com/aircrack-ng/rtl8814au/pull/64/files

antoniovazquez commented on 2021-07-15 20:03 (UTC)

Could you please add linux-headers to deps in order to avoid:

==> Unable to install module rtl8814au/5.8.5.1.r113.g9d55a15 for kernel *: Missing kernel headers.

frostwork commented on 2021-06-01 06:16 (UTC)

mhm

zebulon commented on 2021-06-01 04:46 (UTC)

I have updated to the morrownr Github repository.

frostwork commented on 2021-05-18 06:58 (UTC)

@zebulon just sent you a mail.

zebulon commented on 2021-05-17 21:39 (UTC)

@frostwork: would you like to maintain this package? If not, can you send me the PKGFILE, all credits will be due of course.

zebulon commented on 2021-05-17 21:37 (UTC)

@frostwork: thanks a lot and I apologise for the lack of updates. I have unfortunatelz little time to maintain this package, and also lack the hardware to test. I will try to update with your changes asap.

frostwork commented on 2021-05-17 09:57 (UTC)

Hi again. I rewrote this PKGBUILD to work with https://github.com/morrownr/8814au (only gave it a quick test, received my awus1900 today, and it works with it, so I assume it works). Changed I made were minimal. Is there any interest in merging the changes?

frostwork commented on 2021-05-17 09:26 (UTC)

I vote for a switch to https://github.com/morrownr/8814au as well as https://github.com/zebulon2/rtl8814au upstream looks dead and upstream for the other driver https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git is broken (in linux 5.12): https://github.com/aircrack-ng/rtl8814au/issues/61

b00rt00s commented on 2021-05-13 06:23 (UTC)

Hey, there is a repo https://github.com/morrownr/8814au that is actively developed. Maybe it would be good idea ti switch.

zebulon commented on 2021-02-15 12:57 (UTC)

@kmahyyg: thanks for your comments. Unfortunately I have no rtl8814au adapter that I could test and was maintaining these packages along with rtl8812au driver, but without any mean to solve issues like this. I can only recommend the aircrack driver for it, but it needs rtl8814au-aircrack from https://github.com/aircrack-ng/rtl8814au. Are you able to make it work?

Otherwise I have also switched to a PCIe AX200 from Intel, which works well. Of course this is not USB so maybe not a solution for everyone.

kmahyyg commented on 2021-02-14 15:13 (UTC)

I just skimmed all recently widely-used USB WLAN dual-band network interface. So sadly, since mt76 in Linux kernel is totally not working while Mediatek MT7612u is a good and cheap chipset but still got initialization failed. The proprietary one which called mtwifi has nobody to port it for general usage.

Then as always with the bad reputation of Realtek chipset, after a few years, it still has a super bad reputation. RTL88xxAU is not working for RTL8814AU, RTL8812AU is still not working on the most recent kernel (5.10.16 now). However, I still could see the maintainers still trying to port it for v5.11 kernel.

As for RTL8814AU, it just updated at Jan 2021, and no updates and nobody answers users' questions on upstream.

I'm really questioning about the future of both chipsets. Windows version driver is not working smoothly too, even in LAN, the latency of RTL chips still so high as about 20ms, but with Mediatek chip, just about 2~3 ms.

But for Linux, nothing can be used.

For god's sake and saving my life, I totally give up with those f**king wireless drivers.

As for Intel iwlwifi, My AC9260 Always get traffic stuck or sudden disconnected when using 5GHz bands.

Now, I just suggest everyone here, just drop those sh*ts and maybe Sh**tel and Qualcomm can be the only choices for saving everyone's life.

zebulon commented on 2020-12-26 19:41 (UTC) (edited on 2020-12-26 19:42 (UTC) by zebulon)

@intrepid: if it is working fine then I will use the next few days to update it. Thanks for reporting.

intrepid commented on 2020-10-26 07:23 (UTC)

Hello, rtl88xxau-aircrack-dkms-git dropped rtl8814au support.

It seems the driver from https://github.com/aircrack-ng/rtl8814au is working, testing it right now.

zebulon commented on 2020-08-24 11:18 (UTC)

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?

a_manthey commented on 2019-10-01 09:54 (UTC)

same issue with rtl88xxau-aircrack-dkms-git

zebulon commented on 2019-10-01 06:19 (UTC) (edited on 2022-05-02 09:13 (UTC) by zebulon)

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

zebulon commented on 2019-10-01 06:15 (UTC)

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.

aris commented on 2019-09-27 11:20 (UTC) (edited on 2019-09-27 11:30 (UTC) by aris)

I'd like to add to the comment by @a_manthey.

The driver indeed doesn't work on 5.3.1.

TP-Link Archer T9UH (AC1900) is not recognized anymore. It still shows up in the query lsusb. However, it fails to show up in the query iw dev.

a_manthey commented on 2019-09-24 17:40 (UTC) (edited on 2019-09-24 18:12 (UTC) by a_manthey)

Driver builds on 5.3 without errors

Edimax AC 1750 (id 7392:a833) is no longer recognized

lsusb runs infinitely without showing Edimax AC 1750 (id 7392:a833)

shutdown of pc and notebook stops at this point:

systemd-shutdown[1]: Syncing filesystems and blockdevices.

systemd-shutdown[1]: Sending SIGTERM to remainig processes ...

systemd-journald[557]: Received SIGTERM from PID 1 (systemd-shutdown).

systemd-shutdown[1]: waiting for process: systemd-udevd, systemd-udevd

systemd-udevd[593]: Giving up waiting for workers to finish.

systemd-udevd[593]: Event loop failed: Connection timed out

downgrade of systemd to 243.0-1 doesn't fix it.

nepenthe commented on 2019-07-10 13:48 (UTC)

@zebulon Build and Install looks clean - driver is functioning on 5.2.

Thank you!

zebulon commented on 2019-07-10 12:48 (UTC)

@nepenthe: I have merged the patch for 5.2 support. Please try again and let me know if this works. Thanks.

nepenthe commented on 2019-07-09 15:29 (UTC) (edited on 2019-07-09 15:33 (UTC) by nepenthe)

Here's what I saw in relation to kernel 5.2 -- ugh, formatting, looking at Wiki for formatting help.

(1/2) Install DKMS modules ==> dkms install rtl8814au/4.3.21.r47.g70f8d24 -k 5.2.0-0-MANJARO Error! Bad return status for module build on kernel: 5.2.0-0-MANJARO (x86_64) Consult /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/make.log for more information.

DKMS make.log for rtl8814au-4.3.21.r47.g70f8d24 for kernel 5.2.0-0-MANJARO (x86_64) Tue 09 Jul 2019 11:28:37 AM EDT make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.2.0-0-MANJARO/build M=/var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build modules make[1]: Entering directory '/usr/lib/modules/5.2.0-0-MANJARO/build' CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_cmd.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_security.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_debug.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_io.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ioctl_query.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ioctl_set.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ieee80211.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_mlme.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_mlme_ext.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_wlan_util.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_vht.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_pwrctrl.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_rf.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_recv.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_sta_mgt.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ap.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_xmit.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_p2p.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_tdls.o /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ap.c: In function ‘rtw_add_bcn_ie’: /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_ap.c:228:24: warning: ‘ielen’ may be used uninitialized in this function [-Wmaybe-uninitialized] 228 | if (p != NULL && ielen>0) | ~~~~~^~ CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_br_ext.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_iol.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_sreset.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_btcoex.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_beamforming.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/rtw_odm.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/core/efuse/rtw_efuse.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/osdep_service.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/os_intfs.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/usb_intf.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/usb_ops_linux.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/ioctl_linux.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/xmit_linux.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/mlme_linux.o /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/os_intfs.c:918:22: error: initialization of ‘u16 ()(struct net_device , struct sk_buff , struct net_device )’ {aka ‘short unsigned int ()(struct net_device , struct sk_buff , struct net_device )’} from incompatible pointer type ‘u16 ()(struct net_device , struct sk_buff , struct net_device , u16 ()(struct net_device , struct sk_buff , struct net_device ))’ {aka ‘short unsigned int ()(struct net_device , struct sk_buff , struct net_device , short unsigned int ()(struct net_device , struct sk_buff , struct net_device ))’} [-Werror=incompatible-pointer-types] 918 | .ndo_select_queue = rtw_select_queue, | ^~~~~~~~~~~~~~~~ /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/os_intfs.c:918:22: note: (near initialization for ‘rtw_netdev_ops.ndo_select_queue’) CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/recv_linux.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/ioctl_cfg80211.o CC [M] /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/rtw_cfgvendor.o cc1: some warnings being treated as errors make[2]: [scripts/Makefile.build:279: /var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build/os_dep/linux/os_intfs.o] Error 1 make[2]: Waiting for unfinished jobs.... make[1]: [Makefile:1595: module/var/lib/dkms/rtl8814au/4.3.21.r47.g70f8d24/build] Error 2 make[1]: Leaving directory '/usr/lib/modules/5.2.0-0-MANJARO/build' make: [Makefile:1699: modules] Error 2

zebulon commented on 2019-06-11 09:00 (UTC)

@andrej: can you copy the part of the log that shows the error? Thanks.

andrej commented on 2019-06-10 04:36 (UTC)

This just keeps failing to build via DKMS across a few last kernel versions. :-(

zebulon commented on 2019-05-16 09:51 (UTC)

Updated for kernel 5.1.

itsmattson commented on 2019-01-29 03:56 (UTC)

Thanks @zebulon! I learned something from that so I uninstalled it and reinstalled it your way via downloading snapshot, untarring, and using makepkg -i and r40 came down as you suggested which is great! I thought I had to go via github to get the latest because package details at the top of page says "rtl8814au-dkms-git 4.3.21.r34.ga0c4479-2". Apologies for the misunderstanding - This has certainly simplified AUR package updates for me :)

zebulon commented on 2019-01-28 15:16 (UTC)

@itsmattson: good to hear. Regarding the best practice: I think you confused the source for the driver and the source for the PKGBUILD. You do not need to git clone https://github.com/zebulon2/rtl8814au and make a package out of it, but only of the PKGBUILD snapshot https://aur.archlinux.org/cgit/aur.git/snapshot/rtl8814au-dkms-git.tar.gz which you untar somewhere and then run makepkg -i inside (as explained in the AUR wiki page). makepkg will handle the download of the source from github (the latest revision by default). The thing is, the PKGBUILD is not updated each time the Github driver source is (this is normal and an Arch guidance). Hence, if you wish to use the latest version of the driver, clean up your PKGBUILD snapshot folder (or reexpand it again) and run makepkg -i from time to time (or each time you see the Github driver has been updated). Hope this helps.

itsmattson commented on 2019-01-28 13:20 (UTC)

Hey @zebulon, on latest git pull a moment ago I got "rtl8814au-dkms-git-4.3.21.r40.ge217689-1" and it installed perfectly (the one I got the error with this afternoon was r35). Thank you! Any tips on how to know if latest kernel is supported before I do a system upgrade next time?

itsmattson commented on 2019-01-28 13:10 (UTC) (edited on 2019-01-28 13:22 (UTC) by itsmattson)

Thanks @zebulon!

I think I did it right so maybe you can tell me where I went wrong? Maybe I just tried to upgrade (git pull) too soon (before your merge) - Is that what you mean?

This is the order I did things: Updated system (sudo pacman -Syu), noticed Wi-Fi no longer working so pulled latest changes in cloned repo (git pull), remade the package (makepkg -Acs), and finally reinstalled it to Pacman (sudo pacman -U <package>.pkg.tar.xz). This was second time I got the error (first during pacman -Syu) so decided to come here and ask for help :p

Can I bother you to advise what best approach would be in future when looking to upgrade? Thanks!

zebulon commented on 2019-01-28 08:41 (UTC)

@itsmattson: I just read again your message. Indeed, you have the r35 version of the repository, that is before I merged the support for kernel 4.20 (see the source history at https://github.com/zebulon2/rtl8814au/commits/master). Note that AUR packages do not update automatically with pacman, and that secondly a -git package needs to be rerun some time to time to get the latest git sources, since the PKGBUILD is not necessarily changed, while the original sources are. I invite you to read the Wiki for more info about AUR, starting at https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages. Once you have well understood the concept, then you can use a pacman wrapper that helps installing AUR packages automatically, such as pikaur, but only after you have understood the "manual" way! ;)

zebulon commented on 2019-01-28 07:45 (UTC)

@itsmattson: normally support for 4.20 has been added. Looks it does not compile with 4.20.4, but I can only diagnose the problem if you give me the content of /var/lib/dkms/rtl8814au/4.3.21.r35.g7dde5bd/build/make.log. Can you please avoid pasting a long text here, and instead send a pastebin (or equivalent) link?

itsmattson commented on 2019-01-28 04:43 (UTC)

Made the decision to upgrade system via pacman -Syu, knowing I'd probably have issues with this package but did it anyway... but came across an issue I don't think I can fix myself. Part of the upgrade seems to have been Arch itself to 4.20.4. Any ideas?

(1/2) Install DKMS modules ==> dkms install rtl8814au/4.3.21.r35.g7dde5bd -k 4.20.4-arch1-1-ARCH Error! Bad return status for module build on kernel: 4.20.4-arch1-1-ARCH (x86_64) Consult /var/lib/dkms/rtl8814au/4.3.21.r35.g7dde5bd/build/make.log for more information. (2/2) Arming ConditionNeedsUpdate...

Thanks in advance!

zebulon commented on 2019-01-24 10:01 (UTC)

@SeeLook: you're welcome. When you say "before it just worked out of a box" you are probably speaking about another adapter, because the RTL88xxau USB adapters have never worked out of the box (i.e. the Linux kernel does not come with the drivers). I have another USB adapter (EDIMAX EW-7318USg) which works without external driver, but this is an 802.11n (2.4GHz only) adapter with chipset Ralink RT2571W, which uses the rt73usb module, available in Linux kernel source.

SeeLook commented on 2019-01-23 19:48 (UTC)

Thanks for clues. Usually it is not often thing to change wifi adapter and with other ones before it just worked out of a box. So I will read that closely to fix my issues.

Also thank you for developing and packing it for Arch.

zebulon commented on 2019-01-23 12:49 (UTC)

@SeeLook: well, the number of devices is extremely high, and it is impossible to list them all or to keep the list complete. There are other resources for this, such as https://wikidevi.com. What is really important is the chipset (8812, 8814, 8821, etc.) A lot of people mistakenly use the wrong driver due to the fact they do not identify correctly their chipset. The Arch wiki section on rtl88xxau on the WiFi page is very helpful in that sense. Finally, a list of hardware IDs can be found in the driver code in file /os_dep/linux/usb_intf.c.

SeeLook commented on 2019-01-23 11:01 (UTC) (edited on 2019-01-23 11:01 (UTC) by SeeLook)

Hi,

Just for information. This is only one among many AUR packages I'v tried that works with Tp-Link T9UH adapter (id 2357:0106), so it would be good to have supported devices listed somewhere close to it, otherwise it is really hard to find proper driver.

Still resume from suspend kills the device.

Gatenkaas commented on 2019-01-03 16:40 (UTC)

Building and working perfectly, thank you!

zebulon commented on 2019-01-03 05:34 (UTC)

I just merged the patch for kernel 4.20, please let me know if that works.

Gatenkaas commented on 2018-12-28 18:48 (UTC)

With kernel 4.20 the driver does not compile due to the following error: "rtl8814au-master/os_dep/linux/ioctl_cfg80211.c:352:2: error: implicit declaration of function ‘get_monotonic_boottime’; did you mean ‘getboottime’? [-Werror=implicit-function-declaration] get_monotonic_boottime(&ts); " See line 351 en 352: struct timespec ts; get_monotonic_boottime(&ts);

This is caused by the deprecation of "get_monotonic_boottime" in kernel 4.20. See https://www.kernel.org/doc/html/latest/core-api/timekeeping.html under "Deprecated time interfaces".

If you change the lines in ioctl_cfg80211.c to:

351 struct timespec64 ts; 352 ktime_get_boottime_ts64(&ts);

..then it compiles without errors. However I am not a developer.

zebulon commented on 2018-10-30 19:07 (UTC)

The 4.19 patches have now been merged, you can re-run the script (I did not update the PKGBUILD though).

zebulon commented on 2018-10-29 12:21 (UTC)

@dobedobedo: thanks, I will merge asap.

dobedobedo commented on 2018-10-27 13:48 (UTC)

Hi, just found that the project which the source forked from added the support to kernel 4.19.
https://github.com/tpircher/rtl8814AU
I changed the download source and the folder name to rtl8814AU and it works.

dobedobedo commented on 2018-10-27 06:11 (UTC) (edited on 2018-10-27 06:13 (UTC) by dobedobedo)

Hi, I failed to install this driver on kernel 4.19. It showed the error message:
Error! Bad return status for module build on kernel: 4.19.0-2-MANJARO (x86_64)
Consult /var/lib/dkms/rtl8814au/4.3.21.r34.ga0c4479/build/make.log for more information.
However, there is no such a log file.

zebulon commented on 2018-09-04 19:05 (UTC)

Looking at the comments on Github aircrack, there seem to be some limitations with 5.3.4, the biggest one being the lack of VHT support and maximum speed of 150 Mb/s. Let's wait a bit before packaging it.

zebulon commented on 2018-08-31 18:24 (UTC)

Interesting, looks like an evolution of 5.2.20 and that they have integrated aircrack injection code. Possibly the future for all rtl8812/14/21 series?

erkexzcx commented on 2018-08-29 12:12 (UTC)

https://github.com/aircrack-ng/rtl8812au/issues/180 :)

zebulon commented on 2018-08-24 08:45 (UTC)

Unfortunately I cannot help due to the fact I do not own a 8814au device. As you write, you would need some metrics. But you may notice some bugs being removed (disconnection, etc.). Finally, there may be some security fixes/enhancements that are not visible.

erkexzcx commented on 2018-08-24 03:14 (UTC)

For sure I can test it, but why should I? I mean, even with rtl8812au-aircrack-dkms-git, the only thing I noticed is lower ping (3ms instead of 4ms with your driver. How can I validate it works "better"? :)

zebulon commented on 2018-08-21 12:10 (UTC)

In addition, on the Edimax website, there is a EW-7833UAC_Linux_Driver_1.0.1.0.zip file which decompresses as rtl8814AU_linux_v4.3.21.1_20171108.tar.gz. This is the same version number than for the TP-link, but the timestamp changes by 9 days. I did a quick comparison with T9UH_linux_v4.3.21.1_24835.20171031.zip and indeed they are almost identical. The Edimax archive has an Edimax specific entry while the TP-link has, as expected, its own specific T9UH UIDs. Thus vendors only adapt the code to their adapter names, that's all. Otherwise the rest of code is mostly the same. This shows how Realtek just provides boiler plates to vendors that make their own archives, hence the mess. That said, it is probably worth trying v4.3.21.1 over v4.3.21 as it may have upstream corrections from Realtek.

zebulon commented on 2018-08-21 11:46 (UTC)

I did further searches, and found out this version: T9UH_linux_v4.3.21.1_24835.20171031.zip from https://www.tp-link.com/us/download/Archer-T9UH.html#Driver. Just found out that it is available in Github with kernel patches there: https://github.com/coolshou/rtl8814au or https://github.com/francoism90/rtl8814au. Worth a try maybe? Do you want to try this code base and report? If they do work and fix bugs then it could be worth using them.

zebulon commented on 2018-08-21 11:37 (UTC)

@erkexzcx: this is the reason why I am very reluctant to use these sources. The 3 PKGBUILD I maintain so far use the latest code version from Realtek (allegedly) for each chipset, repectively. The only modifications are code to make them compatible with the latest Linux kernel versions. Other projects often use hybrid code bases to make the drivers compatible with many chipsets, and end up with drivers that are not up to date and carry a lot of hacks. But in the end it is Realtek to blame; they should be more open and transparent with their code and their multiple rewrites.

erkexzcx commented on 2018-08-20 19:21 (UTC)

Actually using AUR package rtl8812au-aircrack-dkms-git I got lower latency and overall better performance when using with my AWUS1900 but then suddenly it started to randomly "reload" itself and connection is getting lost about every 1-2 minutes. I then got back to this (your) AUR package/driver and all the issues went away. So I assume - rtl8812au-aircrack-dkms-git is a more complete driver with more pull requests than in original driver, but again - it was unstable to me.

zebulon commented on 2018-08-20 12:01 (UTC)

@erkexzcx: fantastic, many thanks. Besides, do you know if this is still the latest release from Realtek? It is infuriating the driver is much behind the rtl8812au version (if the version numbering is indeed significant, that is.)

erkexzcx commented on 2018-08-19 22:13 (UTC)

@zebulon I've updated this package. Nothing has changed for x86_64 and i686 architectures, just a very small patch for ARM devices to get it work. Just double checked it by installing this package on my ARM device - works perfectly. Thanks a lot!

zebulon commented on 2018-08-13 10:30 (UTC)

@erkexzcx: I have added you as co-maintainer. Thanks!

zebulon commented on 2018-08-12 19:18 (UTC)

@erkexzcx: this is a bit unfair, in my 2018-07-16 message below I explained I was interested in merging your changes into my PKGBUILD. I just explained that the code needs to be put on a Github acount to be able to use it in the source() section. I have not heard from you since then, and assumed that like me and many others you might be on holiday. I am also between two countries at the moment, hence the lack of repsonsiveness. But please be reassured that all good will is very much appreciated. Are you still happy to merge with my PKGBUIlD then? I can add you as co-maintainer if this is agreable to you.

francoism90 commented on 2018-08-06 11:45 (UTC)

@erkexzcx this is not the case: everyone wants to help you (and others) and good as possible.

Feel free to create your own package, and if possible create a PR to the main repo.

erkexzcx commented on 2018-08-05 21:06 (UTC)

I've put enough effort trying to make this package available for all devices supported in AUR, but nobody else seem to care. I will create another AUR package for this driver.

zebulon commented on 2018-07-16 12:12 (UTC)

@francoism90: thanks I will look into it. I was under the impression that the multiarchitecture support in PKGBUILD was here to avoid multiple packages, but I understand the overhead here.

francoism90 commented on 2018-07-16 09:55 (UTC)

This needs an upstream patch to enable ARM support. I don't know if setting the ARCH to ARM is correctly, if I'm not mistaken another bool needs to be set in the Makefile.

My solution would be to fork the repo, do the changes and create a new package with -arm if no one can test/verify the changes.

zebulon commented on 2018-07-16 08:42 (UTC)

@erkexzcx: I think the best way would be for you to create a Github account and put the file structure of your zip archive in a project. Then we can start diff between your archive and gordboy's one, to see what changes were required for ARM. Then we can see how we can incorporate these changes as a branch in my copy of gordboy's code. I am not familiar with the handling PKGBUILD for several platforms, but I will look into it. Either the platform detection will be made directly in the source (a bit like for the various linux kernel version), or maybe we can make the PKGBUILD download the specific branch according to the platform. I need to read how this is usually done. Thanks anyway for your contribution and I am glad this is on good tracks.

erkexzcx commented on 2018-07-13 16:47 (UTC)

@zebulon I am not very familiar with makefile structure, but my proposed package https://drive.google.com/open?id=1rKsYlV7_8UUDLDsQzk6kxKtb0jbPXulu works just perfectly on 2 of my arm devices. Any suggestions of how this could be implemented? Instructions are here: https://edimax.freshdesk.com/support/solutions/articles/14000063861-how-to-install-ew-7833uac-adapter-on-raspberry-pi (this is exactly what my proposed package does for ARM architecture)

zebulon commented on 2018-07-03 14:05 (UTC)

@francoism90: this is ok and I accept this argument. However we need to have a way to follow the code changes from the vendor's base code. Since my code is in Github, I would suggest to add arm as a patch set.

francoism90 commented on 2018-07-03 13:57 (UTC)

@zebulon It doesn't matter what architect your package supports. Not saying you can do anything in AUR, but other platforms such as ARM and x86 are fine to include if supported by upstream.

zebulon commented on 2018-07-03 09:37 (UTC) (edited on 2018-07-03 13:17 (UTC) by zebulon)

@erkexzcx: EDIT: I would like to amend my initial answer: I received some information and indeed AUR can be used to host various architectures, so I am completely happy to have you helping with the arm version of the package. Please note I do not own arm hardware, so you will be the one doing the patching and the testing.

That said, there is another thing to address here. Can you please propose your arm patches as a Github fork of my repository? A bit of history: the rtl8814au code I have on Github is based on vanilla with patches to compile on recent kernels (see the other related projects (8812au and 8821au), we have repositories on Github that show exactly this). Or do you prefer another solution? If I understand correctly, the PKGBUILD src will point to the same repository, hence we need a code that support both x86_64 and arm, using conditionals (as for the various kernel versions).

erkexzcx commented on 2018-07-02 16:38 (UTC)

Therefore I am asking you to add me as a maintainer, so I can test this driver on ARM architecture as well as on x86_64 (because I can). This way we can avoid creating another package as identical as this, just extra support for ARM.

erkexzcx commented on 2018-07-02 13:54 (UTC)

@zebulon I have no idea why you are focusing so much on arm community and not saying a word about i686 architecture in this AUR package. Please go to https://wiki.archlinux.org/index.php/PKGBUILD#arch and see what architectures are available for AUR. Also, if you really feel that AUR is not a place for ARM architecture, then please drop i686 as well. I do not see why you should support i686 if you resist to support arm architectures.

zebulon commented on 2018-07-02 09:02 (UTC)

@erkexzcx: unfortunately I am not a maintainer for ARM, or even have any affiliation with the people from archlinuxarm. You may want to contact them directly on their IRC or forum to propose your PKGBUILD (see https://archlinuxarm.org/forum/viewforum.php?f=4 for user-submitted packages). But the AUR, as far as I know, is not designed to host ARM PKGBUILDs. Hope this helps.

erkexzcx commented on 2018-06-30 13:10 (UTC)

@zebulon Could you please add me as a maintainer or at least - update this AUR archive with this one? https://drive.google.com/open?id=1rKsYlV7_8UUDLDsQzk6kxKtb0jbPXulu

I have 2 ARM based SBC and this driver is a MUST to have. I am more than happy to test it for you. My provided AUR archive works just fine on my laptop as well as on my boards.

zebulon commented on 2018-06-29 05:21 (UTC)

@erkexzcx: thanks for your work and comments. However please note I do not maintain packages for ARM. Arm is not supported here, this repository is for x86_64 only (i686 having now been dropped). There is however a separate Archlinux project for ARM at https://archlinuxarm.org and this is where an ARM package should be developed. Note this is not bad will, just that I would not be able to test it. Thus it would be better to leave it to the Archlinuxarm developers who have the hardware.

erkexzcx commented on 2018-06-28 02:13 (UTC)

Following these instructions, I managed to install it on Arch Linux ARM (Raspberri pi). This can be done by using this AUR package, but it needs some tweaks to PKGBUILD file. Could you please update it if possible? https://edimax.freshdesk.com/support/solutions/articles/14000063861-how-to-install-ew-7833uac-adapter-on-raspberry-pi

It is driver which needs to be compiled in order to install, but AUR package is limited to i686 and x86_64 architectures...

erkexzcx commented on 2018-06-23 19:57 (UTC)

To put AWUS1900 to monitor mode (fails through airmon-ng), use this command: ifconfig wlp0s20f0u1 down && iwconfig wlp0s20f0u1 mode monitor && ifconfig wlp0s20f0u1 up

erkexzcx commented on 2018-06-22 18:12 (UTC)

This driver works wtih Alfa AWUS1900. Thanks for sharing!

zebulon commented on 2018-05-19 13:32 (UTC)

@francoism90: thanks a lot for your contribution. DKMS support is very easy to add, this can be done later before packaging - we can simply use the files I used for rtl8814au, just adjusting the package version. Unfortunately I have no rtl8814au device tp test, but based on your feedback I am happy to switch. Also, you could do a pull request of your branch to tpircher (or other packagers).

francoism90 commented on 2018-05-19 09:50 (UTC)

In case someone ones to test the driver T9UH_linux_v4.3.21.1_24835.20171031 (based on build fixes from lwfinger + zebulon2/tpircher): https://github.com/francoism90/rtl8814au

No DKMS support and only one ASUS USB has been added, so you may need to add the device in os_dep/linux/usb_intf.c. It doesn't include other changes/fixes, just some things changed to make building work on Linux 4.15>=.

It works fine for my device (ID 0b05:1853 ASUSTek Computer, Inc).

francoism90 commented on 2018-05-18 19:58 (UTC)

@zebulon Isn't it not a requirement to share your work when using GPL? I don't understand why they don't provide any sources. :/

zebulon commented on 2018-05-18 10:18 (UTC)

@francoism90: unfortunately Realtek is unresponsive. We should insist though, maybe one day some manager would have a better attitude. Some brands are much more friendly, a few years ago I got from Terratec their sound card tech details for the ALSA pproject. But this seems an exception...

francoism90 commented on 2018-05-17 14:15 (UTC) (edited on 2018-05-17 14:19 (UTC) by francoism90)

I have mailed Realtek for the latest source.. haven't received any response.

@zebulon Cool! Will try this version. :)

Seems we can add devices as seen upstream.

Changelog: 1. For Archer T9UH V1/V2. 2. For Linux kernel 2.6.18 ~ 4.4.6. 3. Support monitor mode. 4. This is a beta version; unknown bugs may still exist. The formal version is coming soon.

zebulon commented on 2018-05-17 07:25 (UTC)

I just noticed that on TP-LLink site there is a new Linux driver for their T9UH, published on 8th of May 2018 as a beta. The driver in the archive is labelled: T9UH_linux_v4.3.21.1_24835.20171031

Seems to be a new revision of the 4.3.21 version. Will notify the packagers to see if they want to update their repositories.

francoism90 commented on 2018-04-30 14:41 (UTC)

@andrej Seems to be custom code, or something that has been included in this version. Will take a look, but for now, I just placed something upfront of the device.

andrej commented on 2018-04-24 20:48 (UTC)

Nope, I’ve set many more flags than that. Here they are. But mostly to no avail, because I couldn’t enable any VHT settings anyway. :-(

No clue about the LED; on my device it blinks slowly and it’s so weak that I can barely see it, even at night. So I didn’t look into disabling it.

francoism90 commented on 2018-04-24 19:56 (UTC) (edited on 2018-04-24 20:01 (UTC) by francoism90)

@andrej Is that the only flag you have set?

Is it possible to control the led? The blinking on my device makes me crazy, lol.

andrej commented on 2018-04-24 01:58 (UTC)

Here we go: 17, 18, 19, 20, 21. :-)

But I guess most of these^^^ are in fact just "upstream" issues that can't be easily fixed without substantial help from Realtek. :-( Well, there's at least some AP support, but it's nowhere near the advertised 1Gb/s+ rates.

andrej commented on 2018-04-24 01:00 (UTC) (edited on 2018-05-01 07:54 (UTC) by andrej)

OK, I've just got the 8814au device and it appears to work in AP mode, to some extent, but it definitely looks like there's a VHT-related incompatiblity / disagreement between the driver and hostapd. (I had to disable ~all the VHT capabilities.) There are numerous options I can't turn on (when compared to ath10k), so I'll just file bugs for these on GitHub, so that someone knows about them. :-)

The most important kernel module option is: rtw_switch_usb_mode=1. Then (and only then) you get the device to connect at USB 3.0 speeds (as lsusb -t says):

|__ Port 2: Dev 18, If 0, Class=Vendor Specific Class, Driver=rtl8814au, 5000M

andrej commented on 2018-04-18 20:43 (UTC)

Hi, will this driver (and/or rtl8812au) work with hostapd? There are lots of confusing (and sometimes contradictory) statements about this on the web, unfortunately. :-(

rtl8814au : This comment suggests that it should work, but it's in no way clear. Some issues at aircrack-ng seem to even suggest that their rtl8812au driver should also support the 8814 chipset. Is that indeed the case? Does it apply to the 5.2.20 version here on AUR?

rtl8812au : Even after reading this and this, I still have no clue about AP support. :-/ It may kinda' sorta' work, perhaps with a different hostapd… Is there a howto for this?

(Context: I run a 5GHz 802.11ac AP on ath10k (with hostapd), but need to move it from PCIe to a USB device. Because ath10k_usb devices don't seem to exist, I was hoping that this rtl8814au device or this rtl8812au device could help.)

zebulon commented on 2018-03-18 07:43 (UTC) (edited on 2018-03-18 11:52 (UTC) by zebulon)

There is no official driver 5.1.5 for 8814au. The latest sources that can be found are based on 4.3.21 (which is what is used there). However, 5.1.5 for 8814au is a hack of 5.1.5 that was released for 8812au at some point, with hal files for 8814au copied over from 4.3.21. They did a lot of work, we can assume that it was good work. However the same hack could not be done using 5.2.20 (the latest version for 8812au) due to a significant codebase change. I am happy to try to package 5.1.5 from aircrack if that helps though. But I will not have a 8814au adapter to test it. And would I break 8813au compatibilty? (although this chip is very rare).

francoism90 commented on 2018-03-13 15:46 (UTC) (edited on 2018-03-13 16:06 (UTC) by francoism90)

Does anyone know the differences between this and other drivers?

https://github.com/astsam/rtl8812au https://github.com/aircrack-ng/rtl8812au/tree/v5.1.5

Thanks!

zebulon commented on 2018-02-07 15:32 (UTC)

@escapement: this is good to read. Note that credits go to the patch developers. I am only a packager and tester at the moment!

escapement commented on 2018-02-07 03:48 (UTC)

Working like a champ with 4.15 kernel! I'm running Manjaro... I got lazy... I don't know if they push out the kernels before Arch officially does, but I've have 4.15 for a while... Couldn't use 4.14 because there were problems with my amd graphics... Thank you so much for fixing this!

zebulon commented on 2018-02-05 09:44 (UTC)

@Foolz: good to hear. Modprobe failing to load is probably related to Manjaro specifics, look at the logs for more info.

Foolz commented on 2018-02-05 03:12 (UTC)

@zebulon

Thank you so much for your work. I wasn't able to load the module with modprobe earlier. However, after the latest kernel update today, everything works again, for some reason.

zebulon commented on 2018-02-02 10:14 (UTC)

I have just pushed the patches for kernel 4.15, should now compile with the kernel in Testing. Please re-install the driver for an automated recompilation via DKMS.

zebulon commented on 2018-02-02 10:03 (UTC)

@escapement: kernel 4.15 is still in testing. Probably this driver will require patches, will see if they are ready.

zebulon commented on 2018-02-02 10:00 (UTC)

@Foolz: can you manually load the module with modprobe? You need to enquire at Manjaro forums though, I am not a user and cannot really help there. Do they use different kernel patches than Arch?

Foolz commented on 2018-02-02 00:41 (UTC)

Using MANJARO with the latest 4.14.15-1 and having issue loading the Module. (which after the update, they system wouldn't load the module automatically) the system simply wouldn't found the module. Even it is clearly existed under the /lib/modules/4.14.15-1-MANJARO.

Tried sudo depmod -a, and so far, nothing conventional works.

escapement commented on 2018-01-30 03:37 (UTC)

Arch just updated to kernel 15.0-1 and the build totally fails... My linux C skills are rusty, but I'm trying to debug.... here's the build error

make[1]: Entering directory '/usr/lib/modules/4.15.0-1-MANJARO/build' CC [M] /home/tom/git/rtl8814au/core/rtw_cmd.o In file included from /home/tom/git/rtl8814au/include/osdep_service.h:41:0, from /home/tom/git/rtl8814au/include/drv_types.h:32, from /home/tom/git/rtl8814au/core/rtw_cmd.c:22: /home/tom/git/rtl8814au/include/osdep_service_linux.h: In function ‘init_timer’: /home/tom/git/rtl8814au/include/osdep_service_linux.h:273:8: error: ‘_timer {aka struct timer_list}’ has no member named ‘data’ ptimer->data = (unsigned long)cntx; ^~ /home/tom/git/rtl8814au/include/osdep_service_linux.h:274:2: error: implicit declaration of function ‘init_timer’; did you mean ‘_init_timer’? [-Werror=implicit-function-declaration] init_timer(ptimer); ^~~~~~~~~~ _init_timer cc1: some warnings being treated as errors make[2]: [scripts/Makefile.build:317: /home/tom/git/rtl8814au/core/rtw_cmd.o] Error 1 make[1]: [Makefile:1508: _module/home/tom/git/rtl8814au] Error 2 make[1]: Leaving directory '/usr/lib/modules/4.15.0-1-MANJARO/build' make: *** [Makefile:1699: modules] Error 2

escapement commented on 2018-01-24 02:45 (UTC)

You are my hero... I bought this Alfa AWUS1900 under the promise it was linux compatible... tried with Fedora... tried with Ubuntu ... using the drivers I found in git land... no joy on either... actually bricked my fedora install... Then I switched to manjaro... I should have used arch in the first place but was lazy... Installed your package and now everything is happy... Thank you

zebulon commented on 2017-12-15 14:36 (UTC)

I just pushed a new revision with better kernel 4.14 support.

@Foolz: I will se what I can do. I'll look at other repos for this ID.

Foolz commented on 2017-11-29 05:44 (UTC) (edited on 2017-11-29 05:45 (UTC) by Foolz)

TP-Link T9UH Archer works without an issue on 4.14.2-1-MANJARO. However the my usb ID for some reason is still missing, when doing a lsusb. Thank you so much for the driver!

aarcher commented on 2017-10-01 21:18 (UTC)

TP-Link T9UH Archer works without an issue on 4.13.4-1-MANJARO. thanks devs

Svenstaro commented on 2017-09-19 05:05 (UTC)

Merging into rtl8814au-dkms-git which is the same but newer and working.

zebulon commented on 2017-09-18 20:33 (UTC)

@Svenstaro: this package should be merged with edimax_ac1750_8814au-dkms, which does not compile for kernel 4.12 anymore. Thanks!

zebulon commented on 2017-09-18 20:23 (UTC)

This is my first attempt at providing Realtek 8814au chipset driver (allegedly also works for 8813au), which are used in AC1750 and AC1900 USB3 wifi adapters. Please note this is based on github repository code. Unfortunately I have no AC1900 to test it (please let me know if you wish to donate hardware :) Let me know of any problem, etc.

zebulon commented on 2017-09-06 09:54 (UTC)

To the maintainer: you may want to try https://github.com/astsam/rtl8812au/tree/v5.1.5 It has a newer driver 5.1.5 and the hal code for rtl8814au. You may need to patch for kernels 4.11.9 and 4.12 (see the same patches for 8812au).

bsdfirst commented on 2017-07-26 06:04 (UTC)

Hi all, I'm doing to disown this package as I'm not actually using the device anymore and I'm doing a poor job of keeping it up to date. Hopefully somebody who uses the device can pick this up!

a_manthey commented on 2017-06-22 10:15 (UTC)

its working on Kernel 4.11.6-1-Arch, thanks

bsdfirst commented on 2017-06-22 01:20 (UTC)

Ah. Yes. Oops. Apologies.

ohmyarch commented on 2017-06-21 01:29 (UTC)

==> Building and installing package ==> ERROR: pkgver is not allowed to contain colons, hyphens or whitespace. ==> ERROR: An unknown error has occurred. Exiting... ==> ERROR: Makepkg was unable to build edimax_ac1750_8814au-dkms.

bsdfirst commented on 2017-06-21 00:24 (UTC)

Thanks a_manthey, the box I have this running on doesn't see a lot of use nowadays so I haven't patched it recently. I've added the patch you provided upstream (though I confess to have not tested this on a kernel greater or less than 4.11 - i.e. I haven't tested it at all).

a_manthey commented on 2017-06-08 20:49 (UTC)

On kernel 4.11 compilation exits with errors (implicit declaration of function „allow_signal“ etc.). From edimax-support i got this solution: You're running kernel v4.11 which has the Signal related functions moved to a different file.  You need to do the following in order to make it works. open a text editor, like nano, vi, etc. open the file include/osdep_service_linux.h from rtl8814AU/ folder add the following lines after this line (#48) #include <linux/sched.h> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)) #include <linux/sched/signal.h> #endif save the file try to recompile the driver again