(Realtek drivers do not support more than one adapter with the same chipset in the same computer) How to specify different driver options for multiple adapters?

[spcharc]

I bought two rtl88x2bu adapters and am planning to run one of them as an AP and another as a WiFi client. However after they arrived, I found out this introduces conflicting driver parameters. For the AP one I need "rtw_vht_enable=2", but this is a bad option for the client one. So my plan is to give them different driver options. How can I do that?

[morrownr]

You can't do what you are asking with Realtek based adapters. These Realtek drivers don't support more than one adapter with the same chipset in the same computer. However, testing has shown that the Mediatek drivers do support more than one adapter with the same chipset in the same computer. Recommend adapters with the mt7612u chipset. You can get more information and links at the following site:

https://github.com/morrownr/USB-WiFi

Additional info: Please read the issue right before this one. The user was asking what usb adapter to get. He got the TEROW ROW02FD but there are several usb adapters that use the mt7612u chipset. That adapter is good for AP mode. In fact, I use one for AP mode with a RasPi4b. Hopefully this info helps.

P.S. This issue has now come up enough that I am adding it to the FAQ at the bottom of the main page.

[spcharc]

@morrownr Oh I see. Wasn't expecting that ... Thank you, you are really helpful.

[spcharc]

Managed to get both of them working. I installed vmware player, and created a virtual linux machine, then assigned one of the adapters to the virtual machine. I installed your 88x2bu driver on both of the machines. The virtual machine handles the hostapd thing and the host machine works as a wifi client. Not a beautiful solution, but at least it works.

[spcharc]

I have to say the IO speed of a virtual machine is pretty bad. Comparing to an AP set up directly on the host machine, this virtual machine AP gives me around 20% of the original throughput (downloading a file goes from 60+MB/s to 13MB/s). I think I have to find a better solution.

---

Update: I think I found the reason: vmware player ate all the CPU resource when I started to download ...

[morrownr]

I respect determination. I had not thought of this solution. Let's leave this issue open and it you get it working reasonable well, post the details as it might help someone else.

It appears that I failed to mention that there is no problem with multiple Realtek based adapters in a computer as long as all have different chipsets. I have all 5 of the drivers I have up on this site installed. It is normal for me to have multiple adapters going at any one time. You just can't have two Realtek adapters with the same chipset. You can have one with a 8812bu chipset and another with a 8812au chipset that will work fine together. In fact, the driver for the 8812au is by far the best driver here. However, if you give me the choice between an adapter with a 8812au chipset and one with a mt7612u chipset, I will go for the mt7612u and it is not a hard decision.

[spcharc]

there is no problem with multiple Realtek based adapters in a computer as long as all have different chipsets.

So you mean the Realtek drivers do not conflict with each other, as long as they have different names?

Perhaps it has something to do with how the kernel loads the driver? Since multiple Realtek devices do not work under the same driver, then it appears to me that the kernel loads the driver only once and registers multiple devices to that driver. And if the driver fails to handle multiple devices then this problem appears. (I do not know how drivers work, this can be all wrong)

So I think: (it may sound very stupid to you)

Is it possible to rename the driver from 88x2bu to some other names, like "88x2bu1", "88x2bu2", ... and force the kernel to load different drivers for different devices? If this works, I can even specify different driver parameters in "88x2bu1.conf", "88x2bu2.conf" ...

[spcharc]

@morrownr It works! Renaming the driver is the key. Now both of them work as expected, and the network speed is way faster than the virtual machine. The virtual machine emulates USB using software which caused too much work load for the cpu. There are these things to change:

• /include/autoconf.h: DRV_NAME (I'm not sure if changing it is necessary. It's not the kernel module name for the kernel, but the usb driver name for usbcore)
• Makefile: MODULE_NAME
• dkms.conf: BUILD_MODULE_NAME, PACKAGE_NAME (I'm not sure if changing PACKAGE_NAME is necessary)
• /os_dep/linux/usb_intf.c: Change supported vendors, so only the driver you want to load get loaded when a usb device is detected.

Now I don't have to return them to amazon, nice. Thanks for your repo! (200 stars congrats) (Feel free to close this issue. I'm leaving it open for now)

