[Solved] USB W-Fi Issues

arrmo · February 14, 2024, 12:30am

Hi,

OK, pulling my hair out - and I can't afford to do that ... LOL! I have 2 USB Wi-Fi adapters, trying to one of them working, to debug another issue - and only needing the USB Wi-Fi as a client, not AP mode. I installed the following packages (opkg),

kmod-rtlwifi_5.15.137+6.1.24-3_mipsel_74kc.ipk
kmod-rtlwifi-usb_5.15.137+6.1.24-3_mipsel_74kc.ipk
kmod-rtl8812au-ct_5.15.137+2021-11-07-39df5596-1_mipsel_74kc.ipk
kmod-rtl8192c-common_5.15.137+6.1.24-3_mipsel_74kc.ipk
kmod-rtl8192cu_5.15.137+6.1.24-3_mipsel_74kc.ipk
rtl8192cu-firmware_20230804-1_mipsel_74kc.ipk

Tried both adapters,

ID 7392:a812 Realtek Edimax AC600 USB - this one seems to "install", with the driver rtl8812au ... but hangs OpenWrt when trying to use it. I get that, it's not really very well supported. But perhaps changes to /etc/config/wireless may help?
7392:b811 Realtek Edimax N150 Adapter - this one is odd. It's supposed to have an RTL8192 in it, but I don't see any driver "attaching" to it. Not sure why - but I'm open to suggestions. It's likely me .

Thanks!

patrakov · February 14, 2024, 2:21am

Please buy a supported WiFi adapter. For example, Alfa Network AWUS036ACM. Exactly "ACM", not any other letter combination. With snapshots, Alfa Network AWUS036AXML will also work, but it has shorter range.

arrmo · February 14, 2024, 2:51am

Dumb question, but ... is there a list of supported devices? Or just use the ToH? Never mind ... LOL. I just checked the ToH, don't see it there. Is there a way to know what is supported?

Thanks!

patrakov · February 14, 2024, 2:58am

At this point, any adapter based on the MT7612U chipset should work, and, until very recently, that was the only USB3 WiFi chipset supported. I used to recommend searching for "mt7612u" on AliExpress, but the problem is that the RF part and antenna quality varies.

The AWUS036AXML is based on a newer MediaTek chipset, supports WiFi 6E, but there are still some sharp edges here and there - e.g., non-working TX power control (says 3 dBm no matter what).

See also https://github.com/morrownr/USB-WiFi but avoid anything other than MediaTek.

arrmo · February 14, 2024, 3:11am

Will do, thanks!!

fakemanhk · February 14, 2024, 4:02am

It's a display issue (according to the author of the GitHub you mentioned), so the signal is never 3 dBm but display always showing this thing, I guess they are going to fix it later. However this is not the most important thing, this MT7921u chipset, doesn't seem to be stable enough in AP mode, my COMFAST CF-953AX with OpenWrt has driver crash from time to time (tested with many different devices), especially when high traffic volume it can die very soon.

MT7612U is better but my test is showing mixed results, the one I own isn't really working very fast (kind of disappointed) when compared to my MT7610U (Asus USB-AC51, TPLINK T2U). However for the MT7610U it's really really stable and performing well though it's only USB 2.0, sustained transfer rate 200-230Mbps is an easy task for them, right now I even pair it with one of my older Raspberry Pi to extend WiFi to cover a small corner of my home which my main WiFi isn't able to cover, and it's been a month without any issue at all. Now I am trying to see if I can grab a few more cheaper from AliExpress to augment on my old travel router GL-INET MT300N (it's 2.4GHz only but equipped with 1 x USB 2.0)

slh · February 14, 2024, 5:58am

I don't see that device to be supported by Linux right now (kernel v6.7) at all. Maybe it's 'just' a case of getting the USB ID added to an existing driver, maybe it needs more efforts - in either way, you will have to engage with mainline linux wireless developers about this (and effectively provide a patch; at the very least find out which chipset is in there, maybe you can open the case and read the chip numbers/ take a photo).

That one 'should' be supported by kmod-rtl8xxxu.

