New 88x2bu driver v5.13.1-20-gbd7c7eb9d.20210702

[morrownr]

Request that you test and report any problems. Specific bugs should be reported by opening a new issue. Discussion can go here.

Of note: I am requesting that you follow the documentation so as to check and provide correction to the documentation. It could be easy to miss issues in the documentation if you used the prior version of this driver.

Of particular interest is AP mode operation. Hopefully AP mode is MUCH better now.

Nick

[spcharc]

Reporting back:

It seems two 88x2bu adapters still cannot work simultaneously. Only one of them operated normally in my test.

So it seems my solution in morrownr/88x2bu#73 is still the only option ...

Even if this driver does allow two adapters to run, you would not be able to give different driver parameters to different adapters. My solution allows this, which can be useful in some cases. (For example in my case, rtw_vht_enable=2 for the Access Point one and rtw_vht_enable=1 for the Managed Mode one.)

---

Edit: tested download speed through my AP (which is just a wifi extender), showing 360+Mbps, a little faster than the screenshot I posted in morrownr/88x2bu#79 .

WPA3-SAE works! However since I have only one device that supports WPA3, I have to continue to use WPA2 for my AP.

[henkv1]

I didn't notice any difference when using AP mode.
FT-PSK is still not working, 5GHz signal strength is still weak and the 2.4GHz signal is not reliable.
On the other hand: things didn't get worse, this adapter just isn't great in AP mode and unfortunately this new driver version did not solve that.

[morrownr]

It seems two 88x2bu adapters still cannot work simultaneously. Only one of them operated normally in my test.

So it seems my solution in morrownr/88x2bu#73 is still the only option

I'm going to step back and look at the big picture for a moment.

While we may enjoy a good hack, the existing hack is not something that we can put in the docs and support. The simple fact is that until or if Realtek wants to do this the right way, running two of the same kind of adapter in the same system is going to be problematic. As you pointed out, even with your hack, if you want one adapter in managed mode and the other in master mode and they need different module parameters, how do we do that?

So what is the solution that would best serve the community? Probably to rewrite the entry in the FAQ to not just say it can't be done but to point out this it is not a feature that Realtek supports and also provide recommended solutions for those wanting to run two or more adapters in a single system. Thoughts?

We do know that two or more adapters can run in a single system. My normal configuration on my main dev box is to have two adapters and sometimes as many as 4 and they all work well. I just don't use 2 adapters that use the same Realtek chipset at the same time. I've had as many 4 Realtek based adapters in one system and things worked well but the adapters all had different chipsets.

Even if this driver does allow two adapters to run, you would not be able to give different driver parameters to different adapters. My solution allows this, which can be useful in some cases. (For example in my case, rtw_vht_enable=2 for the Access Point one and rtw_vht_enable=1 for the Managed Mode one.)

Edit: tested download speed through my AP (which is just a wifi extender), showing 360+Mbps, a little faster than the screenshot I posted in morrownr/88x2bu#79 .

Managed mode seems to work very well.

WPA3-SAE works! However since I have only one device that supports WPA3, I have to continue to use WPA2 for my AP.

Unfortunately it will be a while before WPA3 works seemlessly like it does with the Mediatek drivers.

Have you been able to check AP mode?

[morrownr]

I didn't notice any difference when using AP mode. FT-PSK is still not working, 5GHz signal strength is still weak and the 2.4GHz signal is not reliable.

I gave it a try in AP mode last night here and I was really disappointed. What you describe plus it would just drop offline at times when pushed.

On the other hand: things didn't get worse, this adapter just isn't great in AP mode and unfortunately this new driver version did not solve that.

Very true. This is sad. I just finished bringing new drivers for the 8812au and 8821au (8811au) online and the AP mode works wonderfully on those adapters. Earlier this morning I was poking around in the code and noticed that core/rtw_ap.c is identical with the same file in the new 8812au driver. These problems are in the driver for the 8811cu chipset also. However, the driver for the 8811au is very good.

So, what we have is bad AP mode for the newer chipsets, 8812bu and 8811cu, and very good for the older chipsets, 8812au and 8811au. Could this be a problem with the newer chipsets or with the firmware for the newer chipsets? I don't know but I can take it even further... it is the same for monitor mode. Monitor mode works well on the older chipsets but bad on these newer ones. My plan for this new driver is simply to not activate monitor mode and to leave it out of the README as a supported feature. That really should not be a big deal since almost all users that require monitor mode support either use adapters based on the Mediatek chipsets or the 8812au and 8811au chipsets. In other words, monitor mode has always sucked on these newer chipsets and the same can be said for AP mode.