---

currently my lsmod output is showing both drivers:

$ lsmod | grep cfg80211
cfg80211              704512  5 iwlmvm,88x2bu1,88x2bu2,iwlwifi,mac80211

(there are iwlmvm and iwlwifi because the computer comes with builtin wifi adapter Intel 3165)

[morrownr]

I'm going to leave this open for now.

You have really opened up a can of worms. It will be a few weeks before I can fully investigate this but this has promise.

I will encourage you to return one of the adapters and replace it with an adapter with a mt7612u chipset so that you can see the difference. Something like the follow might be worth looking at since you mentioned Amazon:

https://www.amazon.com/gp/product/B086L3D3NB

[spcharc]

@morrownr I saw your product review in that page, lol

You have really opened up a can of worms.

No I have not. It is not that complicated:

1. You told me multiple realtek drivers can work together
2. It looks like the kernel runs only one instance of driver to deal with multiple realtek devices with the same chipset, and this does not work well.
3. So I think, if one instance of driver can only handle one device, then why not run multiple instances of driver instead?
4. Rename the driver so I can load multiple instances of this driver into the kernel.

Yeah that is how I figured it out

[morrownr]

I should have been more specific. It is a can of worms for me, not you.

This and the other repos here are very heavily used. When last I counted, the repos here are getting around 5,000 hits per week. One of my main goals was to attempt to make using usb wifi adapters on Linux easier. I've put in a lot of hours on the documentation and the installation scripts for the Realtek drivers. I've also learned about the law of unintended consequences so I try to test a lot before introducing changes or additions. I've also put in a lot of work on the /USB-WiFi repo because most Linux users would benefit from using adapters that use in-kernel drivers. Realtek drivers are not a good thing for your average Linux user because, by their design, they will regularly cause problems due to a lack of updates that is inherent with out-of-kernel drivers.

It is one thing for a user to mod things on their system. It is another thing when I need to decide how to document this or add the capability to the installation script or both. The first step should be to document exactly what steps a user needs to take to make this happen. You changed 3 things. Do all 3 need to be changed? Would you like to take a stab at writing the document? It will be a couple of weeks before I can turn my attention to testing and otherwise working on the drivers again.

Something else to keep in mind: Only recently the changes were merged to make AP work reliably on this driver... it seems to be reliable. I hope it is reliable. When people ask, I only recommend 2 chipsets for 5 GHz AP mode... mt7612u and rtl8812au. APs that are not reliable, and I mean 24/7/365 reliable, make for a lack of happiness. This message is coming to you via my homemade AP. 5 GHz uses an adapter with a mt7612u chipset and 2 Ghz uses an adapter with a ar9271 chipset. I use a RasPi4b and hostapd. Both adapters and their drivers are rock solid.

Looking forward to your docs so I can test.

Regards.

[spcharc]

Ahhhh I see... But do you really have to document this? I mean there will only be very very limited people who need this ...

[spcharc]

Reporting back: After 10 days, this setup seems very stable. Both adapters (and their 88x2bu drivers) work flawlessly. This issue can be closed now.

[Quackoman]

@spcharc can you maybe post a few more detailed steps to reproduce multiple driver modules loaded at the same time?

i'm not clear on how i should edit /os_dep/linux/usb_intf.c: to ensure the right driver gets loaded.

in my case the two adapters show like this for lsusb with the same vendor and product id Bus 001 Device 004: ID 0bda:b812 Realtek Semiconductor Corp. Bus 001 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. USB2.0 Hub

I'm of the stance that it isn't possible because no matter what the two cards are identical when read and loaded.

[morrownr]

No two networking devices are identical. All have different MACs.

[spcharc]

I'm of the stance that it isn't possible because no matter what the two cards are identical when read and loaded.

Ahhhhhh I see. Yeah you are right it seems not possible currently ... I do not know much about the USB specification, but AFAIK it seems when driver is not loaded, the only thing the OS knows about a USB device is the [vendor id]:[product id] pair?