In either case, Realtek -especially USB- WLAN is always bad news and something better supported will make your job easier.

arrmo · February 14, 2024, 2:37pm

That makes sense, thanks! Dumb question (but learning about this yet), where is USB ID checked, so the driver loads appropriately in Linux / OpenWrt?

Also here, why do you say that? Not debating, just to understand. And I have that loaded, but it doesn't seem to "attach" to this device (i.e. not taken into use)? And I admit, it's a bit confusing ... do I also need the rtlwifi drivers installed? Not sure if this is causing issues or not.

Agreed!

Thanks!!

arrmo · February 14, 2024, 6:31pm

And another follow-up LOL. I have a feeling I know what is going on, but I admit ... I'm struggling to find where the rtl8xxx code gets pulled in to OpenWrt . And and all pointers appreciated! I will keep digging, but so far spinning in circles.

Thanks!

arrmo · February 15, 2024, 1:49am

OK, a few things, to follow up ,

I see the current Linux kernel code, and it does show support for the device 7392:b811 ... but, that is not in the code OpenWrt is pulling. I tried to hack it in, editing the .c file for now, inside the build_dir ... but still seems to not be detected. Very odd.
I grabbed a couple other cheap USB Wi-Fi devices. One device is Ralink based, using the rt2800usb driver ... bingo! Works fine. Thanks!
The other device, uses a MediaTek mt7601u, and it sort of works . Sort of meaning when it's detected on USB ... only on hard power cycle, or remove and insert, not reboot. I checked the kernel log, and it seems to be due to a known issue, that causes this error,

[   10.668647] usb 1-1.4: new high-speed USB device number 7 using ehci-platform
[   10.731199] usb 1-1.4: device descriptor read/8, error -71
[   10.891188] usb 1-1.4: device descriptor read/8, error -71
[   11.158748] usb 1-1.4: new full-speed USB device number 8 using ehci-platform
[   11.268563] usb 1-1.4: device descriptor read/8, error -32
[   11.534351] usb 1-1.4: device descriptor read/8, error -32
[   11.753771] usb 1-1-port4: unable to enumerate USB device

The potential fix I found is to add options usbcore use_both_schemes=y to /etc/modprobe.d/options. Hmm, that directory doesn't exist in OpenWrt. Not sure where / how to add the option. Still digging, but if anyone knows .

Thanks!

slh · February 15, 2024, 8:37am

The USB IDs are part of the driver source, the module's device table.