Should we shut AP mode down on this driver and simply advise people to get adapters with one of the following chipsets if the need AP mode?

mt7612u
mt7610u
rtl8812au
rtl8811au

My experience is that those 4 chipsets are the only ones where Linux users will get 24/7/365 solid AP mode and monitor mode performance and if we shut this bad AP mode support down and document our recommendation, folks that make a mistake will know it rapidly and can return their purchase before the return window closes.

FWIW: I tried shutting AP down this morning via makefile option and the compile crashed. So much for Realtek doing any testing. It is something that I can fix but would like for both of you to give me your opinion on shutting AP mode down before I pursue it.

Nick

[spcharc]

As you pointed out, even with your hack, if you want one adapter in managed mode and the other in master mode and they need different module parameters, how do we do that?

It seems I failed to make it clear in the previous post.

With my hack (running two instances of drivers with two different names):

• You will have two config files for both of the drivers, so you can use different driver parameters.
• You won't be able to use this hack if both of your adapters have the same vendor_id:product_id pairs. For example, if you have two adapters that show 0bda:b812 in lsusb, then you cannot make them work simultaneously. (At least I haven't figured out how this hack can work in this case)

If the driver supports multiple adapters:

• You won't be able to use two config files, since there is only one instance of this driver running
• Adapters with the same vendor_id:product_id pair will work (At least this is what I believe)

So what is the solution that would best serve the community? Probably to rewrite the entry in the FAQ to not just say it can't be done but to point out this it is not a feature that Realtek supports and also provide recommended solutions for those wanting to run two or more adapters in a single system. Thoughts?

You can do that of course. You may have to point out that two adapters with the same vendor_id:product_id pairs is not supported by this hack.

I also wrote a script that automatically does all the file modifications for the drivers (it does all the renaming and code modification based on what USB adapter you want to use). If you want to have a look at it, I can share it.

Each time your new driver came out I just ran this script to prepare my two drivers and installed them. Though I have to say the code is quite ugly since I did not take much effort in improving readability.

Managed mode seems to work very well.

No. I am not only talking about managed mode. "My AP" here means my 88x2bu AP.

As I said before, my AP has two 88x2bu adapters, one is in client mode and another is in AP mode. Basically it is a WiFi extender. That 360Mbps is the result of a speed test I did through this AP.

The setup looks like:

MyComputer >>> 88x2bu1(AP)---88x2bu2(client) >>> router---AT&T

Since I am using a 300Mbps cable service provided by AT&T, 300+Mbps is not best speed these adapters can run. It is just an upper limit of this AT&T service.

Unfortunately it will be a while before WPA3 works seemlessly like it does with the Mediatek drivers.
Have you been able to check AP mode?

In fact, I only checked AP mode, not client mode. I do not have any WPA3 WiFi around me so I cannot test the client mode.

I made my 88x2bu1 adapter (shown above) to run a WPA3-SAE WiFi AP. It was perfect. The only problem was four of my devices being not able to connect to it since they don't support WPA3, I had to switch back to WPA2

Should we shut AP mode down on this driver and simply advise people to get adapters with one of the following chipsets if the need AP mode?

Then you are just pushing people away from your repo ...

[morrownr]

• You will have two config files for both of the drivers, so you can use different driver parameters.
• You won't be able to use this hack if both of your adapters have the same vendor_id:product_id pairs. For example, if you have two adapters that show 0bda:b812 in lsusb, then you cannot make them work simultaneously. (At least I haven't figured out how this hack can work in this case)

Okay, I think I have a better understanding now.

You can do that of course. You may have to point out that two adapters with the same vendor_id:product_id pairs is not supported by this hack.

We can document that as part of a solution.

I also wrote a script that automatically does all the file modifications for the drivers (it does all the renaming and code modification based on what USB adapter you want to use). If you want to have a look at it, I can share it.

Each time your new driver came out I just ran this script to prepare my two drivers and installed them. Though I have to say the code is quite ugly since I did not take much effort in improving readability.

I understand ugly code as I have some ugly code I am working on so don't worry about that. Please do share so we can see about getting a reasonable solution in place.

As I said before, my AP has two 88x2bu adapters, one is in client mode and another is in AP mode. Basically it is a WiFi extender. That 360Mbps is the result of a speed test I did through this AP.

The setup looks like:

MyComputer >>> 88x2bu1(AP)---88x2bu2(client) >>> router---AT&T

Since I am using a 300Mbps cable service provided by AT&T, 300+Mbps is not best speed these adapters can run. It is just an upper limit of this AT&T service.

