Package Details: rtl8812au-dkms-git 5.13.6.r129.g0fe44f8-1

Git Clone URL: https://aur.archlinux.org/rtl8812au-dkms-git.git (read-only, click to copy)
Package Base: rtl8812au-dkms-git
Description: rtl8812AU chipset driver with firmware v5.13.6
Upstream URL: https://github.com/morrownr/8812au-20210629
Licenses: GPL2
Conflicts: rtl8812au
Submitter: thelinuxguy
Maintainer: zebulon (zebulon)
Last Packager: zebulon
Votes: 76
Popularity: 0.23
First Submitted: 2015-06-08 13:04 (UTC)
Last Updated: 2022-09-02 13:21 (UTC)

Dependencies (3)

Required by (0)

Sources (2)

Pinned Comments

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

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

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 32 Next › Last »

zebulon commented on 2018-12-10 09:12 (UTC)

@arthurwatt-veea: thanks a lot for your work on the code. When you are ready, please fork one of the rtl8812au repos (such as gordboy's or the aircrack-ng) and propose your patches. One patch per issue being better than a big one addressing several ones, as you might already know. The earliest these patches are being added and tested (to ensure they do not introduce side effects), the better.

arthurwatt-veea commented on 2018-12-07 07:57 (UTC)

The bug is present in 5.1 and 5.2 repos. I guess there is not much testing of IBSS. My next job is to try and get IBSS working securely with RSN.

zebulon commented on 2018-11-29 15:30 (UTC)

@arthurwatt-veea: that is great work. Has the bug been introduced in 5.2? The codebase is very different from 4.3 (and 5.1 as far as I remember). What I would recommend to do is for you to fork a github repo (such as gordboy's or aircrack-ng), commit your change and send a pull request to various rtl8812au repos. They do not need to be the same than the one you used for your fork of course.

arthurwatt-veea commented on 2018-11-29 14:33 (UTC)

Thanks Zebulon. Before cutting through the repos I wanted to make sure the driver was not receiving the multicast packets and then discarding them. I then found that the multicast frames were being received and then discarded. The fix is fairly straightforward, not sure which repo I should push the change to, there seem to be so many....

zebulon commented on 2018-11-28 12:29 (UTC)

@arthurwatt-veea: 2 possibilities here: 1) would you like to try 5.3.4 version of the driver from: https://github.com/aircrack-ng/rtl8812au/tree/v5.3.4 and let me know if that corrects the issue. 2) Also, does reverting to 5.1.5 work? You can install package https://aur.archlinux.org/packages/rtl8821au-dkms-git/ and check (this one works for 8812au too). Please let me know which one works.

arthurwatt-veea commented on 2018-11-28 11:43 (UTC) (edited on 2018-11-28 11:46 (UTC) by arthurwatt-veea)

Hello I am testing the RTL8812AU device on 4.14 kernel in IBSS mode. Beacon handing seems ok and we can create/join the IBSS network with this driver. However we have noticed that multicast/broadcast data reception is failing which causes issues. Unicast processing seems to be working correctly. The IBSS behaved well on 4.3 version of the 8812AU driver.

Has anyone else come across this problem?

Regards

Arthur

moething commented on 2018-11-14 19:52 (UTC)

@gordboy It turned out that it was my mistake. Apologies. https://github.com/zebulon2/rtl8812au-driver-5.2.20/commit/f92c90364f21a7d9ea2d38ea85bb9d6287111a6f was missing in my local copy. That one contains the fix for my issue. It works fine now. Thanks for your support!

zebulon commented on 2018-11-14 11:01 (UTC)

@gordboy: thanks a lot for your notification and your swiftness. Just merged the change. As usual, please notify me issues or directly to the concerned Github repos.

gordboy commented on 2018-11-14 00:07 (UTC)

UPDATE

There was an issue with the latest kernel 4.20-rc2 just today which has now been fixed upstream, by a very fine and able maintainer :)

Only the very latest kernel was affected, and 4.19 has been working nicely since the last fix went in at 4.19-rc1.

@zebulon If you are still tracking 5.2.20.2, you would be advised to pull the latest commit, before the hordes arrive complaining about the latest kernel ...