Project: Improve rtl8821/11cu rtw88 in-kernel driver. Need help...

[morrownr]

Greetings to anyone that reads this message.

It was reported that the rtw88 in-kernel driver for the rtl8821cu/rtl8811cu chipsets was broken. So... we decided to make it better. Five patches have now gone into the Linux kernel (6.9) so things are better. While things are better, it is good to continue testing and make things very good.

If you are willing to help, here is a basic plan:

• uninstall the driver in this repo using sudo sh remove-driver.sh.
• install the driver at: https://github.com/lwfinger/rtw88 (follow the installation at that site)
• try to use your adapter and report results... applicable lines in the log file may help.

The rtw88 repo shown above is a downstream repo from the Linux kernel. It focuses on the rtw88 driver series. If you have test results or questions, post in this issue.

Regards,

@morrownr

[henkv1]

The repo https://github.com/lwfinger/rtw88 contains a backport of the latest wireless-next code for kernel 5.4 and newer. The driver really improved since the initial release in kernel 6.2 and works pretty well with my adapters. Except AP mode, which is still broken.

[morrownr]

@henkv1

Thanks for the info. I was aware of Larry's repo but did not know it was tracking wireless-next. I have been testing rtw88_8822bu and it has been making good progress in managed mode up through 6.5, which is the last version I have tested. I've had a couple of reports here about rtw_8821cu not working so I started testing my 8811cu adapter and it is not working. I've been in contact with some devs/users I know that have 8811cu adapters so as to get them to test. I'm trying to collect the info so as to try to determine what the problem is.

My overall goal is to shift my priority to helping with the mac80211 drivers, whether it be Mediatek or Realtek chipsets and I hope I can eventully sunset the 8822bu and 8821cu drivers here as I need to use my time on other things.

Cheers

[surfaceflinger]

Anything I can do as an end user with 8811cu to help? The exact device that I have is MERCUSYS AC650.

I've been testing every kernel release after 6.2 (and also that out-of-tree wireless-next port) to see if it's working but never really bothered to contact anyone...

I'll grab some dmesgs for you soon, I remember that logs were different between iwd and wpa_supplicant.

[morrownr]

@surfaceflinger

Due to some health problems, this issue has slipped lower on my priority list but I would like to see information flowing in so that maybe we can get to the point that we know where the important problems are. The rtl8812bu driver in rtw88 is in much better shape that the driver for rtl8811cu. It is not clear why which is why I posted this issue.

[surfaceflinger]

@morrownr Attaching dmesg + lsusb below. First it blocked some things so GNOME was frozen before session started properly, then it couldn't upload firmware until I removed it from USB and connected again. Firmware was uploaded to the adapter but connections to actual networks got timed out. It's the same between wpa_supplicant and iwd.

dmesg_wpasupplicant.log lsusb.log

[Salz]

I can't use the in kernel rtw88_8821cu driver either, it says it can't upload the firmware and keeps reconnecting. I compiled the driver with debug support, attaching the dmesg lines. Please tell me if I can help in any way.

lsusb.txt dmesg.txt

[morrownr]

Hi @Salz

I took a look at the files you sent. What kernel version are you using? Also, have you checked the firmware?

https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md

The location of the Realtek firmware is a few lines from the top.

[Salz]

I took a look at the files you sent. What kernel version are you using?

Linux 6.6.1 from kernel.org. In case it matters I also attached my .config

Also, have you checked the firmware?

Just checked them, the files in /lib/firmware/rtw88 are identical to from the kernel firmware repository.

[alkisg]

I've just tested an 8821cu adapter (0bda:c811) with Kali Linux, kernel 6.5.0-kali3-amd64. No device node (wlan0) was created, so I guess this issue also affects 8821cu devices. The relevant parts of dmesg are:

