RTL8812AU kernel crash on 24.10.0 rc2

Hello,

I am wondering if anyone can cross check my work here. I ran the following:

opkg update
opkg install kmod-rtl8812au-ct

I got

Installing kmod-rtl8812au-ct (6.6.63.2022.10.26~9b2b203a-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/targets/x86/64/kmods/6.6.63-1-fdf628e4ac1bbb67c9c54e22238868e0/kmod-rtl8812au-ct_6.6.63.2022.10.26~9b2b203a-r1_x86_64.ipk
Installing iw (6.9-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/iw_6.9-r1_x86_64.ipk
Installing iwinfo (2024.10.20~b94f066e-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/iwinfo_2024.10.20~b94f066e-r1_x86_64.ipk
Installing ucode-mod-nl80211 (2025.05.11~d5b3a9dc-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/ucode-mod-nl80211_2025.05.11~d5b3a9dc-r1_x86_64.ipk
Installing ucode-mod-rtnl (2025.05.11~d5b3a9dc-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/ucode-mod-rtnl_2025.05.11~d5b3a9dc-r1_x86_64.ipk
Installing wifi-scripts (1.0-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/wifi-scripts_1.0-r1_all.ipk
Installing wireless-regdb (2025.02.20-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/packages/x86_64/base/wireless-regdb_2025.02.20-r1_all.ipk
Installing kmod-cfg80211 (6.6.63.6.11.2-r1) to root...
Downloading https://downloads.openwrt.org/releases/24.10.0-rc2/targets/x86/64/kmods/6.6.63-1-fdf628e4ac1bbb67c9c54e22238868e0/kmod-cfg80211_6.6.63.6.11.2-r1_x86_64.ipk
Configuring iwinfo.
Configuring iw.
Configuring ucode-mod-nl80211.
Configuring ucode-mod-rtnl.
Configuring wifi-scripts.
Configuring wireless-regdb.
Configuring kmod-cfg80211.
Configuring kmod-rtl8812au-ct.

Rebooted the system and found myself in a bootloop w/ kernel panic: fatal error. The system did eventually come online, so I rebooted again and found the kernel panic was intermittent but not resolved. I ran:

opkg remove kmod-rtl8812au-ct

The system is now stable after many reboots.

Did I do something wrong? I can find many posts with the same issue, but they all date to OpenWRT v19.x.x or are not using an official driver from OpenWRT... I am just looking for a sanity check here -- it is OK if the driver is busted, but if I did something silly and can fix it, I'd like to... Specifically, I noticed that it did not install a firmware? I do not know if this matters.

Thanks

Yep.

First, you have stayed on a release candidate waaaaay past its sell-by date. The current release is 24.10.2. Please upgrade:

opkg update 
opkg install owut 
owut upgrade 

Second, you made two mistakes in one action: you tried to use a USB device (first mistake) made by Realtek (second mistake). If you want your networking to actually work, you need a PCIe, m.2, or mSATA device made by Mediatek or Qualcomm Atheros (or by a third party using their chipsets).

Do you know if updating to latest keeps other configs, like docker instances, etc?? That's the main reason I've not upgraded, I had to compile some stuff for my docker instances to get them working.

Also -- and this question is for anyone, really -- can anyone confirm if the driver works on latest stable? I read somewhere that newer kernels have the 8812 driver built-in, but can't confirm this.

Yes you did something wrong, you can't just install kernel module rt18812.... into any version.
if you not wanna update firmware then don't add/update any packages and stay in the version you are using.
As this is open source free system probably no one can confirm anything for you.
If you know how to keep your config update is not a problem.

Could you try rtl8xxxu driver?

Entirely up to you. There's a file, /etc/sysupgrade.conf, into which you can place a list of files to be preserved across upgrades.

Wrong question. The right questions are, should I be using USB networking devices? and should I be using components made by Realtek? The answer to both is no, if at all possible. You want your wireless card to be on the PCI bus, and you want one made by Mediatek or Qualcomm Atheros.

I will give this a try tomorrow and report back. Thank you for the idea. For tonight, I've discovered some interesting quirks that I'll try to document here.

Thanks for the info. I'll give this a think.

Every thread I find on this topic has the obligatory 'don't use USB, and don't use Realtek' post -- I let the first slide because like I say, it's obligatory, but in context if you must know, the choice to use a realtek USB adapter is entirely an RF related choice.

  1. Looking at datasheets, the RTL8812 has a really good receive sensitivity of -88dBm @ 802.11b 1Mbps. This is not as good as the old Orinco PCMCIA cards of the early 2000s @ -92dBm, but it's not bad in today's world where people don't give much thought to the RF side of things.
  2. USB has the distinct advantage of short coax runs. If your antenna(s) is(are) 10-15ft from your termination point, you can run a USB cable, and then a short pigtail coax. This reduces RF losses while the data over the USB cable doesn't mind a little loss as long as it's in spec. Remember connectors add 0.5dB/connector and coax depends on length, but it can really add up especially if you use RG-176 or thinner coax for pigtails, or RG-58 for longer runs...

So, it's good to get the obligatory 'don't use USB or a realtek' posts out of the way; I had my reasons for buying this adapter. Rant over.


On to OpenWRT. I have some other, older adapters that I attempted to use in place of the RTL8812AU. They have Atheros AR9271 and RaLink RT3070 chipsets enabled by the ath9k and rt2800x drivers respectively. While the drivers did not bootloop my system, the cards did not work by simply installing kernel module drivers either. It turns out that my OpenWRT did not have ANY wireless packages and some packages were dependent w/o being marked as such in the repositories. Namely:

I had to install the following:

opkg install wireless-tools wpad ibuci20250120 libubus20250102

The last two libraries were needed for iwinfo but were not auto installed as dependencies, if I remember. I think they were mostly cosmetic for Luci to report the status of the wireless links. Again, if adding a wireless card to a router that ALREADY has wireless, these would already be installed. This was my problem with the Atheros and RaLink USB cards.

Now that I have a wireless setup working, I may revisit the RTL8812AU drivers in the morning. Thank you to everyone for your input. OpenWRT is free, so I know what help I get is given freely from the community's personal time.

Besides, that no one today wants to use 802.11b you also need a good antenna (as you know as a radio amateur). When you look at the 'antenna' of such a stick, they're more like a kind of excuse.

On the other hand, you might get additional unwanted rf if the USB cable isn't proper shielded. Especially when using USB 3.0.

Well, we're talking about wifi, not EME or OSCAR.
But yes, you're right.

Besides, if you want to use an USB device for an AP, you won't have much fun finding one that works.
They're meant to be used on clients, not access points.

But, i do wish you luck and success.

55 es 73.

2 Likes

is not necessary for anything at all (well vendor drivers, of which kmod-rtl8812au-ct is one, but those won't to AP mode anyways).

wpad is a bad idea (you lose WPA3 relative to the default wpad-basic-mbedtls), wpad-mbedtls or wpad-openssl would be natural successors and not a downgrade.

indirect dependencies, they will be resolved automatically.

both of which are ~15 years old, hardly representative for moderm chipsets nor recommended for this purpose (either).

Technically correct, but… 15ft is very ambitious for USB3 (and you need USB3 for modern (wifi5+) WLAN cards), even in USB2 days that involved a good cable and luck (on the brink of active cables; been there with printers, you will suffer problems); with USB3 passive extension cables are explicitly against spec (for good reasons, doesn't mean that I'll agree, but passive extension cable +plus+ long cable don't go along).

Sounds cool, unless you realize that data sheets mean jack shit. Chipset specs, especially for this, don't translate 1:1 to the individual devices, their rf design and antennas (and that's bad, with pretty much anything USB). And even if the theoretical specs were indeed correct, what use are they if the drivers don't make it accessible.

For AP mode and/ or 24/7 operations, USB (any vendor) is not a contender. Until quite recently, "Realtek USB" (Reasil) driver support was very neglected (their PCIe divisions took notice of linux a bit earlier), especially when looking at AP mode. But there is nothing as 'Realtek' here either, we have 4 major driver generations at play:

  • rtlwifi
  • rtl8xxxu
  • rtw88
  • rtw89

rtlwifi/ rtl8xxxu are not focused on AP, if AP mode actually works or not is more of less by accident. rtw88/ rtw89 get more attentions by the company. Especially rtlwifi/ rtl8xxxu are not all that uniform either, spanning a diverse set of sub-drivers spanning around a decade of hardware development - especially the older ones being worse than the newer ones. Some of the newer ones are actually pretty good (e.g. rtlwifi/ rtl8192du and rtw88/ rtl8822ce), but that doesn't mean they quite fit for AP mode in production.

But kmod-rtl8812au-ct doesn't belong to either of these, it's a slightly hacked up vendor driver. wext based, with a slim cfg80211 emulation layer on top, derived from kernel v2.6.16 era ipw2200 wireless 'stack' - meant to use a vendor hacked hostapd 0.4.5. A horror cabinet of history.

Neither of which is relevant in 2025, yes I still have those antiquities as well, boxed up on a shelf - functional, but not up for use.

These are not the droids you are looking for.

1 Like

There's a lot to reply to here, but I can't argue with most of it. On 10-15ft USB runs, at least w/ USB 2.0 I've long used 30+ foot runs w/o much issue, but this will depend on many factors such as noise, shielding, and I think most importantly current draw / transience load spikes. In this application, I think it's important to understand how a USB WiFi card will draw current -- that is, what takes the most current and what sort of load does this present to the USB bus. For my case, I cut the USB cable and soldered in a 400uF capacitor next to the USB device to handle transient load spikes and this helped quite a bit, but this was many years ago. Yes, much of my hardware is old, but so long as drivers are available, I expect them to work.

On the datasheet receive sensitivity -- yes, a lot of it also depends on the vendor specific implementation, but the datasheet is a good place to start -- this issue by the way exists for PCI implementations too -- and I was simply using it to justify my choice to buy realtek. At the time, mediatek was ultra low-budget garbage. It seems they've turned the ship, so to speak, which is great for them and the rest of us as they're still fairly inexpensive.

My primary reason to make this post wasn't to engage in a long debate on best-practice hardware choice -- I made the post to see if I'd made a silly mistake and forgot some step in getting an additional wireless interface to work. I think at this point, I can say I didn't forget any step -- the officially posted driver is likely just hit-or-miss and the hardware is too old to develop it further -- I think this probably makes for a good argument to pull the driver from the official repo as to not render systems inoperable or unstable.