Because a general purpose linux with kernel v6.7 (OpenWrt's current set of wireless backports is older than that and might not know about it) tells me so:

$ grep -ia 7392.*b811 /lib/modules/$(uname -r)/* 2>/dev/null
/lib/modules/6.7.5-rc2/modules.alias:alias usb:v7392pB811d*dc*dsc*dp*icFFiscFFipFFin* rtl8xxxu

Also check (on OpenWrt with rtl8xxxu installed):

$ /sbin/modinfo -F alias rtl8xxxu | grep -i 7392.*b811
usb:v7392pB811d*dc*dsc*dp*icFFiscFFipFFin*

It only 'attaches', if it feels responsible for that USB ID - because it's declared in the driver source (or hot patched via /sys/bus/usb/drivers/rtl8xxxu/new_id, but in the context of OpenWrt that's a tad more complicated).

Disclaimer: I have no personal experience with rtl8xxxu (no devices using it), I have no idea if its packaging is correct or complete (necessary firmware packaged? --> check dmesg).

arrmo · February 15, 2024, 2:22pm

First off - thanks! Much appreciated, for the detailed replies ... it does help (a lot!). And a few thoughts .

Yep, seeing that now, thanks! I wasn't understanding that initially (new to that part of it).

I see the same, on my Linux (Ubuntu) box => it's there. But not OpenWrt ... even with rtl8xxx installed. And I did check, on OpenWrt,

# dmesg | grep 8xxx
[34830.885945] usbcore: registered new interface driver rtl8xxxu

But,

# grep -ia 7392 /lib/modules/5.15.137/rtl8xxxu.ko 2>/dev/null

Nothing at all ... odd? And also empty,

/sbin/modinfo -F alias rtl8xxxu | grep -i 7392.*b811

I also checked the source code, and not seeing this device (newer than what OpenWrt has pulled?).

That makes sense, thanks! To try (debug), is there a way to hot patch it? I'm willing to try

Thanks again!

slh · February 16, 2024, 3:05am

Presumably

echo "7392 b811" >/sys/bus/usb/drivers/rtl8xxxu/new_id

but in case of rtl8xxxu I'm not very hopeful about that to work, as the driver covers multiple different chipsets under one driver, without being able to tell the driver what chipset it is, there's no big success rate there (you really, really, really want the IDs to be declared in the driver source, properly).

Forgive me that I won't look into the 23.05.x/ backports 6.1 source to check about the details (maybe RTL8XXXU_UNTESTED needs to be set). While you should be able to get it working, it'll (probably) need some (limited) developing, but still would only result in basic client-only support.

arrmo · February 16, 2024, 4:39am

Agreed! Just trying to debug, see if I can get the device to be detected. I did try, but in that directory (/sys/bus/usb/drivers/rtl8xxxu/), there is only,

bind     module/  uevent   unbind

I get a Permission denied error for new_id

No worries! That's for me to figure out .

Thanks!

slh · February 16, 2024, 5:21am

If you can get it working on Ubuntu -with rtl8xxxu(!)- (it's going to be easier there, newer kernel version, everything and the kitchen sink enabled by default, firmwares preinstaleld), then it's also possible to do under OpenWrt. And with the knowledge of what (how) it is done on Ubuntu (unless they've gone for vendor drivers), it's easier to replicate on OpenWrt. 'All it needs' then is 'just' doing some driver backports, some packaging changes/ additions, not saying that it's going to be trivial, but doable.

…but at the end of the days, it remains Realtek wireless - and totally unsuitable for AP mode. So spend your efforts wisely and wage it against the cost of something that would just work instead (e.g. mt7921au).

arrmo · February 16, 2024, 5:26pm

Agree with you! And that's what I'm trying to do ... or at least, for now - debug in OpenWrt (more on that below ).

Agreed! But I also have issues with mt7601u, as above ... USB failing to detect on reboot (only works on hard power cycle, or USB remove and reinsert)? So that one has issues also.

And to what I have been trying => creating a patch, to add support for the device I am testing, the patch is as follows,

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index be93ffa508..4a1b5cc511 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6609,7 +6609,11 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
                }
                break;
        case 0x7392:
-               if (id->idProduct == 0x7811 || id->idProduct == 0xa611)
+               rtl8xxxu_debug |= RTL8XXXU_DEBUG_EFUSE;
+               dev_info(&udev->dev,
+                       "Edimax (Realtek) USB WiFi dongle (0x%04x:0x%04x) detected!\n",
+                       id->idVendor, id->idProduct);
+               if (id->idProduct == 0x7811 || id->idProduct == 0xa611 || id->idProduct == 0xb811)
                        untested = 0;
                break;
        case 0x050d:
@@ -6818,6 +6822,9 @@ static const struct usb_device_id dev_table[] = {
        .driver_info = (unsigned long)&rtl8723bu_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x7392, 0xa611, 0xff, 0xff, 0xff),
        .driver_info = (unsigned long)&rtl8723bu_fops},
+/* Edimax EW-7811Un V2 */
+{USB_DEVICE_AND_INTERFACE_INFO(0x7392, 0xb811, 0xff, 0xff, 0xff),
+       .driver_info = (unsigned long)&rtl8188eu_fops},
 #ifdef CONFIG_RTL8XXXU_UNTESTED
 /* Still supported by rtlwifi */
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8176, 0xff, 0xff, 0xff),

I backported this from the latest official Linux kernel code. But, on OpenWrt, it's never triggering?!?! In the kernel log (dmesg),

# dmesg | grep -i rtl
[   21.714853] usbcore: registered new interface driver rtl8xxxu

But nothing more ... so the check I added - never being triggered. Huh?!?!

Thanks!!