[  156.990720] rtw_8821cu 1-7:1.0: firmware: failed to load rtw88/rtw8821c_fw.bin (-2)
[  156.990730] rtw_8821cu 1-7:1.0: firmware: failed to load rtw88/rtw8821c_fw.bin (-2)
[  156.990732] rtw_8821cu 1-7:1.0: Direct firmware load for rtw88/rtw8821c_fw.bin failed with error -2
[  156.990734] rtw_8821cu 1-7:1.0: failed to request firmware
[  156.994141] rtw_8821cu 1-7:1.0: failed to load firmware
[  156.994142] rtw_8821cu 1-7:1.0: failed to setup chip efuse info
[  156.994143] rtw_8821cu 1-7:1.0: failed to setup chip information
[  156.994536] rtw_8821cu: probe of 1-7:1.0 failed with error -22
[  156.994552] usbcore: registered new interface driver rtw_8821cu

While the driver from this repository (8821cu-20210916) worked fine.

[alkisg]

Testing on an older ArchLinux with kernel 6.4.5-arch1-1, there were various errors in dmesg but the adapter was working.

There was no attempt to load the rtw8821c_fw.bin firwmare. Is that firmware really needed, or not, and the attempt to load it is what's causing the issue?

[alkisg]

Sorry, my bad. apt install firmware-realtek did the trick; the firmware files were missing from a default Kali installation.

[morrownr]

I was able to do a little more testing here a couple of days ago. I was using Debian 12. Base Debian 12 comes with kernel 6.1 lts but they do release later kernels at times. I uploaded kernel 6.5. Interestingly, the firmware was in place but kernel 6.1 did not have the driver. Kernel 6.5 fixed that. What I saw with that setup is that driver loaded and an interface was formed. When trying to connect, it would fail and it looked like a problem with security. Interestingly, the in-kernel driver for the 8812bu chipset does connect and work well. I really need more time to document the details of the failure and time to start looking around in the code of rtw88.

One thing I have noticed using the rtw88 driver for the 8812bu chipset is that rtw88 is not full featured yet. However, these out-of-kernel drivers are also missing features. My opinion is that the best supported chipsets overall for Linux users is the mt7610u, mt7612u and mt7921au. We should have adapters based on the new mt7925 chipset (wifi 7) soon since the driver is now in the Linux kernel. I'd say we may see them available at some point in the second half of 2024.

[Jibun-no-Kage]

2024? Really? Wow.

[wandou2018]

I can't use the in kernel rtw88_8821cu driver either, it says it can't upload the firmware and keeps reconnecting. I compiled the driver with debug support, attaching the dmesg lines. Please tell me if I can help in any way.

lsusb.txt dmesg.txt

Hello, i have the same issue on linux kernel 6.2.0 and pi 400 with linux kernel6.6.6-v8(built by myself). My hardware is a usb wireless card rtl8811cu, i use rtw88 in-kernel driver for the rtl8811cu.

➜  ~ uname -a
Linux root 6.2.0-37-generic #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov  2 18:01:13 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

➜  ~ lsusb | grep realtek -i
Bus 001 Device 006: ID 0bda:c811 Realtek Semiconductor Corp. 802.11ac NIC

➜  ~ cat ./drivers/net/wireless/realtek/rtw88/rtw8821cu.c | grep 8811CU -rinw -C 1
drivers/net/wireless/realtek/rtw88/rtw8821cu.c-24-      { USB_DEVICE_AND_INTERFACE_INFO(RTW_USB_VENDOR_ID_REALTEK, 0xc811, 0xff, 0xff, 0xff),
drivers/net/wireless/realtek/rtw88/rtw8821cu.c:25:        .driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* 8811CU */
drivers/net/wireless/realtek/rtw88/rtw8821cu.c-26-      { USB_DEVICE_AND_INTERFACE_INFO(RTW_USB_VENDOR_ID_REALTEK, 0x8811, 0xff, 0xff, 0xff),
drivers/net/wireless/realtek/rtw88/rtw8821cu.c:27:        .driver_info = (kernel_ulong_t)&(rtw8821c_hw_spec) }, /* 8811CU */

➜  ~ lsmod| grep -E "rtw|802"
rtw88_8821cu           16384  0
rtw88_8821c            90112  1 rtw88_8821cu
rtw88_usb              24576  1 rtw88_8821cu
rtw88_core            344064  2 rtw88_8821c,rtw88_usb
mac80211             1617920  3 iwlmvm,rtw88_core,rtw88_usb
libarc4                16384  1 mac80211
cfg80211             1241088  4 iwlmvm,rtw88_core,iwlwifi,mac80211

➜  ~ iwconfig wlan1
wlan1     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
          Retry short limit:4   RTS thr:off   Fragment thr:off
          Power Management:on

➜  ~ tail -f /var/log/kern.log
Dec 14 01:33:58 n-hop kernel: [16054.139380] wlan1: authenticate with e8:9f:80:7d:5b:f1
Dec 14 01:33:58 n-hop kernel: [16054.171908] wlan1: send auth to e8:9f:80:7d:5b:f1 (try 1/3)
Dec 14 01:33:59 n-hop kernel: [16055.163045] wlan1: send auth to e8:9f:80:7d:5b:f1 (try 2/3)
Dec 14 01:34:00 n-hop kernel: [16056.156415] wlan1: send auth to e8:9f:80:7d:5b:f1 (try 3/3)
Dec 14 01:34:01 n-hop kernel: [16057.175452] wlan1: authentication with e8:9f:80:7d:5b:f1 timed out

➜  ~ cat /var/log/kern.log  | grep "Firmware version"
Dec 13 02:51:23 root kernel: [  146.751339] rtw_8821cu 1-2:1.0: Firmware version 24.8.0, H2C version 12
Dec 13 03:36:30 root  kernel: [ 2853.426466] rtw_8821cu 1-2:1.0: Firmware version 24.11.0, H2C version 12

➜  ~ md5sum /usr/lib/firmware/rtw88/rtw8821c_fw.bin*
2638a40042a27e98df2f7929c8eee760  /usr/lib/firmware/rtw88/rtw8821c_fw.bin
f58626e7b13e6f146c7c4dfed12beab9  /usr/lib/firmware/rtw88/rtw8821c_fw.bin.src

I don't see the log failed to download firmware so I think it loaded successfully, and I do see an additional wireless card named wlan1.

I tried two versions of rtw8821c_fw.bin, and both had the authentication with xxxx timed out issue.

Add i tried to capture the authentication packet on the other pc(windows), but no authentication packet was captured, so I guess the kernel sent the packet to the wifi network card, but the wifi network card did not send it. The software i use to capture packets is Mircosoft Network Monitor, i was able to capture authentication packets from other sta, so I thought the software was being used correctly.

Do you have any other updates?

[morrownr]

@Jibun-no-Kage

2024? Really? Wow.

Right now I'm thinking that we will see cards (PCIe) in the first half of 2024 and usb adapters in the second half of 2024. That applies to the mt7925 chipset from Mediatek. I noticed a WiFi 7 PCIe card based on an Intel chipset for sale yesterday. The Intel driver is also already in the kernel. I forget which kernel it was first included in. I am still not seeing any information regarding Realtek and WiFi 7 for usb. The only thing for sure is that Realtek can't continue with out-of-kernel drivers, such as this one, as they will no longer work starting with WiFi 7.

[morrownr]

@wandou2018

Thanks for the additional information.

but no authentication packet was captured

This is consistent with what I am seeing. My latest test is with kernel 6.5. The driver loads, an interface is created but I cannot get a connection. The lack of an authentication packet would cause this.

I also have an adapter based on the rtl8812bu chipset, which is also supported in rtw88. It works as expected. Maybe we can compare code and find the difference?

@lwfinger

Larry, I am adding you to this message in the hopes that maybe you have an idea how we need to proceed.

I started this issue in my rtl8821cu repo with the goal of finding out why the rtw88 support for the rtl8821cu chipset is broken. What we have discovered so far:

With kernel 6.2 and later, rtw88_8821cu is loading and an interface is being formed. When a connection is attempted, it fails. It appears that no authentication packet is being sent.

Any help appreciated.

@morrownr

[lwfinger]

Since you have packet capture, could you please attach it to this issue.

[morrownr]

@wandou2018

The above message from lwfinger is requesting a packet capture file. Could you be so kind as to attach a packet capture file in a reply?

I added lwfinger to this issue as he maintains a downstream repo for rtw88 and might be able to provide some guidance based on what we are seeing.

Thanks.

@morrownr

[Smackd0wn]

Hi, I'm chiming in and add my observations.

I have two 88x1cu cards. Both tested on Arch Linux with kernel 6.6.7. One is 8821cu (0bda:c820), the one with bluetooth support. It works very well with the rtw88 driver. Bluetooth works okay as well (with the in-kernel btusb driver) and BT can work simultaneously with Wi-Fi. Almost felt too good to be true...

The other is 8811cu (0bda:c811 after modeswitch), and it does not work with rtw88. Haven't tested 8821cu from this repository, but it works okay on Windows. With rtw88, the symptom is the same--sending auth to AP for 3 times before authentication timed out.

I have not done any packet capture myself, but I believe it should be the same issue as @wandou2018. I think what he meant was that while his monitor setup is okay, there was not a single packet sent by the 8811cu in the capture. In other words, 8811cu was not sending any packets, or the power was way too low to be captured, maybe? Either way, RX seems okay, but TX is not working at all.

[morrownr]

@Smackd0wn

and BT can work simultaneously with Wi-Fi.

BT and WiFi can work simultaneously in the same adapter but the WiFi has to be limited to USB2 or there will be interference with BT. Since your card is USB2, it works. Where the problem comes in is if an adapter has a AC1200 or later chipset and is capable of USB3 WiFi. If makers turn on BT support, they have to limit WiFi to USB2 which is a serious limitation on AC1200 or later chipsets.

The other is 8811cu (0bda:c811 after modeswitch), and it does not work with rtw88.

I have two adapters that are 8811cu chips and vid/pid 0bda:c811 and they are single-state so no need for usb_modeswitch. Neither work with rtw88... from Mainline. I tested kernel 6.7 rc6 this morning. The situation is as many 8811cu users have reported: A wifi interface is created. An attempt to connect is made and the connection fails. I've tested with numerous distros and kernels. This has been reported by numerous users. It is interesting that your multi-function 8821cu based adapter does work. Maybe that is another hint as to what the problem is.

@morrownr

[Jibun-no-Kage]

Been tracking this... unfortunately I don't have any additional variants of ICs, so have not commented as yet. But am tracking, in case I can help in any way, just let me know.... Oh, and happy holidays!

[wandou2018]

@lwfinger @morrownr

Add i tried to capture the authentication packet on the other pc(windows), but no authentication packet was captured, so I guess the kernel sent the packet to the wifi network card, but the wifi network card did not send it

Sorry, it means that I can't capture any packets sent from the rtl8811cu, but I can capture packets from other intel wireless cards . so I can't provide the packets.

[wandou2018]

Hi, I'm chiming in and add my observations.

I have two 88x1cu cards. Both tested on Arch Linux with kernel 6.6.7. One is 8821cu (0bda:c820), the one with bluetooth support. It works very well with the rtw88 driver. Bluetooth works okay as well (with the in-kernel btusb driver) and BT can work simultaneously with Wi-Fi. Almost felt too good to be true...

The other is 8811cu (0bda:c811 after modeswitch), and it does not work with rtw88. Haven't tested 8821cu from this repository, but it works okay on Windows. With rtw88, the symptom is the same--sending auth to AP for 3 times before authentication timed out.

I have not done any packet capture myself, but I believe it should be the same issue as @wandou2018. I think what he meant was that while his monitor setup is okay, there was not a single packet sent by the 8811cu in the capture. In other words, 8811cu was not sending any packets, or the power was way too low to be captured, maybe? Either way, RX seems okay, but TX is not working at all.

Yes, my rtl8811cu works fine on Windows. And on linux, RX works because it has wifi list information. So I think this should be a firmware issue with rtw8821c_fw.bin, not a hardware issue.

[Smackd0wn]

Yes, my rtl8811cu works fine on Windows. And on linux, RX works because it has wifi list information. So I think this should be a firmware issue with rtw8821c_fw.bin, not a hardware issue.

I am not sure if it's a firmware issue, as I made several more tests with my 8811cu, all on Arch Linux 6.6.7:

1. With driver rtw88, Firmware version 24.11.0, H2C version 12 (from linux-firmware): no TX.
2. With driver 8821cu-20210916 and its array_mp_8821c_fw_nic firmware: works okay.
3. With driver rtw88, firmware from 8821cu-20210916 (same as 2nd test, shown as Firmware version 24.8.0, H2C version 12): no TX.

My 8821cu card works okay on all 3 conditions.

[lwfinger]

It is clearly not a firmware issue. The standard firmware extracted from your listed header file is identical with the one currently in rtw88.

I do not have a copy of 8821cu-20210916. Could you please post your tarball? Thanks.

[morrownr]

I do not have a copy of 8821cu-20210916. Could you please post your tarball?

https://github.com/morrownr/8821cu-20210916

This thread is in Issues in the above repo.

Background: I started this issue a few months ago after seeing a fairly constant flow of users having problems with rtw88. Why would users of the 8821cu/8811cu chipset be reporting problems with rtw88 in a repo that is the out-of-kernel driver? Because I actively encourage the users of this repo to try rtw88. This flow of problem reports caused me to take the time to test rtw88 and I found it not to be working. For me, a wifi interface is created. When I try to connect, the connection fails. This seems to be common. It was a surprise to me when the above user said his 8821cu (multi-function chipset) was working with rtw88.

I agree that this does not seem to be a firmware issue.

Many Linux users are not familiar with in-kernel (AKA in-tree) drivers and how they different from what they have experienced with installing drivers for Windows or installing the out-of-kernel Linux drivers so here is a short blurb for those that are following along:

Linux in-kernel wifi drivers consist of one or more driver files and one or more firmware files. The driver, actually called module if we are to be correct with the terminology, is never only one file. What we normally call the driver files are in the kernel. The firmware files are in the distro. When a new kernel kernel flows into your system during a update/upgrade, the driver is automatically updated because the driver is part of the kernel. A new kernel does not update/upgrade the firmware files. The firmware can be updated by the maintainers of your distro and it will flow in just like new kernels do but will have a name similar to Firmware for bla bla. Users can also upgrade the firmware files on their own.

Larry, I have an extra 8811cu based adapter if you are interested. I can mail it to you if you want. I really would like to see this fixed and I am not yet familiar enough with in-kernel programming to be much help but it is on my to-do list to work on.

Regards,

@morrownr

[lwfinger]

Do a 'git pull' and 'sudo cp rtw_8821c_fw.bin /lib/firmware/rtw88/.'. Does that change the actions of the 8811 modules?

[lwfinger]

The chip 8821ce is not a very good one. I even had to domate an RTL8192CU dongle to my neighbor whose 8821ce would not work even in Windows. I will try the spare 8811cu. Send me an E-mail at larry.finger@lwfinger.net and I will send you my mailing address.

[Dapeva]

Thanks to your contribution my Comfast usb wifi adapter (rtl8821cu) came back to life in Linux Mint. Greetings!.

[Matthaiks]

Kernel 6.8-rc3 + Mercusys MU6H (RTL8811CU): no TX.

[morrownr]

Thanks @Matthaiks

It seems that there is enough data piled up at this point, not all is in this issue, to say with some confidence that most people are having sucess with the in-kernel driver with the rtl8821cu chipset but no luch with the rtl8811cu chipset. Since the rtl8811cu is basically the rtl8821cu with bluetooth turned off, it make ones wonder what could the problem be.

@lwfinger

I have a theory. I noticed a few years ago that I had regular reports on the 8821cu out-of-kernel driver so I did some digging and finally figured out the problem has to do with RFE type. To fix a specific situation with any specific adapter, a user may have to use the rtw_RFE_type module parameter to fix things. It appears Realtek offered the option of various antenna configurations and makers could pick what they wanted. Not exactly freiendly to us.

# Select RFE type ( rtw_RFE_type )
#
# 0 = (2-Ant, DPDT), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 1 = (1-Ant, SPDT@Ant1), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 2 = (1-Ant, SPDT@Ant1) , (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 3 = (1-Ant, DPDT@Ant2), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 4 = (1-Ant, DPDT@Ant2), (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 5 = (2-Ant), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 6 = (2-Ant), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)
# 7 = (1-Ant), (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW) (try this setting first)
# 64 = this appears to be the default on adapters that do not support bluetooth
#
# Note: RFE Type is used to set antenna isolation and the BT coexistence
# mechanism. Some adapters require this setting and some do not. It may be
# necessary to try different settings to determine which setting is optimal
# for your adapter.

My bet is that the in-kernel driver has an antenna configuration that works for many rtl8821cu based cards but not for the rtl8811cu cards.

Thoughts?

@morrownr

[lwfinger]

What RFE does the device report? I do not think I have one of those.

Larry

On Sun, Feb 11, 2024 at 12:09 PM morrownr @.***> wrote:

Thanks @Matthaiks https://github.com/Matthaiks

It seems that there is enough data piled up at this point, not all is in this issue, to say with some confidence that most people are having sucess with the in-kernel driver with the rtl8821cu chipset but no luch with the rtl8811cu chipset. Since the rtl8811cu is basically the rtl8821cu with bluetooth turned off, it make ones wonder what could the problem be.

@lwfinger https://github.com/lwfinger

I have a theory. I noticed a few years ago that I had regular reports on the 8821cu out-of-kernel driver so I did some digging and finally figured out the problem has to do with RFE type. To fix a specific situation with any specific adapter, a user may have to use the rtw_RFE_type module parameter to fix things. It appears Realtek offered the option of various antenna configurations and makers could pick what they wanted. Not exactly freiendly to us.

Select RFE type ( rtw_RFE_type )

#

0 = (2-Ant, DPDT), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

1 = (1-Ant, @.***), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

2 = (1-Ant, @.***) , (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

3 = (1-Ant, @.***), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

4 = (1-Ant, @.***), (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

5 = (2-Ant), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

6 = (2-Ant), (2G_WLG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW)

7 = (1-Ant), (2G_BTG, iPA, iLNA, iSW), (5G, iPA, iLNA, iSW) (try this setting first)

64 = this appears to be the default on adapters that do not support bluetooth

#

Note: RFE Type is used to set antenna isolation and the BT coexistence

mechanism. Some adapters require this setting and some do not. It may be

necessary to try different settings to determine which setting is optimal

for your adapter.

My bet is that the in-kernel driver has an antenna configuration that works for many rtl8821cu based cards but not for the rtl8811cu cards.

Thoughts?

@morrownr https://github.com/morrownr

— Reply to this email directly, view it on GitHub https://github.com/morrownr/8821cu-20210916/issues/115#issuecomment-1937826417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6SEZOVJ3QAFTSRXUEHV33YTECORAVCNFSM6AAAAAA4WRF4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXHAZDMNBRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[morrownr]

@lwfinger

What RFE does the device report?

rtw_RFE_type:64

The rtl8821cu based adapters seem to have values of 0-7. I don't have a rtl8821cu based adapter. This is from memory... what little is left of my memory.

I just wonder if I should post how to check this setting so that others here can check and provide more feedback. If we do track the problen down to this, it would seem that only way to fix it would be to add a module parameter that users can set.

I do not think I have one of those.

The Bostrend adapter that has a single long antenna has the rtl8811cu chipset in it and that is the problem chipset.

@morrownr

[Smackd0wn]

My bet is that the in-kernel driver has an antenna configuration that works for many rtl8821cu based cards but not for the rtl8811cu cards.

The RFE type is parsed from the efuse by the in-kernel driver. Both my working 8821cu and non-working 8811cu dongles have the value rfe_option 0x22, which is RFE type 2 (after & 0x1f type mask):

https://github.com/torvalds/linux/blob/841c35169323cd833294798e58b9bf63fa4fa1de/drivers/net/wireless/realtek/rtw88/rtw8821c.c#L48-L92

That seems a bit curious because the 8811cu does not have Bluetooth, but the RFE type indicates it's BTG instead of WLG.

[morrownr]

@Smackd0wn

Both my working 8821cu and non-working 8811cu dongles have the value rfe_option 0x22, which is RFE type 2 (after & 0x1f type mask)

I think that is a hint that the problem does come back to the RFE type. One thing that would help me is if I had a better understand of the efuse system. Please educate me if you can.

That seems a bit curious because the 8811cu does not have Bluetooth, but the RFE type indicates it's BTG instead of WLG.

Something is wrong. A few years ago, after a few reports from 8821cu chipset users that the out-of-kernel driver was not working, I did a deep dive to see if I could discover the problem. I did not fully understand what I found but what I found was that if I set a new RFE type with the module parameter, we could fix the problem most of the time. It took trial and error and the best I could figure out was that different adapter makers were using different settings and we had to find the setting that worked with the problem adapter. Not a good system in my opinion but maybe the problem is actually somewhere else. Could it be that the data used by efuse is getting messed up due to incorrect data being supplied?

With the default out-of-kernel driver, I never see problems with the 8811cu chipset, only with the 8821cu. Now with the in-kernel driver, we seem to only be seeing problems with the 8811cu chipset.

[janh]

I'm seeing the issue with the in-kernel driver using an 8821cu device as well. On the other hand, an 8811cu device works fine here. Both are working with the out-of-tree driver.

Working device: RTL8811CU without mode switching

``` RTW: Chip Version Info: CHIP_8821C_U3_1T1R_RomVer(2) RTW: EEPROM ID = 0x8129 RTW: EEPROM Version = 0 RTW: EEPROM Regulatory=0x02 RTW: EEPROM Board Type=0x01 RTW: EEPROM Disable BT-coex, ant_num=1 RTW: hal_com_config_channel_plan chplan:0x7F RTW: EEPROM crystal_cap=0x2f RTW: EEPROM ThermalMeter=0x1e RTW: EEPROM Customer ID=0x00 RTW: EEPROM SupportRemoteWakeup=0 RTW: EEPROM rfe_type=0x22 RTW: EEPROM PAType_2G is 0x0, ExternalPA_2G = 0 RTW: EEPROM PAType_5G is 0x0, external_pa_5g = 0 RTW: EEPROM LNAType_2G is 0x0, ExternalLNA_2G = 0 RTW: EEPROM LNAType_5G is 0x0, external_lna_5g = 0 RTW: EEPROM TypeGPA = 0x0 RTW: EEPROM TypeAPA = 0x0 RTW: EEPROM TypeGLNA = 0x0 RTW: EEPROM TypeALNA = 0x0 RTW: EEPROM tx_bbswing_24G =0x00 RTW: EEPROM tx_bbswing_5G =0x00 RTW: EEPROM USB Switch=0 RTW: EEPROM VID = 0x0BDA, PID = 0xC811 ```

Non-working device: RTL8821CU mode-switching necessary

``` RTW: Chip Version Info: CHIP_8821C_U5_1T1R_RomVer(4) RTW: EEPROM ID = 0x8129 RTW: EEPROM Version = 0 RTW: EEPROM Regulatory=0x01 RTW: EEPROM Board Type=0x01 RTW: EEPROM Enable BT-coex, ant_num=1 RTW: hal_com_config_channel_plan chplan:0x7F RTW: EEPROM crystal_cap=0x0c RTW: EEPROM ThermalMeter=0x1f RTW: EEPROM Customer ID=0x00 RTW: EEPROM SupportRemoteWakeup=0 RTW: EEPROM rfe_type=0x22 RTW: EEPROM PAType_2G is 0x0, ExternalPA_2G = 0 RTW: EEPROM PAType_5G is 0x0, external_pa_5g = 0 RTW: EEPROM LNAType_2G is 0x0, ExternalLNA_2G = 0 RTW: EEPROM LNAType_5G is 0x0, external_lna_5g = 0 RTW: EEPROM TypeGPA = 0x0 RTW: EEPROM TypeAPA = 0x0 RTW: EEPROM TypeGLNA = 0x0 RTW: EEPROM TypeALNA = 0x0 RTW: EEPROM tx_bbswing_24G =0x00 RTW: EEPROM tx_bbswing_5G =0x00 RTW: EEPROM USB Switch=0 RTW: EEPROM VID = 0x0BDA, PID = 0xC820 ```

[lwfinger]

You do not state what the error is for 8821cu. Is it the failure to mode switch?

If so, your system should have the package usb_modeswitch installed. With that should come a file /usr/share/usb_modeswitch that contains an entry for 0bda:1a2b. With that working correctly, plugging in any Realtek device will automatically switch to the wifi device.

[janh]

You do not state what the error is for 8821cu. Is it the failure to mode switch?

Sorry, I should have been clearer. Mode switching works, but I get the authentication with … timed out error with the 8821cu device.

[lwfinger]

What kernel are you using and where is the driver from?

[morrownr]

Sorry, I should have been clearer. Mode switching works, but I get the authentication with … timed out error with the 8821cu device.

More to add to the conversation: I have 2 adapters based on the 8811cu chipset. I was testing them with the in-kernel driver yesterday with kernels 6.5 and 6.8 rc3. The results were the same on both kernels:

The Bostrend adapter works with the in-kernel driver and this out-of-kernel driver.

The Edup adapter does not work with the in-kernel driver but does work with this out-of-kernel driver. The error with the in-kernel driver that I am seeing is exactly what @janh said authentication with … timed out. I am going to dig deeper and report.

FWIW: Both adapters have the same VID-PID.

It seems that both the 8821cu and 8811cu can have similar problems with the in-kernel driver. Are different makers doing something different internal to the adapters that could cause this?

@morrownr

[lwfinger]

I do not know. Any problems with authentication are probably in the content-addressible memory, but I have no idea why they might be different. What device is the Edup one? I checked out their website, but that seemed to be wifi 6 stuff.

[lwfinger]

One thing you might do is try to capture the over-the-air packets with a second computer using wireshark. That way we can see what is being transmitted. If that does not help, then we can look at the data going to/from the USB device.

[morrownr]

Larry,

What device is the Edup one?

Edup EP-AC1635

Let me mention this again: I have seen strange things out of the 8821cu/8811cu based adapters for several years. I was able to give advise regarding RFE type that fixed some of the problems. Overall, these chipsets seem to have some gremlins, even with this out-of-kernel driver.

One thing you might do is try to capture the over-the-air packets with a second computer using wireshark.

Will do as able.

@janh

I have some health problems that are slowing me down so if you are able to capture some over-the-air packets as Larry suggested, please so. Don't wait on me.

[lwfinger]

What device is the Edup one?

Edup EP-AC1635

I just ordered one. The estimated delivery is Feb. 24.

[Smackd0wn]

I believe @wandou2018 encountered the same issue, at least the same symptom, i.e., authentication with … timed out. He has already done a capture, to find no packets sent from 88x1cu captured. That possibly indicates the TX part of the dongle is not working. That is, authentication issue is probably due to the fact the AP did not receive any packets.

[morrownr]

@Smackd0wn

He has already done a capture, to find no packets sent from 88x1cu captured.

Yes, I found the message. Thanks.

[lwfinger]

Not sending an authentication request would certaiinly explain why authentication is timing out. I have ordered one of the Edup devices with the problem and I will be looking at it more closely once that arrives.

[Smackd0wn]

Both my working 8821cu and non-working 8811cu dongles have the value rfe_option 0x22, which is RFE type 2 (after & 0x1f type mask)

I think that is a hint that the problem does come back to the RFE type. One thing that would help me is if I had a better understand of the efuse system. Please educate me if you can.

efuse is just a small (maybe 512 byte), one-time writable memory on the chip that is programmed (wrote) by the device vendor to stores configuration information, including the MAC address. I believe it it called EEPROM in the out-of-tree driver, which also reads the RFE type information from efuse, if it is not overridden by module options.

It is interesting that @janh has a working 8811cu and non-working 8821cu, both show RTW: EEPROM rfe_type=0x22, which is same as my non-working 8811cu and working 8821cu.

[morrownr]

@Smackd0wn

efuse is just a small (maybe 512 byte), one-time writable memory on the chip that is programmed (wrote) by the device vendor to stores configuration information, including the MAC address. I believe it it called EEPROM in the out-of-tree driver, which also reads the RFE type information from efuse, if it is not overridden by module options.

This is starting to make sense now.

It is interesting that @janh has a working 8811cu and non-working 8821cu, both show RTW: EEPROM rfe_type=0x22, which is same as my non-working 8811cu and working 8821cu.

My 2 adapters are both 8811cu with the same VID/PID but different makers. One works and one does not with the in-kernel driver. I need to investigate further.

[lwfinger]

The EFUSE layout is given in file rtw_8821c.h in the rtw88 files. Note that the layout for rtw)8821cs is much less rich than the value for the USB or PCIe versions,

My suspician is that the reason that devices from one vendor work and those of another haas to do with the encoding of the EFUSE, but I will be able to test that when my Edup device arrives.