My understanding is increasing. Keep in mind that I have several repos here at this site and the site is averaging over 6,000 hits per week so my ability to keep everything straight is limited... but I try. It helps if messages are no longer than they need to be and are self contained so that I don't have search back through threads to figure out the situation again.

In fact, I only checked AP mode, not client mode. I do not have any WPA3 WiFi around me so I cannot test the client mode.

That is fine because that is what is needed (AP mode that is). I have checked managed (client) mode and see no problems but none were expected since the current public driver seems to be problem free in managed mode. WPA3 for managed mode is just something we will have cleared document for now. The heavy lift to get this driver ready for the public is AP mode.

Should we shut AP mode down on this driver and simply advise people to get adapters with one of the following chipsets if the need AP mode?

Then you are just pushing people away from your repo ...

You saw a little frustration coming out there. My site here is taking more of my time that I need it to. I need some partners to run day to day operations on some of these drivers as it is to the point that I can't sustain what I am doing.

Have you read the issue 96 post by eddiegb? This triggered me to remember this is an issue I had previously isolated to USB3 in AP mode. I evidently forgot to document the issue and it is specific to this driver. Can I get both of you to test AP mode with both USB3 and USB2 to confirm the details. I use iperf3 and set it to run ( -t 60 ) for at least 60 seconds and this test will blow things up everytime if USB3 is used. If your tests confirm this is the problem then I can see what it will take to revise the documentation. We may or may not be able to find a coding solution but USB2 can handle a pretty good stream so it is not that big of a deal in my opinion.

Now, why did I forget to document this. Likely because the adapters I normally use, when not testing, are adapters based on the following chipsets:

mt7612u
mt7610u
rtl8812au

The only drawback I can find in AP mode with the mt* drivers is no DFS support. They can do 24/7/365 ultra stable AP mode. In fact, if you run OpenWRT, it has the mt761xu drivers in its repos so you just install the package and stick adapter in an extra usb port and you have another radio going. I use two wifi routers. One is a RasPi4B with two usb adapters and the other is a ZyXEL NBG6817 (wave 2). The ZyXEL runs OpenWRT and I have an ALFA AWUS036ACHM plugged into the USB2 port and it provides a second 5 GHz radio. That Alfa adapter has exceptional range.

Regards

[henkv1]

I can confirm that the connection drops under load when using 5GHz with USB3. This is the same behavior as with the previous driver. When using lower speed connections and USB2, the AP is pretty stable. But the range is limited, especially when 5GHz is used.

[morrownr]

I can confirm that the connection drops under load when using 5GHz with USB3.

Thanks. The evidence is building that a heavy load on 5 GHz with USB3 active causes a drop out. I am going to start a new issue just for this problem so we can collect information.

This is the same behavior as with the previous driver.

Concur. If we can get stable operation with USB2 mode, that should provide stable operations in 5 GHz AP mode and in the longer term we can try to isolate and work on a code fix... if possible. We do not have access to all code due to firmware.

FT-PSK is still not working, 5GHz signal strength is still weak and the 2.4GHz signal is not reliable.

When you have time, can you elaborate on each of these concerns?

[spcharc]

Please do share so we can see about getting a reasonable solution in place

change.zip

Please see this zip file. The change.py is the script that I use to replace all the strings, and change.sh is how I used change.py

I know it can be extremely confusing, so let me explain a little bit. change.py takes exactly 3 arguments.

• A path to an folder containing unmodified 88x2bu driver from your repo
• A suffix. For example, if you provide 1 as the suffix, then driver name 88x2bu will become 88x2bu1
• A string that allows the script to know which adapter you will use with this driver.

For the 3rd argument, I chose only and T4U in change.sh because they are substring of a particular USB identifier line that I want to enable, but not other lines.

only is from

{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDER_ID_REALTEK, 0xB812, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* Default ID for USB Single-function, WiFi only */

You can also choose B812. But 0xff or REALTEK can be a bad idea since the script will terminate, leaving the files unchanged, when it detects multiple lines containing this string.

T4U is from

{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0115, 0xff, 0xff, 0xff), .driver_info = RTL8822B}, /* TP-Link Archer T4U V3 */

For testing purpose, you can also turn on the dry_run flag. The script will only print all the strings it tries to modify.

I think this hack can also be used on your other realtek drivers?

Can I get both of you to test AP mode with both USB3 and USB2 to confirm the details.

No problem. Will post result here after the test

[morrownr]

Can I get both of you to test AP mode with both USB3 and USB2 to confirm the details.

No problem. Will post result here after the test

FYI: I have opened Issue 2 specifically for this 5 GHz AP mode problem so please move to that issue for related reporting.