slh · February 16, 2024, 6:36pm

You need to add your patch to package/kernel/mac80211/patches/, not directly as a kernel patch. The in-kernel wireless stack and -drivers aren't used, in favour of the kernel v6.1 based mac80211 backports (which does complicate things, but provides newer wireless drivers for an older base kernel).

arrmo · February 16, 2024, 6:49pm

Dang! How did you know that . Thanks!!

Any particular subdirectory, or do I have to create a new one? Only asking because I see several targets / devices, but none really related to rtl.

Thanks again.

slh · February 16, 2024, 7:16pm

rtl/ or realtek/ would be an obvious choice, if you want to play it safe for testing, subsys/ is always at your disposal (it's 'wrong' (and wouldn't be accepted for a formal PR), but will work).

arrmo · February 16, 2024, 10:29pm

That makes sense! I wasn't sure if it was OK to create a new directory or not - I had guessed, put it in subsys (for debugging)

That's cool, NP at all - glad you knew that! I admit, I may have missed it, but wasn't aware of it.

So I got my patch in place (moved) ... and had to modify it. Very odd, but the latest kernel points this device to an rtl8188eu, but v6.1 of the kernel calls out rtl8723bu. That tripped me up for a bit, but now - building, and inserting the new kernel module (with some debug code),

[18920.364072] usb 1-1.2: Edimax (Realtek) USB WiFi dongle (0x7392:0xb811) detected!
[18920.585708] usb 1-1.2: Vendor: ▒▒▒▒▒▒▒
[18920.589623] usb 1-1.2: Product: ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒-▒▒▒
[18920.596092] usb 1-1.2: rtl8723bu_parse_efuse: dumping efuse (0x200 bytes):
[18920.603246] usb 1-1.2: 00: 29 81 00 6c 0b 00 00 00
[18920.608183] usb 1-1.2: 08: 00 0c 00 00 00 00 00 00
[18920.613184] usb 1-1.2: 10: 2e 2e 2d 2d 2c 2c 33 33
[18920.618085] usb 1-1.2: 18: 33 31 31 e1 ff ff ff ff
[18920.623048] usb 1-1.2: 20: ff ff ff ff ff ff ff ff
---CUT---
[18920.712076] usb 1-1.2: b0: ff ff ff ff ff ff ff ff
[18920.716980] usb 1-1.2: b8: 22 29 17 00 00 00 00 00
[18920.721936] usb 1-1.2: c0: 00 01 00 10 00 00 00 00
[18920.726835] usb 1-1.2: c8: 00 03 0c ff ff ff ff ff
[18920.731782] usb 1-1.2: d0: 92 73 11 b8 42 66 00 08
[18920.736683] usb 1-1.2: d8: be ac 2e 38 36 09 03 52
[18920.741689] usb 1-1.2: e0: 65 61 6c 74 65 6b 15 03
[18920.746649] usb 1-1.2: e8: 45 64 69 6d 61 78 20 4e
[18920.751626] usb 1-1.2: f0: 31 35 30 20 41 64 61 70
[18920.756567] usb 1-1.2: f8: 74 65 72 00 ff ff ff ff
[18920.761532] usb 1-1.2: 100: ff ff ff ff ff ff ff ff
---CUT---
[18920.786642] usb 1-1.2: 128: ff ff ff ff ff ff ff ff
[18920.791701] usb 1-1.2: 130: 81 ae 96 2d 03 93 96 11
[18920.796690] usb 1-1.2: 138: fc 8c 00 11 9b ff ff ff
[18920.801765] usb 1-1.2: 140: ff ff ff ff ff ff ff ff
---CUT---
[18920.917660] usb 1-1.2: 1f8: ff ff ff ff ff ff ff ff
[18920.922716] usb 1-1.2: RTL8188CU rev D (TSMC) 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[18920.931485] usb 1-1.2: RTL8188CU MAC: ff:ff:ff:ff:ff:ff
[18920.936831] usb 1-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8723bu_nic.bin
[18920.944215] usb 1-1.2: Direct firmware load for rtlwifi/rtl8723bu_nic.bin failed with error -2
[18920.953163] usb 1-1.2: Falling back to sysfs fallback for: rtlwifi/rtl8723bu_nic.bin
[18921.020887] usb 1-1.2: request_firmware(rtlwifi/rtl8723bu_nic.bin) failed
[18921.028016] usb 1-1.2: Fatal - failed to load firmware
[18921.033389] rtl8xxxu: probe of 1-1.2:1.0 failed with error -11
[18921.039642] usbcore: registered new interface driver rtl8xxxu

