USB Wifi 5 -- BT + AC600 Driver free not functioning

Hello Strangers,

I have in my hands a shiny new dual purpose usb dongle for wifi 5 and bt. It does not function in any usb port when plugged in.
I've tried to check that it's detected:

# lsusb
Bus 002 Device 003: ID 25a7:2410  
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 013: ID 0bda:1a2b Realtek Semiconductor Corp. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 003 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

This is the device
Bus 001 Device 013: ID 0bda:1a2b Realtek Semiconductor Corp.

from there I went to tailing the journal to see what's going on:

Mar 30 16:41:35 desktop1.tmf.home kernel: usb 1-1.1: New USB device found, idVendor=0bda, idProduct=1a2b, bcdDevice= 2.00
Mar 30 16:41:35 desktop1.tmf.home kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 30 16:41:35 desktop1.tmf.home kernel: usb 1-1.1: Product: DISK
Mar 30 16:41:35 desktop1.tmf.home kernel: usb 1-1.1: Manufacturer: Realtek
Mar 30 16:41:35 desktop1.tmf.home kernel: usb-storage 1-1.1:1.0: USB Mass Storage device detected
Mar 30 16:41:35 desktop1.tmf.home kernel: scsi host6: usb-storage 1-1.1:1.0
Mar 30 16:41:35 desktop1.tmf.home mtp-probe[10779]: checking bus 1, device 14: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1"
Mar 30 16:41:35 desktop1.tmf.home mtp-probe[10779]: bus: 1, device: 14 was not an MTP device```

I have added a udev rule to handle this
```# cat /etc/udev/rules.d/99-realtek-wifi.rules 
SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="1a2b", MODE="0666"

as well have modified the usb_modeswitch file to ensure it's picked up and switched:

# Realtek wifi/bt dongle
TargetVendor=0x0bda
TargetProduct=0x1a2b
StandardEject=1
  • On plugin I note that the device number increments by 1 every time.
  • reboot does not impact the behaviour

I assume at this point that usb_modeswitch is not functioning correctly as it's not seen from within the journal, as well it references the incorrect usb bus(1-1.1) where from lsusb it should list as:

    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
        |__ Port 1: Dev 14, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            ID 0bda:1a2b Realtek Semiconductor Corp. 
        |__ Port 2: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:c534 Logitech, Inc. Unifying Receiver
        |__ Port 2: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            ID 046d:c534 Logitech, Inc. Unifying Receiver```

for reference as well, I attempted to manually run usb_modeswitch

```usb_modeswitch -v 0bda -p 1a2b -J
Look for default devices ...
 Found devices in default mode (1)
Access device 016 on bus 001
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
 with class 8
Use endpoints 0x0b (out) and 0x8a (in)
Using standard Huawei switching message
Looking for active drivers ...
 OK, driver detached
Set up interface 0
Use endpoint 0x0b for message sending ...
Trying to send message 1 to endpoint 0x0b ...
 Sending the message returned error -7. Try to continue
Read the response to message 1 (CSW) ...
 Response reading failed (error -7)
 Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!

any insight or assistance would be appreciated.

--GeekDad

Does this ubuntu forum thread help? Someone compiled a driver!

Key element to try first from that thread:

sudo usb_modeswitch -KW -v 0bda -p 1a2b

But poster found out that Realtek had changed the chipset without notifying anyone. But let's not forget that those devices are designed for that other OS!

1 Like

I did indeed try the following drivers from various git repos and sources:

drwxr-xr-x 10 tmf  tmf  4096 Mar 29 11:43 ../
drwxr-xr-x  9 tmf  tmf  4096 Mar 18 08:30 8821cu-20210916.FAILED/
-rw-rw-r--  1 tmf  tmf  2764 Mar 18 09:58 README
drwxrwxr-x 12 tmf  tmf  4096 Mar 30 11:50 rtl8812au/
drwxr-xr-x  8 tmf  tmf  4096 Mar 18 08:45 rtl8812au-NOT-WORKING/
drwxr-xr-x 12 tmf  tmf  4096 Mar 18 09:53 rtl8812au-WORKING-BROKEN-USB-SWITCHING/
drwxr-xr-x  9 root root 4096 Mar 18 10:44 rtl8821CU/
drwxr-xr-x  8 root root 4096 Mar 30 19:36 rtl8821cu/
drwxr-xr-x  8 root root 4096 Mar 18 10:35 rtl8821CU-OLD/

the one recommended through that thread I attempted:
# git clone https://github.com/MingxuZhang/rtl8821cu/

followed with cd to the dir, and a make which errored out with:

In file included from /home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/include/osdep_service.h:47,
                 from /home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/include/drv_types.h:32,
                 from /home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/core/rtw_cmd.c:22:
/home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/include/osdep_service_linux.h: In function ‘_init_timer’:
/home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/include/osdep_service_linux.h:302:8: error: ‘_timer’ {aka ‘struct timer_list’} has no member named ‘data’
  302 |  ptimer->data = (unsigned long)cntx;
      |        ^~
/home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/include/osdep_service_linux.h:303:2: error: implicit declaration of function ‘init_timer’; did you mean ‘_init_timer’? [-Werror=implicit-function-declaration]
  303 |  init_timer(ptimer);
      |  ^~~~~~~~~~
      |  _init_timer
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:297: /home/tmf/Documents/WIFI-ADAPTER/rtl8821cu/core/rtw_cmd.o] Error 1
make[1]: *** [Makefile:1906: /home/tmf/Documents/WIFI-ADAPTER/rtl8821cu] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-69-generic'
make: *** [Makefile:1908: modules] Error 2

I'm unsure which of the git repos you were attempting to reference, as well I'm wondering, the command you posted referenced a different device in comparison to the one I've discovered via lsusb: 0bda:1a2b

=================UPDATE=======================
I managed to get the following git to compile as well as install

git clone https://github.com/brektrou/rtl8821CU.git

after which I did make and make install with success; unplug/replug did not modify the output.

HOWEVER!! after which I ran:

usb_modeswitch -KW -v 0bda -p 1a2b

the results of which are here --> https://termbin.com/nvfc

and voila, worked.

2 Likes

Greetings,
I too had issue with installing Realtek based product. I have been testing the new Brostrend AX1800 (RTL8852bu) on several PC platforms all running Zorin 16.2 Pro (updated)
On older HP8200, Dell Precision, and an Acer Veriton PC's I had issue with the device being detected. On newer HP and even Lenovo M73 this was not a problem.

I want to say that the vendor installation package works great. Even if not detected you are prompted to select the desired driver, so that is not the issue.

There does appear to be a problem with the usb_modeswitch running on Z16.2
I do not agree that running usb_modeswitch -KW -v 0bda -p 1a2b
is the solution but a temp fix. In this case it properly activates the device ID 0bda:b832 however if you cold boot OR move your adapter to a different USB port it requires you to run it again to access your device.

I am in agreement with the Brostrend support that there is something not functioning properly on modeswitch 2.5.2 that runs on Z16.2 if I dual boot with Ubuntu 22.04 or 23.04 (kernel 6.2) the device works as expected. Both have modeswitch 2.6.1 installed.

I am in the process of verifying dependencies in order to force the upgrade to modeswitch 2.6.1 on a Z16.2 installation.

Regards,

Have you tried the Tux Invader Kernel?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.