May be worth calling out the importance of `rtw_switch_usb_mode` in the README about 88x2bu HOT 6 CLOSED

Ouch! You are right, this should probably get a write up in the USB recommendations section of the README.

The current default (2) is the result of problems with the other two options (0, 1). In fact, 2 has worked very well for a long time. It is interesting how this USB stuff is handled manually by Realtek because I also use adapters based on Mediatek chipsets. The Mediatek drivers, which are in-kernel, don't offer a module parameter. This is fully automated. I've never had a problem and have never seen anyone report a problem related to USB with the Mediatek drivers.

Anyway, it is what it is for now. Could I get you to write a paragraph for me to include? Your perspective would likely help you do a good job.

Regards

from 88x2bu.

After fiddling for over an hour with this repo/driver not working for me (I could see wifi networks but was in an infinite hanging/connection loop state)

I do not understand why your wifi connection issue can be caused by "rtw_switch_usb_mode".

As far as I know, if you plug it in a USB2 only port and set "rtw_switch_usb_mode=1" then you are in trouble. But it runs well with "rtw_switch_usb_mode=2" when plugged in a USB3 port. It just switches to USB2 mode and runs at a low speed, but there is no problem connecting to WiFi networks or setting up access points

from 88x2bu.

Having started using this driver very recently as an Access Point, I just wanted to report on the importance of rtw_switch_usb_mode, but to suggest to people; try both 1 and 2 if you are having problems.

I have a generic USB3 device bought from Amazon - identifies itself with vid/pid 0bda:b812 - which I plugged into a powered USB3 hub on an x86_64 machine with vanilla stable kernel.org release 5.10.74.

I initially set rtw_switch_usb_mode=1 with it being USB3. It initially worked, but as soon as the dongle needed to receive a heavy transfer of large amounts of data from a client (an rsync run on the client), the driver would send hostapd a signal to disassociate the client (which it did, killing the connection of course) around 10 - 20 secs into the transfer. This was reproducible consistently. After being kicked off, the client would be unable to associate again unless I killed and restarted hostapd.

To try and fix I tried switching/changing several other driver options as well as playing with various hostapd ones, with no resolution. Finally, although it didn't maker sense with it being a USB3 dongle plugged into a USB3 port, I changed to rtw_switch_usb_mode=2 and the problem went away, and I now have a functioning AP. Despite being forced into USB2 mode I find throughput is still excellent, since USB2 can cope with real-world AC speeds anyway.

Not sure if it is a quirk of my device. If I turn on full driver debugging it reports these lines about itself:
RTW: CHIP TYPE: RTL8822B
RTW: Chip Version Info: CHIP_8822B_U4_2T2R_RomVer(3)
RTW: NIC FW Version:30 SubVersion:20 FW size:161240

from 88x2bu.

It just switches to USB2 mode and runs at a low speed, but there is no problem connecting to WiFi networks or setting up access points

Why this happens is one of the great mysteries of the universe.

Seriously, running this driver in USB3 mode while in AP mode will result in dropped connections. It is a long standing problem and I have failed to document it properly. I need to correct that because AP can be reasonably good with this driver as long as you stick with USB2 mode.

from 88x2bu.

@eddiegb

This post is greatly appreciated as it makes it clear that better documentation is needed for AP mode with this driver.

I have a new version of this driver based on new source code. The repo is under construction but is available for those that want to help get the driver ready to go public. See issue 98 and let me know if you want to help. We need AP mode testers as managed mode is such that I'm not aware of any problems.

Having started using this driver very recently as an Access Point, I just wanted to report on the importance of rtw_switch_usb_mode, but to suggest to people; try both 1 and 2 if you are having problems.

I have a generic USB3 device bought from Amazon - identifies itself with vid/pid 0bda:b812 - which I plugged into a powered USB3 hub on an x86_64 machine with vanilla stable kernel.org release 5.10.74.

I initially set rtw_switch_usb_mode=1 with it being USB3. It initially worked, but as soon as the dongle needed to receive a heavy transfer of large amounts of data from a client (an rsync run on the client), the driver would send hostapd a signal to disassociate the client (which it did, killing the connection of course) around 10 - 20 secs into the transfer. This was reproducible consistently. After being kicked off, the client would be unable to associate again unless I killed and restarted hostapd.

It is very reproducible by any means that puts a heavy sustained load on the driver while in AP mode. I use iperf3 here and the connection will go down after 10-30 seconds like clockwork. Never a problem in managed mode with USB3 and never a problem in AP mode as long as you stick to USB2.

To try and fix I tried switching/changing several other driver options as well as playing with various hostapd ones, with no resolution. Finally, although it didn't maker sense with it being a USB3 dongle plugged into a USB3 port, I changed to rtw_switch_usb_mode=2 and the problem went away, and I now have a functioning AP. Despite being forced into USB2 mode I find throughput is still excellent, since USB2 can cope with real-world AC speeds anyway.

It is my bad for not documenting this better. This problem does not happen with the 8812au driver and chipset so I have pondered whether it could be a firmware issue specific to this chipset.

Not sure if it is a quirk of my device.

All evidence I've seen plus my personal experience indicates this is a widespread issue. not specific to your adapter.

Cheers

from 88x2bu.

@morrownr

Thanks for confirming it's a known issue. However, it is not your bad. If it's anyone's bad it's Realtek's, for not engaging with the their Linux users and leaving us completely on our own to figure these things out about their products, firmware & drivers. You, on the other hand, have gone out of your way to help us all. Whatever you might have omitted to do is irrelevant when you've freely given us so much already, despite being under no obligation.

from 88x2bu.