Yep, I missed the firmware. Added it, built, and re-flashed (went ahead and put this in flash now), but then on boot,

[   25.179480] usb 1-1.2: Edimax (Realtek) USB WiFi dongle (0x7392:0xb811) detected!
[   25.210117] Unhandled kernel unaligned access[#1]:
[   25.215045] CPU: 0 PID: 547 Comm: kmodloader Not tainted 5.15.137 #0
[   25.221514] $ 0   : 00000000 80710000 2f08a7cf 2f08a7cf
[   25.226881] $ 4   : 81a9dbb8 99f6059e 81d94100 00009fbf
[   25.232232] $ 8   : feffffff 00000060 00000003 ffffffff
[   25.237582] $12   : 00000000 0000002a 0c845880 8c122780
[   25.242932] $16   : 80ce3808 81a9dbb8 8192c400 24403735
[   25.248282] $20   : 8192c480 00010000 00000000 004026a8
[   25.253633] $24   : 8065b23c a19c10d7
[   25.258984] $28   : 81a9c000 81a9dba0 818e7200 81da18a0
[   25.264334] Hi    : 00366eb4
[   25.267263] Lo    : f8a9c988
[   25.270194] epc   : 8053ed08 __mutex_unlock_slowpath.constprop.0+0xc8/0x130
[   25.277332] ra    : 81da18a0 rtl8xxxu_read32+0x84/0xe0 [rtl8xxxu]
[   25.283650] Status: 1100a403 KERNEL EXL IE
[   25.287936] Cause : 00800010 (ExcCode 04)
[   25.292009] BadVA : 2f08a7d7
[   25.294939] PrId  : 00019740 (MIPS 74Kc)
[   25.298927] Modules linked in: rtl8xxxu(+) rt2x00usb rt2x00lib pppox ppp_generic pl2303 nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numc
[   25.370261] Process kmodloader (pid: 547, threadinfo=(ptrval), task=(ptrval), tls=77e41dfc)
[   25.378751] Stack : 00010000 80287b38 80ce2200 00000000 80ce2460 00000004 00000001 81a9dbb8
[   25.387314]         00000004 000000f0 8192c400 81da18a0 00000000 805f0000 80ce2200 81d0194c
[   25.395877]         000000f0 00000000 80ce3814 00000004 000001f4 818c0870 8194cf78 80ce36a0
[   25.404438]         00000002 80ce2460 8192c400 81da3ccc 00010000 801f78ac 00007392 0000b811
[   25.413001]         00000000 801f7388 00000000 8194c370 00000a20 00000000 00000000 8194c738
[   25.421564]         ...
[   25.424072] Call Trace:
[   25.426561] [<8053ed08>] __mutex_unlock_slowpath.constprop.0+0xc8/0x130
[   25.433321] [<81da18a0>] rtl8xxxu_read32+0x84/0xe0 [rtl8xxxu]
[   25.439299] [<81da3ccc>] rtl8xxxu_write_rfreg+0x3c8/0x2208 [rtl8xxxu]
[   25.446010]
[   25.447533] Code: 1062001a  02202025  8e020004 <8c520008> 0c01307a  02402825  8e030000  30620001  12400002
[   25.457530]
[   25.459207] ---[ end trace 7d7cea59f0ae3e8a ]---
[   25.463942] Kernel panic - not syncing: Fatal exception
[   25.469262] Rebooting in 1 seconds..
[   26.471401] bcm47xx: Please stand by while rebooting the system...

Huh? And now I'm stuck at TFTP boot - trying to figure out how to get back to a normal boot

Thanks!