If this is true then currently there is no way to load different drivers for two different WiFi dongles with the same [vendor id]:[product id] pair. You have to have two WiFi dongles with two different [vendor id]:[product id] pairs.

But please do not quote me on this since it can be all wrong (as I said I do not know much about how USB works). If you know any other way to force the OS to load two different instances of drivers, then I believe it will work.

No two networking devices are identical. All have different MACs.

You are right, however when the driver is not loaded, the MAC address is unknown. I think you cannot use the MAC address to differentiate the WiFi dongles and force the OS to load another instance of driver.

[spcharc]

Here is a stackexchange answer talking about how USB drivers get loaded under Linux:

Every driver in the Linux kernel is responsible for one or more devices. The driver itself chooses what devices it supports. It does this programmatically, i.e. by checking the device's vendor and product ID, or, if those aren't available (e.g. an old device), performing some auto-detection heuristics and sanity checks. Once the driver is confident it's found a device it supports, it attaches itself to it. In short, you often can't force a particular driver to use a particular device.

So my assumption was correct. Linux loads only one instance of driver, and the problem was cause by the driver not supporting multiple devices.

[ByteArrayException]

Hi, after a few years I have a question :D Is it now possible (or even possible at all) to operate several sticks with the same USB product ID of an RTL8812BU chipset using the rtw88 repo from lwfinger? Or is the performance there too bad or does it not work at all? My problem is that I have 2 sticks from the same manufacturer and the same model and only after the boot both connect to the configured WiFi APs. However, if I want to change the WiFi of one of the 2 sticks during operation, this is not possible until I disconnect both connections and delete all connections from the NetworkManager in order to set them up again afterwards. After setting them up again, everything works. If an AP is disconnected during operation and comes back after a while, it does not reconnect at all until the next restart.

[spcharc]

@ByteArrayException I have not tried the repo you mentioned, but I did try the rtw88_usb driver in recent linux kernel (rtw_8822bu)

TLDR: It does not work well for me.

First of all, when I tried to create 5GHz AP, the rtw88 driver somehow didn't allow it. I forgot what hostapd said during my experiments, but I just could not successfully create an AP.

Besides, I don't know how to modify it to accept only some vendor_id:device_id pair not others without replacing the kernel, so both of my usb adapters have to use the same driver when I use rtw88. Maybe there is some method to do it, I'm just not familiar with linux kernel modules.

So since I already have a working solution I'm just too lazy to move to other drivers.

If you are interested you can always do experiments with rtw88 in different kernel versions. Sometimes they do update the in-kernel drivers which may make a difference.

[ByteArrayException]

@spcharc Hello, thank you for your feedback. But is it possible to simply compile the rtl88x2bu driver twice and then only one pulls the first driver and the other the second driver? I have to leave the vendor and product ID for both, because otherwise the driver cannot be used. I would think, I think that's what you described, that it takes the ‘first driver’ and the second one twice. Otherwise I will test if this works. However, I also had the phenomenon months ago that 2 different drivers were loaded.

[morrownr]

@ByteArrayException

after a few years I have a question :D Is it now possible (or even possible at all) to operate several sticks with the same USB product ID of an RTL8812BU chipset using the rtw88 repo from lwfinger?

It may be possible using the rtw88 series of in-kernel drivers. I recently tested again usb adapter/modules using the mt7610u, mt7612u and mt7921au chips and I did not find any problems using more that one instance of those chips/drivers. I cannot say the same about rtw88 as I have not tested this. I think I will test it. I am part of a small group that is working to improve rtw88.

We started with rtw88_8821cu as it was in really bad shape. Five patches in kernel 6.9 and it is working much better. Our current project is to add a driver rtw88 for the rtl8821/11au chip. We are in testing so if you have anything with that chipset, let me know.

Based on my testing of rtw88_8822bu, the driver performance in managed mode is reasonably good. The driver does support USB3 but that can be fixed. The bottom line is that we all need to get away from these out-of-kernel drivers as soon as is practical.

We are using rtw88 at:

https://github.com/lwfinger/rtw88

It is ahead of rtw88 in any stable Linux kernel as it is based on wireless-next and code is going in regularly. I will eventually make a new Issue here to discuss improvements to rtw88_8822bu but now is not the time. Please report your results back here for now.

@morrownr

[morrownr]

@ByteArrayException @spcharc

I am testing running two rtl8812bu based usb adapters right now. They both have the same vid/pid. I am using the rtw88 repo at:

https://github.com/lwfinger/rtw88

Following the installation instructions carefully.

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.135 port 56064 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  43.6 MBytes   366 Mbits/sec    0    977 KBytes       
[  5]   1.00-2.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   2.00-3.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   3.00-4.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   4.00-5.00   sec  41.2 MBytes   346 Mbits/sec    0    977 KBytes       
[  5]   5.00-6.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   6.00-7.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   7.00-8.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   8.00-9.00   sec  40.0 MBytes   336 Mbits/sec    0    977 KBytes       
[  5]   9.00-10.00  sec  41.2 MBytes   346 Mbits/sec    0    977 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   406 MBytes   341 Mbits/sec    0             sender
[  5]   0.00-10.02  sec   403 MBytes   338 Mbits/sec                  receiver

$ lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=rtw_8822bu, 480M
    |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 5, If 0, Class=Vendor Specific Class, Driver=rtw_8822bu, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 4: Dev 4, If 3, Class=Video, Driver=uvcvideo, 480M
        |__ Port 4: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 480M
        |__ Port 4: Dev 4, If 2, Class=Video, Driver=uvcvideo, 480M
        |__ Port 4: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 5: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 5: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 7: Dev 4, If 0, Class=Wireless, Driver=btusb, 480M
        |__ Port 7: Dev 4, If 1, Class=Wireless, Driver=btusb, 480M
        |__ Port 7: Dev 4, If 2, Class=Wireless, Driver=, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M

$ lsusb
Bus 003 Device 004: ID 13d3:3568 IMC Networks Wireless_Device
Bus 003 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 003: ID 1d5c:5001 Fresco Logic USB3.0 Hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 005: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
Bus 005 Device 003: ID 1d5c:5011 Fresco Logic USB2.0 Hub
Bus 005 Device 004: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 046d:081d Logitech, Inc. HD Webcam C510
Bus 004 Device 003: ID 1058:1020 Western Digital Technologies, Inc. My Book AV      
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I am using one adapter in P2P mode connected to a printer and one in managed mode providing an internet connect. Everything works.

[ByteArrayException]

Hi @morrownr, I will test it later today with my Archer T3U (both RTL8812BU chipset) and give you feedback here. Your repo for this chipset is absolutely insane, but when using the same model from the same manufacturer twice, there was this misbehaviour as described above. But that seems to have been ‘normal’. If this goes very well, I would be very happy :D Otherwise, as already mentioned, I will give the problems here. I really appreciate the work you put into this!

[ByteArrayException]

@morrownr @spcharc Hi, the RTW88 driver from lwfinger works really well! Thank you for your help and work. All the problems I described no longer occur.

[morrownr]

@ByteArrayException

Good. Hopefully we can get USB3 support pushed to the kernel soon. The driver is fast and will be faster than most people really need but it will be faster once USB3 support is in place,

We really need to get rtw88 in good shape so these out-of-kernel driver can be retired. They are not very good in many ways.

[morrownr]

@ByteArrayException

Yes, a lot of improvements are going into rtw88 right now. What you see in lwfinger's rtw88 will end up in the kernel given time as it is basically a downstream repo. We are aware that rtw_8822bu needs usb3 support and LED support and I think those can come soon enough. Right now we are working to add rtw_8821au... no kidding... soon to be followed by rtw_8812au. We are also working on the existing rtw88 drivers. Hopefully things are in really good shape by the time the next LTS kernel rolls around.

We really need to retire these out-of-kernel drivers as Realtek has not done a very good job with them.