sadly this is the only AC usb device available on the market with some support for linux and the drivers are not standard so you have to do things manually, there were some attempts to convert it but everything is abandoned
none of the previous realtek maintainers seems to be interested in this device
Build to Linux WNDR4700 4.9.34 #0 Tue Jun 27 09:47:07 2017 ppc GNU/Linux (r4467-6da4f03) properly from this git sources/drivers (https://github.com/weedy/lede-rtl8812au-rtl8814au/) and...not working. Bug:
root@WNDR4700:~# insmod 8814au failed to insert /lib/modules/4.9.34/8814au.ko root@WNDR4700:~# logread (...) Tue Jun 27 15:17:49 2017 kern.warn kernel: [ 1253.660966] 8814au: Unknown symbol __ieee80211_get_channel (err 0)
Pleas help - I'am still choice to this working correct...
Generally to Ubuntu 16.04.1 LTS (kernel: 4.8.0-56-generic #61~16.04.1-Ubuntu SMP Wed Jun 14 11:58:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) driver build (very simple: dkms) and work perfectly (only client mode: ~235 Mb/s) from other github sources https://github.com/sbosshardt/rtl8814AU in this card https://www.aliexpress.com/item/600Mbps-1200Mbps-1750Mbps-Mini-USB-Wifi-Adapter-2-4G-5GHZ-USB-Wirless-Wifi-Receiver-802-11AC/32787025685.html .
you can compile it, build it, and load it without issues, yes. even on any of these repos you see for this, after patching (with these patches and copy Module.symvers: Manually or Automatically). the issue is when it is loaded. we cannot control it from lede's normal systems. we have to rely on udhcpc and wpa_supplicant to actually get a card connected in client mode without crashing the driver. ap mode can broadcast (from hostapd) but i havent tested any further
but also:
that being said some other driver modules i listed here so this person could pick another card just to save time, rather than wasting it trying to use this driver
@lucize - identical problem to build this driver (no x86 and no mipsel/mips architecture) : http://wklej.org/id/3213235/ @Cutepally
I understand that you are recommending something that works - but not the only thing that is basically a cheap USB card with the possibility of WIFI-AC - that's what the card i mentioned and ubuntu works great - the problem that i do not want to work, ie i tried All of the described ways of building and either the driver does not build, or does not work the only one that builds without problems, ie https://github.com/weedy/lede-rtl8812au-rtl8814au. You have not posted in this thread a comprehensive procedure ... or just no one has created a fully functioning Makefile that handles LEDE-trunk, with different architectures (because it seems to matter too).
The question is whether someone will take this? (Not everyone is a programmer - my way of thinking why again another, good idea for economical AC falls and goes without echoes among so many professionals ...?).
To be honest, I do not mind the launch mode of this card and that it is necessary to additionally cry out the LEDE automation. AP mode I just do not need. I mean, how many of us, to revive older USB3 routers and a fairly decent low cost Chinese processor that works more than satisfactorily in STA mode.
EDIT: http://wklej.org/id/3213252/ - i litle modyfication Makefile from https://github.com/musashino-build/lede-rtl8812au ...compile and... there is a similar problem at compilation -p generally without success http://wklej.org/id/3213255/ .
That is why it is important to have a thorough and thorough procedure - I assure you that a lot of people are interested in upgrading to powerful routers with AC functionality - at low cost - that's probably the main reason for doing so ... is not it?
I just remember that this "Chinese invention" works great in AC mode ... but on ubuntu (AP mode also works ... as someone depends on it) - however, it must be some kind of goodwill of professionals (...by working to LEDE).
Is what the copy of beat - as usual: it is about money. Why overpay?
i dont have some step by step guide, im sorry for this
i provided my Makefile, it is exactly what i used to compile this and it was tested on nearly every driver for rtl8812au
===============================================
most likely not, it's a good idea, sure but relatek provided us with.. less-than drivers. we would have to redo a lot of it to get it to work properly (under luci and such). if someone wants it to work enough to get this thing loaded then maybe they understand how to use it or give up. plain and simple. it's very unlikely someone is going to rework most of this bad driver just on the grounds its cheap AC like yeah i understand where you are coming from but it will only work for the people willing to control it manually at this point and supporting that even in this forum would be a lot in my opinion.
===============================================
this was already answered you need to have D_LINUX_BYTEORDER_SWAB_H see:
this tries to make it use both endians (little and big) when you call for dconf_big_endian in makefile, so you must use CONFIG_PLATFORM_I386_PC="n" to prevent that and properly switch endians.
musashino-build/rtl8812AU doesnt have CONFIG_PLATFORM_GENERIC though, so this disabling this one is for some of the other repos.
"any ideas", well yes (see my makefile for this part if you want), this is also required and it's not being done. a lot of these were answered in this thread so please take some time to read over it.
@Cutepally
Have you read my modified Makefile (EDIT3)? - It seems to me that in your Makefile as well as @jow simply missing the appropriate source to which these patches can be imposed (I also have some doubts whether they will certainly be the same patches and if they are all required ...) ... And yes - I read this thread several times and frankly there is no simple, fully functioning Makefile that creates a working controller, even in such a form, to manually write outside of the LEDE automation.
And it does not matter where I come from - after all, the rational and thrifty use of my resources is probably the domain of all imaginative minded people - regardless of their state of possessions and their origin - is not it?
Just as I mentioned - there is a good will of programmers to make this driver was working under LEDE - you partly gave yourself the word by writing:
And yes - contrary to popular opinion price is the most important - always and everywhere ...
Well, sometimes 'The Time' is much much more valuable than money... If You pay a few bucks more You get well supported product and no head ache. Oh, and You have time for enjoy/people/more-valuable-work/whatever
my makefile can work against any of the drivers posted in this thread (weedy, grawp, abperiasamy, astsam, dl12345, diederikdehaas, and musashino-build), even stock drivers like (after they are patched):
@Cutepally - I will repeat myself in case you do not understand me - you could simply insert a complete and working Makefile, where you use the correct syntax of the package with examples of working sources - such a normal, complete Makefile, which creates a package based on external sources and not Any local "src" ??? (Of course, with patches that work in favor of the entire compilation) - in short, I think there must be a complete source for github ...
EDIT:
Ok - for this moment after taking into account all your suggestions i created something based on Makefile musashino-build - the whole source : https://megawrzuta.pl/download/f17ba18e1cab611756c0fe366fbddde3.html
Compile and...bad again http://wklej.org/id/3213478/...
well, i think normally this would be the case but not for this specific driver. it would only create more issues in the state it is currently in for average users or people new to building. i understand you think it might be helpful but anybody who wants to work on this can already compile it fine with what we provided here and users would only create chaos because it's very unstable running under LEDE unless managed properly. i mean yes, it "works" (and it's surprisingly stable if handled properly) but that's a very loose definition of works and im not ready to pick up all the issues that get reported from it because of the driver Realtek made. if this driver worked fine under luci and lede could properly bring it up without crashing the driver, i would have posted it ages ago when i first compiled it.
similar to what lucize said above.
============================
that being said. it compiles fine for me (under my setup), so i confirm it will compile.
@Cutepally - After all, my Makefile in practice is no different from yours (I added the missing + kmod-lib80211 switch in the right place) and yet I am not building ... so just show me your complete Makefile - type statement in my build, in my The sources are built only forces the question ... what sources/what "my setup"/etc ?
So give the chance to play this particular package by throwing a complete Makefile ... I'm beginning to think that we will not come to an agreement, though, since you have such an attitude, "Read and Make Your Own Makefile" ... it was thanks to such an attitude " Developers "OpenWRT / Lede projects will always lag behind global levers in the broader field of Opensources ... Among other things, I call this the unwillingness of the programmers Lede ... it starts to happen exactly the same as what caused the fall of OpenWRT ...
I find it hard to say whether this will work on my router at all, this particular card since I can not just build a driver ... it seems so obvious that there is probably nothing to comment on this ...
most of the other ones i tested worked fine as well, after properly patching.
============================
the one i provided is fine, you don't need to make your own. you only have to patch the driver you want to use properly.
there is really no reason to be upset over this issue, even others have agreed on this too.
see dl12345 comments on this for example:
so, it's not my fault, not your fault, not LEDE fault. the fault is in the driver being not well supported by Realtek choices.
i'm sorry that isn't what you want to hear and i don't mean to sound sour about it but we have to face the facts, this driver is not that great running under LEDE.
if Realtek did a better job on the driver, we wouldn't even be having this conversation at all. all the work would be finished.
yes, someone could come along putting hours and hours into this driver, rewrite it enough, and get it running under LEDE without this problems but so far that person hasn't showed up. only people wanting to use the driver have and where it's at right now, isn't going to make that easy on anyone.
Sorry - is not complete Makefile and not complete sources - not compile driver for this Makefile (Of course inside Lede-trunk sources: [sources]/package/kernel/rtl8812au)
Where section (?):
...etc
That's what I mean by writing "complete Makefile".
As for the patches, as you can see in my logs are properly overlapped before compilation - that is, in short, are the patches you indicated in the appropriate directory: [sources Lede-trunk]/package/kernel/rtl8812au/patches.
Also, I still think that there is no complete recipe in this thread as to how to build this driver (even such a mauled and needy after installation) specifically my architecture (maybe any other than x86).
Also your assurances that something you have built on my architecture for the time being I treat with a glance of the eye since I can not reproduce it. Whether it will work on my card is a completely different story ...
I've got rtl8814au and tried to build an image with https://github.com/weedy/lede-rtl8812au-rtl8814au.
I've selected it in menuconfig, but resulting image file doesn't contain it. Also there were no errors and otherwise image seems to be working fine.
Any suggestions?
Hello!
I`m trying to launch 8812au driver on Archer T4U device using AM335XSK platform.
Driver was successfully compiled (diederikdehaas plus https://github.com/dl12345/rtl8812au/tree/master/patches).
In makefile I changed CONFIG_PLATFORM_ARM_RPI = y
LEDE starts successfully and finds my HW:
[ 2.559436] usb 2-1: new high-speed USB device number 2 using musb-hdrc [ 2.700314] usb 2-1: New USB device found, idVendor=2357, idProduct=010d [ 2.707364] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.714932] usb 2-1: Product: 802.11n NIC [ 2.719145] usb 2-1: Manufacturer: Realtek [ 2.723490] usb 2-1: SerialNumber: 123456
OK, I found out that Archer T4Uv2 (idProduct=0x10d) wasn`t listed in os_dep\linux\usb_intf.c
I add line: {USB_DEVICE(0x2357, 0x010D),.driver_info = RTL8812}, /* TP-Link - Archer T4Uv2 */
to the file and now I get correct info from iwinfo, iw dev and iw phy.
Can you help me to configure driver properly with wpa_supplicant and hostapd please?
Can you publish the text of your script: http://i.imgur.com/UVJzJfo.png
I would like to configure driver to work in AP mode.
I still have no printk output from driver, why?
In my .config kernel build options I have printk enabled:
