rtl8812AU and/or rtl8814AU drivers


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 :frowning:

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/
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?

dom@machina:~/Pulpit/Projekty/WNDR4700-LEDE-REBOOT$ scripts/getver.sh

EDIT2: another modyfication Makefile http://wklej.org/id/3213264/ : its the same...no success http://wklej.org/id/3213266/ .
EDIT3:...and last modification Makefile (I have no more ideas) http://wklej.org/id/3213277/ ...still not building: http://wklej.org/id/3213278/ .
Any ideas ?

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 :frowning:
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 :frowning: 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:


good call here with this edit, i was going to link you this:

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.


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 :slight_smile:

Sorry for totally off-topic :innocent:


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):

  1. http://down.tendacn.com/uploadfile/2017/Drive/U12_linux_v5.1.5_19247.20160830.rar
  2. http://www.edimax.com/images/Image/Driver_Utility/Wireless/NIC/EW-7822UAC/EW-7822UAC_linux_v4.2.2_7502.20130517.tar.gz
  3. http://wikidevi.com/files/Drivers/Realtek/rtl8812AU_8821AU_linux_v4.2.2_7502.20130517_addl_IDs_added.tar.bz2


yes, i told you what your modified file fixed in the above post.


@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 ...
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 (?):



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?


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

then I probe driver and get strange output:

root@LEDE:/# modprobe 8812au
[ 69.872587] usbcore: registered new interface driver rtl8821au

rtl8821au instead of 8812au and lack of output from driver.
iw phy and iwinfo commands return empty result.

What can go wrong? Please help!


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:



I successfully configured driver in AP mode with hostapd and hostapd.conf
Problem with printk was solved by configuring kernel default print level.


I have a TP-Link MR 3020 (LEDE supported https://lede-project.org/toh/hwdata/tp-link/tp-link_tl-mr3020_v1) and an Edimax rtl8812au USB dongle

I want to build a wifi extender of sort out of this with the USB dongle (the rtl8812au thing) being used as client to connect to another AP

I can't get head or tail of the whole "build the driver for your router" thing and "cross compilation" thing (I once compiled a driver for an ubuntu laptop, that's the top of my skill)

Please help me getting the rtl8812au dongle to work with LEDE (on MR 3020 router) thank you very much

Do you speak Russian? My english is... struggling and I very much need help with rtl8812au on LEDE :slight_smile:


Пишите на <мой_ник>@rambler.ru


@prettyface - how to adopt yor compilation method to 8814au ?
Pleas howto "step by step" and "complete files" or patches.
Your method build drivers only for AM335XSK platform aka RPI ?

Main device is:

#ifdef CONFIG_RTL8814A
	{USB_DEVICE(0x0bda, 0x8813), .driver_info = RTL8814A}, /* Comfast - CF917AC */
#endif /* CONFIG_RTL8814A */

in os_dep\linux\usb_intf.c

lsusb -v
Bus 002 Device 002: ID 0bda:8813 Realtek Semiconductor Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x8813 
  bcdDevice            0.00
  iManufacturer           1 Realtek
  iProduct                2 802.11ac NIC
  iSerial                 3 123456
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           53
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           5
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0002
  (Bus Powered)
  Remote Wakeup Enabled

Will not really find in this forum some forgiving and specific developer who will tell me how to compile a driver for this device or compile it for me (or anyone else who has RTL8814AU)?
I've really used all the methods and found drivers on github, and no one wants to start working after compiling under LEDE - still shows in these successful builds the same error when trying to load the driver (at least compilation under WNDR4700 works):

8814au: Unknown symbol __ieee80211_get_channel (err 0)


I've made a fork (of LEDE part and module itself) and it compiles/installs fine:

But I'm also getting:

8814au: Unknown symbol __ieee80211_get_channel (err 0)

On master branch with x86_64 build. I'm wondering what is wrong here. No other errors, everything installs fine, dependencies are good.


It's because you use the mac80211/wireless network subsystem from your kernel (4.9). LEDE/OpenWRT however use the compat-wireless/backports for the system and drivers to be more up to date with development. You would have to compile your driver against the "mac80211" source from this package: