Is the firmware present on your system?  Try to boot with firmware_class.dyndbg=+p boot option.  It'll enable the debug prints from the firmware loader, and you can see each attempt and failure.

Adding Larry to Cc, as he might have seen a similar problem.

The firmware is found. As shown in the following log fragment:

[    8.511742] rtw_8821cu 2-2:1.0: Firmware version 24.11.0, H2C version 12
[    8.613917] usbcore: registered new interface driver rtw_8821cu
[    8.619664] rtw_8821cu 2-2:1.0 wlp0s20u2: renamed from wlan0

The device would not know the firmware version unless the firmware were loaded into host memory. In addition, it would not have produced wlan0 unless it could download the firmware and start the device.

The following fragment is problematic:

[ 2275.806334] usb 2-2: USB disconnect, device number 3
[ 2275.820328] wlp0s20u2: deauthenticating from 1c:3b:f3:4f:1a:d5 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 2276.260348] rtw_8821cu 2-2:1.0: timed out to flush queue 0
[ 2276.586935] rtw_8821cu 2-2:1.0: timed out to flush queue 1
[ 2276.753528] rtw_8821cu 2-2:1.0: timed out to flush queue 0
[ 2276.946902] rtw_8821cu 2-2:1.0: timed out to flush queue 3
[ 2277.080243] rtw_8821cu 2-2:1.0: timed out to flush queue 0
[ 2277.216843] rtw_8821cu 2-2:1.0: timed out to flush queue 1

I have no idea why there was a USB disconnect. All I can say is that power was not lost to the wifi device. In any case, it was left in a state where it could not re-download the firmware; however, as shown below, the device recovered using the firmware that was already downloaded, and made a connection to the AP:

[ 2277.756761] usb 2-2: new high-speed USB device number 13 using xhci_hcd
[ 2277.900721] usb 2-2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[ 2277.900736] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2277.900742] usb 2-2: Product: 802.11ac NIC
[ 2277.900746] usb 2-2: Manufacturer: Realtek
[ 2277.900750] usb 2-2: SerialNumber: 123456
[ 2278.083006] rtw_8821cu 2-2:1.0: Firmware version 24.11.0, H2C version 12
[ 2279.111521] rtw_8821cu 2-2:1.0 wlp0s20u2: renamed from wlan0
[ 2279.203609] rtw_8821cu 2-2:1.0: failed to download firmware
[ 2284.663699] wlp0s20u2: authenticate with 1c:3b:f3:4f:1a:d5
[ 2285.319818] wlp0s20u2: send auth to 1c:3b:f3:4f:1a:d5 (try 1/3)
[ 2285.326229] wlp0s20u2: authenticated
[ 2285.332573] wlp0s20u2: associate with 1c:3b:f3:4f:1a:d5 (try 1/3)
[ 2285.339386] wlp0s20u2: RX AssocResp from 1c:3b:f3:4f:1a:d5 (capab=0x11 status=0 aid=4)
[ 2285.343326] wlp0s20u2: associated

My interpretation is that something is funky with the USB system, and that the RTW8821CU is doing what it should.

The rtw88 driver does not deal with LEDs at all. When you changed from the vendor driver to the in-kernel rtw88, that is when the LEDs stopped blinking.

Created attachment 868886 [details]
dmesg as result of firmware_class.dyndbg=+p boot option

I have also witnessed network not connecting at all until replugging the USB device and have dmesg of it if needed. USB subsystem (hardware-wise) doesn't have problems, e.g. I have a USB3 external drive connected via fstab entry 24/7.

Apologies for thinking LED functionality is handled with device firmware.

After using the system 1-2 hours I notice my connection is gone and when I re-plug the USB wifi it reconnects. I noticed the following on dmesg

wlp0s20u2: send auth to 1c:3b:f3:4f:1a:d5 (try 1/3)
[ 2922.288871] rtw_8821cu 2-2:1.0: failed to get tx report from firmware
[ 2922.395493] wlp0s20u2: send auth to 1c:3b:f3:4f:1a:d5 (try 2/3)
[ 2922.902118] rtw_8821cu 2-2:1.0: failed to get tx report from firmware
[ 2923.408852] wlp0s20u2: send auth to 1c:3b:f3:4f:1a:d5 (try 3/3)
[ 2923.915445] rtw_8821cu 2-2:1.0: failed to get tx report from firmware

You have 3 different primary USB hubs on your system, and a number of secondary hubs:

hub 1: USB3, 2 ports detected
    Port 1: Hub with 8 ports
hub 2: USB3: 11 ports detected
    Port 2: Device 0bda:c811 - Your wifi
    Port 3: Device 0bda:5776 - HP Truevision HD (Your camera?)
    Port 4: Device 06cb:114f - Synaptics Touchpad
    Port 5: Device 048d:8350 - ITE Device(8350) (Keyboard?)
    Port 6: Hub with 4 ports
        Port 1: Device 058f:6387 - Flash Disk
        Port 3: Device 03f0:2d12 - HP Officejet 4500
        Port 4: Hub with 4 ports
            Port 1: Device 046d:c534 - Logitech USB Receiver (ext. kbd + mouse?)
            Port 3: Device 046d:c52b - Logitech USB Receiver (ext. mouse/kbd?)
hub 3: USB3: 4 ports detected
    Port 1: Device 1058:2620 - A Western Digital disk drive
    Port 2: USB3 Hub with 4 ports

A glitch on primary hub2 could affect the wifi, but not mess up your external hard drive. It is also possible that the total current draw on hub 2 is exceeded. A wifi device draws near the limit by itself.

Do you have any other external USB ports available? If so, move the wifi device to it. In the dmesg log, you will see a string of messages like

[    4.045510] usb 2-2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[    4.045518] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    4.045521] usb 2-2: Product: 802.11ac NIC
[    4.045524] usb 2-2: Manufacturer: Realtek
[    4.045526] usb 2-2: SerialNumber: 123456

What I would like to see is the "usb 2-" changed to "usb 1-" or "usb 3-".

If that is not possible, do you have access to an external, powered hub? If so, plug it in where the external hard drive is now plugged, and plug the external hard driver and the wifi into that external hub.

In the above analysis, I have assumed that all of the secondary hubs are internal. If that is not the case, please let me know.

(In reply to Larry Finger from comment #6)
> You have 3 different primary USB hubs on your system, and a number of
> secondary hubs:
> 
> hub 1: USB3, 2 ports detected
>     Port 1: Hub with 8 ports
> hub 2: USB3: 11 ports detected
>     Port 2: Device 0bda:c811 - Your wifi
>     Port 3: Device 0bda:5776 - HP Truevision HD (Your camera?)
>     Port 4: Device 06cb:114f - Synaptics Touchpad
>     Port 5: Device 048d:8350 - ITE Device(8350) (Keyboard?)
>     Port 6: Hub with 4 ports
>         Port 1: Device 058f:6387 - Flash Disk
>         Port 3: Device 03f0:2d12 - HP Officejet 4500
>         Port 4: Hub with 4 ports
>             Port 1: Device 046d:c534 - Logitech USB Receiver (ext. kbd +
> mouse?)
>             Port 3: Device 046d:c52b - Logitech USB Receiver (ext.
> mouse/kbd?)
> hub 3: USB3: 4 ports detected
>     Port 1: Device 1058:2620 - A Western Digital disk drive
>     Port 2: USB3 Hub with 4 ports
> 
> A glitch on primary hub2 could affect the wifi, but not mess up your
> external hard drive. It is also possible that the total current draw on hub
> 2 is exceeded. A wifi device draws near the limit by itself.
> 
> Do you have any other external USB ports available? If so, move the wifi
> device to it. In the dmesg log, you will see a string of messages like
> 
> [    4.045510] usb 2-2: New USB device found, idVendor=0bda, idProduct=c811,
> bcdDevice= 2.00
> [    4.045518] usb 2-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [    4.045521] usb 2-2: Product: 802.11ac NIC
> [    4.045524] usb 2-2: Manufacturer: Realtek
> [    4.045526] usb 2-2: SerialNumber: 123456
> 
> What I would like to see is the "usb 2-" changed to "usb 1-" or "usb 3-".
> 
> If that is not possible, do you have access to an external, powered hub? If
> so, plug it in where the external hard drive is now plugged, and plug the
> external hard driver and the wifi into that external hub.
> 
I have unplugged the USB3 port connected WD external drive, plugged it into USB3 hub and plugged the USB2 rtl8821cu USB Wifi to it and booted.
I noticed a lag at network service start and when I booted into GUI, network wasn't available. When I removed it from that USB3 port and re-plugged to the dedicated USB2 port on the left of the machine, network was back up.

 I am absolutely sure that the port is fine since I do 10-13 hour face recognition sessions with digikam on that usb3 WD drive both under Linux and Windows.

> In the above analysis, I have assumed that all of the secondary hubs are
> internal. If that is not the case, please let me know.

You are right, I have only a USB3 hub and a USB1.1 hub connected to it for low power/speed keyboard/mouse receiver.

BTW this is what happened when I unplugged the rtl8821cu from that USB3 port and re-plugged to its own USB2 port.

Unfortunately from time to time, I have to use Windows 10 for a long time. For example watching TV series on Amazon Prime (in HD). I have never seen the device stopped functioning since you know, Windows immediately notifies re-connection etc.

This is what happened when I unplugged the wifi usb from port and re-plugged to its own dedicated port (USB2). I will attach the dmesg too .

[  220.840863] usb 2-1: USB disconnect, device number 2
[  226.952717] usb 2-2: new high-speed USB device number 11 using xhci_hcd
[  227.099720] usb 2-2: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[  227.099728] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  227.099731] usb 2-2: Product: 802.11ac NIC
[  227.099733] usb 2-2: Manufacturer: Realtek
[  227.099735] usb 2-2: SerialNumber: 123456
[  227.109651] rtw_8821cu 2-2:1.0: Firmware version 24.11.0, H2C version 12
[  227.797461] rtw_8821cu 2-2:1.0 wlp0s20u2: renamed from wlan0
[  233.340730] wlp0s20u2: authenticate with 1c:3b:f3:4f:1a:d5
[  233.993136] wlp0s20u2: send auth to 1c:3b:f3:4f:1a:d5 (try 1/3)
[  233.993648] wlp0s20u2: authenticated
[  233.995986] wlp0s20u2: associate with 1c:3b:f3:4f:1a:d5 (try 1/3)
[  234.002861] wlp0s20u2: RX AssocResp from 1c:3b:f3:4f:1a:d5 (capab=0x11 status=0 aid=5)
[  234.006966] wlp0s20u2: associated

Created attachment 868892 [details]
dmesg output of boot/no network after changing USB port of wifi device

Created attachment 868894 [details]
Macbook 5.1 is also having the same issue with the rtl8821cu Wi-Fi

I also use Tumbleweed at work on a Macbook 5.1 from Apple. It is running slightly newer kernel because of the nouveau freeze issue. Its USB works flawlessly. I plugged the rtl8821cu to it and saw same issues happening.

Additionally, I tried reverting to rtl8821cu-kmp-default from Sauerland OBS on that HP (not this Mac), it shows same issues.

As this is a cheap USB Wifi dongle I would assume there is something wrong with the hardware however it is working under Windows with exact same configuration.

The USB drivers for the rtw88xxu devices are still a work in progress, thus the 6.4.x driver has some problems. There is one patch currently in wireless-next, which will be in kernel 6.6 that may be pertinent. The commit message is as follows:

    wifi: rtw88: usb: silence log flooding error message
    
    When receiving more rx packets than the kernel can handle the driver
    drops the packets and issues an error message. This is bad for two
    reasons. The logs are flooded with myriads of messages, but then time
    consumed for printing messages in that critical code path brings down
    the device. After some time of excessive rx load the driver responds
    with:
    
    rtw_8822cu 1-1:1.2: failed to get tx report from firmware

PLease run the following commands:

sudo zypper in make gcc kernel-devel kernel-default-devel git libopenssl-devel
git clone https://github.com/lwfinger/rtw88.git
cd rtw88
make
sudo make install

Then reboot. If you are using secure boot, replace that last line with 'sudo make sign-install', and be sure to read the section on signing in README.md in the rtw88 directory.

It may be that the dongle is defective, but we need to explore all options before we make that conclusion.

When you unplugged the wifi usb from port and re-plugged to its own dedicated port (USB2), you were still connected to primary hub 2, and just moved from port 1 to port 2.

[  220.840863] usb 2-1: USB disconnect, device number 2
[  226.952717] usb 2-2: new high-speed USB device number 11 using xhci_hcd

Created attachment 868900 [details]
problem continues with built driver

I have compiled&sign-installed the module and it was rejected to load while I did install its key on mokutil.

I disabled secure boot and loaded fine. Unfortunately the issue still remains. Interestingly, kmod of Sauerland except 1 time disconnecting, running more stable. I didn't really know rtl8821cu-kmp-default was a separate code, I thought once it was mature enough, they accepted into kernel.

I noticed these new lines too
[  418.068638] rtw_8821cu 2-2:1.0: Firmware version 24.11.0, H2C version 12
[  419.003924] rtw88_8821cu: disagrees about version of symbol rtw8821c_hw_spec
[  419.003938] rtw88_8821cu: Unknown symbol rtw8821c_hw_spec (err -22)

A driver is prepared and tested by an author. It is then published, and then reviewed by the community. Once all the reviewers comments are satisfied, then it is merged into one of the -next trees, and ultimately into mainline Linux. Do you think that makes it error free? What about a different work flow than the author tested? There are many things that still need to be fixed.

The Sauerland code comes from my rtw88 repo, thus using it is the same as building my code. The symbol disagreement means that something has gone wrond with the particular build, or you are getting mixed modules from the keernel and whatever packages you have installed. Use 'lsmod | grep rtw' to look at what is loaded.

(In reply to Larry Finger from comment #12)
> A driver is prepared and tested by an author. It is then published, and then
> reviewed by the community. Once all the reviewers comments are satisfied,
> then it is merged into one of the -next trees, and ultimately into mainline
> Linux. Do you think that makes it error free? What about a different work
> flow than the author tested? There are many things that still need to be
> fixed.
> 
> The Sauerland code comes from my rtw88 repo, thus using it is the same as
> building my code. The symbol disagreement means that something has gone
> wrond with the particular build, or you are getting mixed modules from the
> keernel and whatever packages you have installed. Use 'lsmod | grep rtw' to
> look at what is loaded.

Hello and thanks again for everything. I finally have good news, I left the machine on and connected overnight, at the morning the network connection was fine with "your" driver I built from the source and there was nothing interesting on dmesg log. A Windows 10 was stuck in a VM constantly rebooting so there was some considerable load (2 cores out of 4) on the machine and USB subsystem too.

Another update. Now the problem started again, I also had couple of kernel crashes (caps blinking) after unplug/replug of the device to fix network, I enabled kdump with default settings and will have some kind of dump file.

Created attachment 868926 [details]
dmesg as a result of removing/replugging the rtl8821cu usb device several times

I finally managed to crash the kernel and have a kernel dump/dmesg in /var/crash. Attaching the dmesg, kdump (about 200mb) is here in case needed.

I also suspect cheap hardware so I did try something, under Virtualbox, I captured the 8821cu USB and it is working flawless there under Windows 10 with led etc all working. As the Windows wasn't booted for months, there was a severe network/cpu load because of updates too. To be sure, I captured the USB while there was several disconnects.

Created attachment 868933 [details]
message containing kernel patch for kernel crashing after several USB reconnects

Kernel developer Sascha Hauer sent me this e-mail as a possible remedy for kernel crash after several physical USB reconnects. Quote from the mail:

"> [  826.359174] rtw_8821cu 2-2:1.0: failed to setup chip information
> [  826.359713] rtw_8821cu: probe of 2-2:1.0 failed with error -22

Here we have a failure in probing the device. Data structures are freed
in the error path, but it seems we still have urbs queued. These
complete below and then the completion handler accesses already freed
memory which results in a kernel crash.

I attached a patch which you could try. Be warned it's completely untested.
I found some other oddities and I am not sure currently what happens
when rtw_usb_probe() races with rtw_usb_disconnect(). I suspect there
might be more bugs when the device is unplugged while the probe function
runs."

Created attachment 868958 [details]
dmesg output of boot&several physical reconnects

I have managed to branch the kernel-default, add the patch to fix the kernel crash as result of several USB insert/remove cycles. It is at

https://build.opensuse.org/package/show/home:ilgazcl:branches:openSUSE:Factory/kernel-default

Obviously as the kernel maintainer says, it wasn't really widely tested so I didn't submit anything but at least here on this HP laptop+rtl8821cu it works. I tried like 15-20 times reconnecting the USB dongle.

Sasha Hauer has submitted this patch to wireless-next. Once it is merged there, I will add it to my rtw88 repo and push it. Once that happens, Sauerland will pick it up as well.

Thanks for testing.

Created attachment 868985 [details]
patch resolving kernel crash issue resulting from multiple rtl8821cu physical device reconnects

Linux Wireless List URL: https://patchwork.kernel.org/project/linux-wireless/patch/20230823075021.588596-1-s.hauer@pengutronix.de/

I have tested this patch on real 8821cu USB hardware replugging the device 17-18 times. It fixed the kernel crash happening as result of 5-7 physical reconnects.

I am keeping it in my repo until it is in the official kernel. Only X86_64 enabled to ease burden on OBS.

Thanks.  I sent a PR to include the fix patch for TW stable git branch.

(In reply to Larry Finger from comment #12)
> 
> The Sauerland code comes from my rtw88 repo, thus using it is the same as
> building my code. The symbol disagreement means that something has gone
> wrond with the particular build, or you are getting mixed modules from the
> keernel and whatever packages you have installed. Use 'lsmod | grep rtw' to
> look at what is loaded.

The symbol disagreement comes because the kernel driver and the git drivers are using different naming schemes.

After using the naming scheme from the Kernel drivers for the git drivers, the symbol disagreement are gone (see makefile.patch)

(In reply to Ilgaz Öcal from comment #19)
> Created attachment 868985 [details]
> patch resolving kernel crash issue resulting from multiple rtl8821cu
> physical device reconnects
> 
> Linux Wireless List URL:
> https://patchwork.kernel.org/project/linux-wireless/patch/20230823075021.
> 588596-1-s.hauer@pengutronix.de/
> 
> I have tested this patch on real 8821cu USB hardware replugging the device
> 17-18 times. It fixed the kernel crash happening as result of 5-7 physical
> reconnects.
> 
> I am keeping it in my repo until it is in the official kernel. Only X86_64
> enabled to ease burden on OBS.

This patch was inserted and new drivers are build.

Stephan

(In reply to Stephan Hemeier from comment #21)
> The symbol disagreement comes because the kernel driver and the git drivers
> are using different naming schemes.
> 
> After using the naming scheme from the Kernel drivers for the git drivers,
> the symbol disagreement are gone (see makefile.patch)

The module name disagreement between git and the kernel is intentional! With that scheme, I can tell which driver is being used.

Read the section from README.md about blacklisting the kernel drivers if you want to use these drivers. It is essential.