Also, don't forget that you may need to put some heavy stress on the adapter to get failure. The stress needs to be sustained. I use iperf3 with a time duration of at least 60 seconds (-t 60). I usually see failure between 10 to 30 seconds into the test. Failure only happens here with USB3 active. The better we can document this issue, the better chance we have to find and fix the problem. If we can establish that USB2 works well, then we can document that so people use USB2 and quite frankly, USB2 is fast enough that most folks will not notice the difference.

Cheers

[dmitttri]

Hi everyone,
I can confirm that issue i've filled recently in the main driver repo, under #93 is fixed with this driver.

To cut it short, the problem was with two Cudy AC1300 dongles, attached to two computers under test. One was configured to be the AP, and the other was cofigured just to connect to the AP. With the previous driver code base, AP works, but is entirely invisible for the other computer using the same dongle. Scan results won't return AP's SSID. I have even added traces into the driver to confirm that even the chipset scan operation was not able to detect the problematic AP. However my phone was able to see the AP, and to connect to it

But form your comments, seems AP is still quite bad, with low range and unreliable.

[morrownr]

Hi everyone, I can confirm that issue i've filled recently in the main driver repo, under #93 is fixed with this driver.

This is good. I think we will find additional improvements as well.

But form your comments, seems AP is still quite bad, with low range and unreliable.

I've been testing AP mode this evening and I am seeing very solid, stable performance. No power management related issues. No drop outs or slow downs. This is with USB2. I will test USB3 after a couple of days of testing USB2.

If we do find very stable operation with USB2, then we can document our findings and continue the search for a fix as we have time. AP mode with USB2 is still fast. In fact, for 2.4 Ghz, it keeps things maxed out. For 5 GHz, it can start start cutting into available bandwidth but is fine for most use cases. Anyone needing the full 5 GHz capability probably needs to have an adapter that is more capable anyway or an internal card or another solution so I think we need to explore and see where it takes us.

Nick

[morrownr]

FYI: I have opened issue 3 to address txpower and range related issues.

[dmitttri]

I've been testing AP mode this evening and I am seeing very solid, stable performance. No power management related issues. No drop outs or slow down

Yes, that's true. In my office I have setup of with one AP (5GHz) and 10 stations attached, running multicast video stream with gstreamer. Right now AP is using 8821au chpset (some D-Link) and all stations use 8821cu (Comfast). My hopes were that with the 88x2bu chipset I could leverage MiMo capabilities on Tx side, thus increasing effctive throughput,

Next week I can run tests with 88x2bu as an AP, with both USB=2 and USB=3, to compare the outcome and measure bandwidths. Also I could compare with 8821au operation (which is my default setup)

Hopefully we can get more meanigful conclusions.

[morrownr]

@dmitttri @spcharc @henkv1 @misha4gps @iVolt1 @greg2891

Monday morning, Novermber 01, 2021, Status Update

I have spent most of my available time over the last few days putting the finishing touches on the new 8812au and 8821au drivers.

https://github.com/morrownr/8812au-20210629
https://github.com/morrownr/8821au-20210708

Those drivers are the best overall Realtek drivers I have ever seen. They are really good (but they are not mac80211 or in-kernel so I will temper my enthusiasm.)

I am now really going to try to turn most of my attention to helping get this driver in good shape so as to go public with it within the next month or so. Let's aim for going public by the end of November.

We already know there are some challenges with this driver. 5 GHz AP mode is problematic with USB3 turned on. That is the long pole in the tent so please work it so that we can find out as much as we can.

@misha4gps is planning a PR to add RHEL8 support so we should get to test that as well.

@grep2891 wants to try monitor mode to see what will happen. As it stands right now, I do not intend to turn monitor mode support on for the public release because monitor mode has never worked well on this chipset and there are many other good chipsets where monitor mode does work well... and I don't feel like putting up with it. Quite frankly, adapters built with this chipset are generally cheap and the quality is lacking in many so we see a lot of problems. This adapter is mostly just used for manage mode and this driver does that well, whereas users that need AP mode and monitor mode would be better served with adapters with more appropriate chipsets. With that said, I know I have stepped on some toes. Sorry about that.

With all of that said, let's test and fix things as best we can. Discussion goes in this thread and you can open new issues for new bugs. I appreciate the help and hope we can get a quality driver out the door.

Regards,

Nick

[morrownr]

@dmitttri @spcharc @henkv1 @ajitwarrier all

After taking a look at things this morning and updating the documentation, I decided to go ahead and take this repo public. I think this driver is solid enough to not cause problems and we need more people using it at this point in order to find out if there are additional issues.

Thanks for your help.

Nick