Hi
A driver for this chipset actually exist
And it supports also AP mode. The source structure and Makefile looks similar to rtl8812au which is supported as out of tree in Openwrt
I am trying to make a package of it, because it is required to leverage on the Openwrt build framework in order to pick up correct UAPI (Openwrt use backported mac80211)
But it does not work, it seems that the module build is not even triggered, I am a little bit lost.
Can anyone assist me on this?
I managed to get rtl88x2bu to compile as an openwrt package but must admit I have no idea what I'm doing. Cross compiling and attempting to bring up my rtl8812bu based usb adapter results in the iw command hanging. So while it compiles and loads, I still haven't had luck actually getting it to work as an AP in openwrt.
Hopefully that might be useful to someone.
The router reboots when trying to use the driver.
[ 300.270370] Process RTW_CMD_THREAD (pid: 6642, threadinfo=4d3ed29f, task=2f2c9d9c, tls=00000000)
[ 300.279115] Stack : 8543fc00 84400afc ffffffd4 8543f400 8543f400 c127b000 00000001 84401088
[ 300.287470] c127b000 00000000 00000001 80621b9c 00000000 8567d200 c127bfd0 84550000
[ 300.295832] 84657300 84657980 84ee7b30 c127b000 84400d70 80700000 80930000 00000000
[ 300.304181] 00000000 800505c4 00000000 00000000 00000000 8005048c 84657300 84ee7b30
[ 300.312537] 8005048c 84657300 807cd6c0 870385c0 84d30460 854e5ae0 00000000 8000aa58
[ 300.320899] ...
[ 300.323340] Call Trace:
[ 300.323353]
[ 300.328257] [<84400afc>] rtw_survey_cmd_callback+0x2c/0x68 [88x2bu]
[ 300.334303] [<84401088>] rtw_cmd_thread+0x318/0x494 [88x2bu]
[ 300.339202] [<80621b9c>] _raw_spin_unlock_irqrestore+0x14/0x38
[ 300.346099] [<84400d70>] rtw_cmd_thread+0x0/0x494 [88x2bu]
[ 300.350542] [<800505c4>] kthread+0x138/0x140
[ 300.354774] [<8005048c>] kthread+0x0/0x140
[ 300.358974] [<8005048c>] kthread+0x0/0x140
[ 300.363230] [<8000aa58>] ret_from_kernel_thread+0x14/0x1c
[ 300.368377]
[ 300.369804] Code: (Bad address in epc)
[ 300.373557]
[ 300.375689] ---[ end trace 42edff7c64e32b64 ]---
[ 300.379840] Kernel panic - not syncing: Fatal exception
[ 300.384896] Rebooting in 3 seconds..
hey guys any progress abt this topic?
compiled modules for ath79.. dont know if they do actually work.. I've managed to get them compiled, still have to give'em a try
88x2bu.ko.5.4
88x2bu.ko.4.14
any chance to get the patches for kernel 4.14? don't know where to begin
following the changes I made to Makefile before compiling
diff package/kernel/rtl8812bu/Makefile package/kernel/rtl8812bu/_Makefile4.14
9c9
< PKG_SOURCE_URL:=https://github.com/cilynx/rtl88x2bu.git
---
> PKG_SOURCE_URL:=https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.2.4.4_26334.20180126_COEX20171012-5044
13,14c13,14
< PKG_SOURCE_DATE:=2020-07-20
< PKG_SOURCE_VERSION:=a2abcaf523dfab2afeda8cc2cdb5e3c9510fc5f3
---
> PKG_SOURCE_DATE:=2018-11-18
> PKG_SOURCE_VERSION:=2d26e77fcf8942034d0f23db627e7e870f93ecb0
the replaced version is the latest compatible with V4 kernel
https://github.com/cilynx/rtl88x2bu/issues/52
That's because OpenWRT executing command iw dev wlan0 del to bring up AP, causing hang.
I created issue https://github.com/cilynx/rtl88x2bu/issues/141
Steps to make it work:
also, i tested your package on openwrt master snapshot (arch x86_64) - AP mode working only if hostapd started manually.
Nice work, leanos! Thanks!
hey guys any progress abt this topic?
By the way, there is an alternative source for this driver with great documentation and support: https://github.com/morrownr/88x2bu
Morrownr (Nick) collects, enhances and provides the linux drivers for Realtek chipsets rtl 8821cu, 8812au, 8821au, 8821cu, 8814au and also provides some overview and opinions on what works well and what not: https://github.com/morrownr/USB-WiFi
But there are no builds for OpenWrt.
Mhm, that indeed could be the case. I was just pointing to another driver source.
It is one of the best out there, next to aircrack-ng.
But is it for the rtl8812au?
And you can not create a version for the rtl8812au? The two best drivers are the one from aircrack-ng and morrownr.
I can't test it because it makes my netbook crash.
Sorry to resuscitate such an old thread, but dealing with that exact problem, and kind of at my wits' end:
It needs unplugging/replugging and restarting ~every week to run it as an AP.
I think the problem is with hostapd or the driver so I'm hopeful it'll get fixed eventually.
I have a Raspberry Pi 4 with a TPLink UE300 ethernet dongle and the Alfa as access point.
Did you ever manage to fix that problem?
I recently got an ALFA AWUS036ACM, hoping it would be the easiest way to improve my RPi4's Wifi… but every few days (seemingly every time a certain amount of data has been transferred), it will die and require unplugging/plugging back, to get it working.
I must admit I am a bit lost on which driver is even the recommended one at that stage (seems to be mt76x2u?), and how I can ensure I am running the latest version and/or upgrade to a more recent version.
Any tips heavily appreciated!
On their website I found that the ALFA AWUS036ACM uses the MT7612U chipset, which has nothing to do with the rtl8812bu driver. That chipset is from Mediatek, which is a different manufacturer and I would assume uses the mt76 driver by default, which is in the Linux kernel and gets merged into OpenWRT regularly. If there are bugs, I would suggest to try a newer Linux kernel or a newer version of OpenWRT. If you can reliably reproduce the issue you also could open a thread in the forums or a bug report at github.
Edit: Some users have reported mtk drivers/firmware work well for some older mediatek chipsets, so you could try those if you have severe problems, but they themselves are quite old (2019 and older) and may not adhere to newest Linux kernel standards.
For the others: Recently, there has been ongoing work to bring the rtl8812bu and some other Realtek chipsets into the Linux kernel. The project runs under the name rtw88. It might potentially make it into kernel 6.2 or something. See here:
Once this is done, there is no need anymore to manually install out of kernel drivers. Plug and play will be possible 