• Couple of issues on this driver still, give it couple of weeks/month to be patched up. One of the issues is related to airmon-ng, causing it to fail to setup monitor mode. But doing it manual (setting monitor mode) is working and there is a patch on it's way for it.

kimcoder, you have the same "issue" with the current version (it is not an airmon-ng issue). It is due to the fact that the driver is not great quality and mixes old stuff with some newer stuff (mac80211) as you can see on their github repository. Putting it in monitor mode (v4 or v5) is the same weird procedure (and none of them are supported by airmon-ng).

Check the forum, I posted a link to their repo, someone had the same "issue".

Yeah I know, but there are patch available for a fix for that one. Adding/creating interface. Will try compiling it using some patches I've collected this weekend and take a look

Adding "SET_NETDEV_DEV(mon_ndev, wiphy_dev(pwdev_priv->rtw_wdev->wiphy));"

++ memcpy

*** NOTICE: The 5.1.5 branch in somehow stable, but the v4.3.21 is more functionally.

• txpower stuck on 12 @ 5.1.5 branch, while 18 (and support to 30) on v4.3.21 branch

So, what you're saying is that you've measured the output power and it's 6db (+- 1db) higher with driver 4.x? Or it's just what is displayed when running iwconfig?

significant difference @ spectrum regarding to power, and the inj. also seems to got some issues, mostly inj. in comparison to the lower branch which worked fine except some smaller problems like the airmon-ng mather. but note I'm testing the 8814AU drivers, not the 8812AU or others in the stack. also collected some patches around, forked the drivers and added more devices + trying some other stuff. time will fix most problems anyway, too much nerds around these days.

• summary: 4.x-branch is more usable today, than the 5.1.x-branch would be tomorrow.. at least running @ 8814AU on AWUS1900 ut seems

have a great weekend Mr (^^,)

buffered or paused / bursty data frame injection reported @ https://github.com/astsam/rtl8812au/issues/30

kimocoder, is upstream really active? Because it looks like there's another driver available:
https://github.com/abperiasamy/rtl8812AU_8821AU_linux

Which seems to support more models of cards, cf 0004157 where we got a complaint about an unsupported card.

I am fearing that this will be a burden to maintain for us if upstream is not really pro-active to support new hardware based on the same chipset.

there are 4 different rtl8812(au) repos I follow and they all got different device id's added, some got more then others.. but "astsam's" repo is the only one with monitor/injection support but the developer does not include our pulls with additional device id's alot..
in "abperiasamy" repo there are 5 additional TP-Link id' added which should be added to the astsam repo too.

I can try make a pull req. with the device id's missing, but i dont know if it will be merged.

Another solution would be to fork the repo & add them yourself

I'll create a repo on Tuesday. Kim, do you have an account on GitHub so I can give you access to the forked repo?

yes, the same username as here.

just pushed 1 commit with additional 4 TP-link devices added to "astsam" repo.

thanks Mr. X.

Continuation of the discussion from https://github.com/astsam/rtl8812au/issues/48#issuecomment-323689272

In terms of Kali support, our interest is to have hardware work out of the box with the standard Linux kernel... if we need to apply a patch for monitoring/injection, it's OK we can maintain that patch on the linux source package itself. Here we made an exception to include this out-of-tree driver but it's not sustainable in the long term. Somehow this must be merged into Linux itself, possibly in the staging tree to start with if the code is not clean enough for the mainline.

You should try to convince someone to do this work. Then about the multiple forks, I have no special advice on which to pick, the most actively maintained one with the broadest hardware support I would say.

Please wait for Mister_X to fork the repo & I will push the kernel 4.11 support patch and add more devices. Changes that have been made so far, may the seen/found @ https://github.com/kimocoder/rtl8812au

As for pushing the monitor/injection support to the staging tree, I've don't got much knowledge on working on the staging/mainline linux kernel tree, but I'd sure look into it as soon as possible. Anyways, we're (Mr X & me) discussed the forking yesterday @IRC but due to the difference in timezones I was sleeping when he asked which repo (version) to fork so I think it will be done today (Tuesday) instead as first planned. Left a note for him to look at when he's online again.

I'll keep on working on my fork and the changes will be merged into Mr. X's one, when it's available. I also absolutely support your interest in getting the support into the staging kernel tree for the future.

At last, thanks for taking interest in this driver stack.

Drivers/support is successfully pushed to the linux staging kernel tree & the pull request is located @ https://github.com/torvalds/linux/pull/452

If this has been done correctly I'm not sure off, but it looks ok.
Awaiting further information.

rhertzog: a forked repo with additional support for 4 new devices (including the one mentioned in this topic) & v4.11 kernel include fix (the sched lib) has made it's way to https://github.com/aircrack-ng/rtl8812au and should therefor be used instead of the inactive "astsam" repo to fix the 'missing drivers'

The Kali repos should switch to the aircrack-ng/rtl8812au (Mister_X)'s repo & we'll make sure to keep it updated along the way until it makes it's way to the staging linux kernel tree. thanks

I just uploaded a new version of realtek-rtl88xxau-dkms (4.3.21_20170824-0kali1) with the repo aircrack-ng/rtl8812au"

Initially the package was based on branch v4.3.21 of astsam repo and it built the modules 8821au and 8814au. We can't build 8814au with the master branch.

For this new version I used branch v4.3.21 from aircrack-ng repository with the 5 new commits coming from the master branch in the same repository (applied without changes).

thanks for the note, I'll be sure to keep the v4.3.21 & v5.1.5 branch up to date in the future. again, thanks!

Can we close this bug or shall we keep it open until you believe that the v5.1.5 branch is ready for release in Kali?

close it, it has some issues with power output stuck on 18 dBm, while the one in use runs on 30. besides, there is a 5.2.9 version available for later use. thanks

Closing as requested, thank you.