RTL8852AU Support (802.11ax)

[dmitttri]

Hi Nick,
thanks for your magnificent effort with USB-WiFi Linux adapters and drivers. Recently you have published latest drivers for 8821au and 88x2bu chipsets, which were significant improvement over the previous versions, so the whole community effort was moved to newest sources that Realtek kindly provided. In particular, new version solved the issue I have reported some time ago, when Station was not able to find AP in the scan results, if both Station and AP uses the same USB dongle. Thanks to you, I had early acces to the drivers under test, and I could confirm this issue was gone.

I am facing the same issue with the only GitHub available version of 8852AU drivers, at https://github.com/s-2/RTL8852AU_WiFi_linux_v1.15.0.1-0-g487ee886.20210714

Since you don't maintain these chipsets, and I could not find any relevant sources on Realtek support website, I was wondering are Realtek sources available for public access, or I need to be a part of their partner program?

I am asking because I hope there is newer version of RTL8852AU available, pretty much the same as Realtek recently published new versions of 8821au and 88x2bu. And I hope new versions will resolve the issue I am still facing with this chipset.

Thanks in advance for any help.
Dimitrije

[morrownr]

Hi Nick

Hi Dimitrije

thanks for your magnificent effort with USB-WiFi Linux adapters and drivers.

I get a lot of help. Thanks for your help.

Recently you have published latest drivers for 8821au and 88x2bu chipsets

Also for the 8812au

which were significant improvement over the previous versions

Agree

so the whole community effort was moved to newest sources that Realtek kindly provided.

Realtek did not provide the new driver source. We should thank Edimax for that. Realtek does not provide a public source for its USB WiFi drivers, nor does it provide a way to report problems. It is also continues to use the wrong technology (drivers need to be based on mac80211) and it is not working to get the drivers in-kernel.

In particular, new version solved the issue I have reported some time ago, when Station was not able to find AP in the scan results, if both Station and AP uses the same USB dongle. Thanks to you, I had early acces to the drivers under test, and I could confirm this issue was gone.

I am facing the same issue with the only GitHub available version of 8852AU drivers, at https://github.com/s-2/RTL8852AU_WiFi_linux_v1.15.0.1-0-g487ee886.20210714

I was unaware of this repo. I have now taken a look. While this driver code is dated 20210714 which would lead us to think it would be at the level of the 3 previously mentioned drivers, it is not. In fact, it only has kernel patches up though 5.09. It would take a significant amount of work for me to include patches for kernels 5.10, 5.12 and 5.15.

Since you don't maintain these chipsets, and I could not find any relevant sources on Realtek support website, I was wondering are Realtek sources available for public access, or I need to be a part of their partner program?

I have tried to find this information out as well but Realtek does not answer emails and I have got email address from those who should know. It is very hard to talk to Realtek unless you are buying a lot of chips from them.

I am asking because I hope there is newer version of RTL8852AU available

Interestingly enough, there is rtl8852 support in staging. That is, support is being prepared to enter the Linux kernel and that means, of course that the driver is the proper technology and maintenance will be performed in-kernel. That is the good news. The bad news is no USB support has been added so far. Here is a site where an individual took the code from the kernel and patched on USB support:

https://github.com/neojou/rtw89-usb

I do not have have an adapter based on the 8852au or 5532au at this point so if you are inclined to test and report, I'm sure some folks would be interested in the results.

Before you ask, Realtek has two separate teams working on wireless. The team that does USB is the team that is failing to properly support Linux which likely is the reason that we do not see the USB support in the 8852au driver in staging.

Hope this helps.

Nick

[dmitttri]

Thnaks for your kind reply,

Realtek did not provide the new driver source. We should thank Edimax for that. Realtek does not provide a public source for its USB WiFi drivers, nor does it provide a way to report problems. It is also continues to use the wrong technology (drivers need to be based on mac80211) and it is not working to get the drivers in-kernel.

I have expected something like this, thanks for confirming. Indeed, their stuborn approach to stay away form mac80211, and out of kernel in general, causes decent amount of problems for many of Linux users.

I was unaware of this repo. I have now taken a look. While this driver code is dated 20210714 which would lead us to think it would be at the level of the 3 previously mentioned drivers, it is not. In fact, it only has kernel patches up though 5.09. It would take a significant amount of work for me to include patches for kernels 5.10, 5.12 and 5.15.

Unfortunatley yes, it seems this is the latest Realtek up to date version, which haven't seen any of useful improvements like 8821au, 8812au, and 88x2bu brought with the latest release.

I have tried to find this information out as well but Realtek does not answer emails and I have got email address from those who should know. It is very hard to talk to Realtek unless you are buying a lot of chips from them.

I have tried to email to Realtek, with the same misfortunate result: silence. This must be the same approach i once experienced with Davicom. After a month of detailed multidisciplinary investigation with my colleagues, we have concluded they have a silicon bug in one of their devices. Once we reported the problem, and have sent detailed documentation, they were kind enough to ask us which volumes we are planing to buy. We just wrote something like 10k, and we never heard anything more from them. Few years later, new hadrware rev came out, and the issue we have reported was solved.

Interestingly enough, there is rtl8852 support in staging. That is, support is being prepared to enter the Linux kernel and that means, of course that the driver is the proper technology and maintenance will be performed in-kernel. That is the good news. The bad news is no USB support has been added so far. Here is a site where an individual took the code from the kernel and patched on USB support:

https://github.com/neojou/rtw89-usb

Thanks a lot for pointing me out to this repo, this is exactly what I was looking for, proper mac80211 port, for USB dongles. I have 5 of D-Link DWA-X1850 dongles, with 8852au chipset, and would be happy to give it a try, and help him with testing. What I had found previously was kimocoder repository: https://github.com/kimocoder/rtw89-usb, but he states it's not yet in the operational state.

If this repo fails to solve the issue I am currenly facing, the only option I could think of is to analyze diffs for 8821au (for example), since I still have the sources before you moved to 20210708, where the same issue was solved. It may take me some time to nail which exact change affects this issue, but I definitely need to do it, to move on with my 802.11ax tests. Most likely it's some chipset register value change. Anyhow I will report my outcome here too, so anyone else interested in 8852au chipset, can leverage on the result.

Before you ask, Realtek has two separate teams working on wireless. The team that does USB is the team that is failing to properly support Linux which likely is the reason that we do not see the USB support in the 8852au driver in staging.

Now this makes sense, as I have noticed that mainline rtw89 don't have support for USB dongles.

Hope this helps.

Definitelty! Thanks a lot!

[morrownr]

There is an app called meld that could prove useful during your hunt. You can use it to compare all files in 2 different directories. If it were me, I would use the current 8812au code to compare against the 8852au code.

You are looking for a needle in a haystack.

I would join the fun and even get the 8852au where it would compile on recent kernels but I have one problem... I don't have an adapter based on the 8852/32 chipset and I would actually need two in order to fully test and release a driver to the public.

[dmitttri]

There is an app called meld that could prove useful during your hunt.

meld is also my favorite GUI diff tool, being around with my develoment for quite some time

I would use the current 8812au code to compare against the 8852au code.

This also makes sense, the code skeleton for these drivers is pretty much the same. But it will also introduce differences AC vs AX, so this is why I was thinking to start with old vs new 8821au (or 8812au)

You are looking for a needle in a haystack.

But at least I know the haystack is there, which is good for start. Plus I am pretty much sure it's the chipset register configuration, rather than driver code logic. Simply because some time ago, while investigating the same issue with 8821au, I went down to the code, to extract raw scan results form the chipset directly, and my concusion was that it's the chipset (and it's firmware) which cuts off AP with the same dongle, not the driver code. It will be fun ride to find the culprit, but it may take decent amount of time too.

I would join the fun and even get the 8852au where it would compile on recent kernels but I have one problem... I don't have an adapter based on the 8852/32 chipset and I would actually need two in order to fully test and release a driver to the public.

Once I resolve this annoying issue, and since I have couple of dongles with me, I can repeat at least a portion of your standard tests, so you can make the conclusion if it's worthwhile of supporting recent kernels, and releasing it along with other drivers which were proven to work fine.

Since today I will be out of office, I can start tomorrow to address this issue

[morrownr]

Once I resolve this annoying issue, and since I have couple of dongles with me, I can repeat at least a portion of your standard tests, so you can make the conclusion if it's worthwhile of supporting recent kernels, and releasing it along with other drivers which were proven to work fine.

Just to clarify: If you are able to fix this issue and your testing shows that this driver is of adequate quality for the Linux community, I will be glad to do the work to get it compiling on resent kernels and will start a repo for it. I normally do not put repos up unless I have an adapter to test with but, with your help, we can probably make this work.

I have no immediate plans to buy an ax adapter as I would prefer a WiFI 6e adapter instead of a WiFi 6 adapter as channel congestion is the issue I am looking at. I do think we will have a 6e adapter available within the next year and it very well may be one with in-kernel support (think Mediatek, not Realtek.)

Regards

[morrownr]

@dmitttri

Dimitrije,

FYI: I had some extra time this evening. I took the clean source and did some work... all required patches to enable it to work on kernels up to and including kernel 5.15 are now in place. I have added appropriate flags and it is now tested on kernels up to 5.13 and gcc up to v9.3. It is a clean compile. I created a new "private for testing" repo. Do you want access?

For what it is worth: I was wrong in my initial assessment. In many areas of code that I looked at during my work this evening, this code is actually more modern than the 3 recently released drivers. In fact, I ran across 2 features that I was considering adding to the newest 3 drivers but now I can backport the features instead of creating them. Cool.

To anyone else that has an adapter that they think is supported by this 8852au driver, please let me know if you want access to the repo. Access will be for testing and I am not putting a timeline on testing as this is new technology and I do not have an adapter to test with so I will be asking those who do have an adapter to test and report.

Regards,

Nick

[dmitttri]

Hi Nick,

FYI: I had some extra time this evening. I took the clean source and did some work... all required patches to enable it to work on kernels up to and including kernel 5.15 are now in place. I have added appropriate flags and it is now tested on kernels up to 5.13 and gcc up to v9.3. It is a clean compile. I created a new "private for testing" repo. Do you want access?

That's great you've found additional time to support latest kernels. Of course I would like access, right now I am in the process of fixing issue we know it has, with AP and STATION. Unfortunately by the end of last week and during weekend, I had no time to contonue my search, but from now on it will be my priority. Then I will submit pull request.

For what it is worth: I was wrong in my initial assessment. In many areas of code that I looked at during my work this evening, this code is actually more modern than the 3 recently released drivers. In fact, I ran across 2 features that I was considering adding to the newest 3 drivers but now I can backport the features instead of creating them. Cool.

That's also great, so it make sense to keep further driver improvements and maintenance here, within your fork.

To anyone else that has an adapter that they think is supported by this 8852au driver, please let me know if you want access to the repo. Access will be for testing and I am not putting a timeline on testing as this is new technology and I do not have an adapter to test with so I will be asking those who do have an adapter to test and report.

At the moment, my priority is to resove the issue which prevent me any testing. I need AP ansd STATION with the same dongle to "see" each other, and then I will available to do lot of testing with these dongles i have, and report all the conclusion and issues to your fork. This may easily become useful community driver. That's cool.

I will keep you updated, soon as I finish my inestigation

[morrownr]

@dmitttri

Your invitation is one the way. When you check in, please open the first issue to get us started.

The repo currently is in a state where the only code changes I made were what was necessary to allow for kernels up to and including 5.15 to compile. I have made some very minor modes to the Makefile. I will go slow as far as adding supplemental files is concerned. Good luck on your hunt.

Nick

[bjlockie]

This guy put the OEM driver with fixes for recent kernels in his repo:
https://github.com/lwfinger/rtl8852au
I think he is involved with the PCIe in kernel driver.

He is also working on a USB driver that is of suitable code quality to go in the kernel as part of the kernel rtw89 driver.
It crashes the USB stack currently.
https://github.com/lwfinger/rtw89
He has the DLink X1850.

[morrownr]

Update: We have given up on trying to get the 8852au driver in good enough shape to go public. It is simply a terrible driver that has multiple ways to lockup a system. Bad stuff. Stay away from any adapter based on the 8852/32au.

Maybe someday we will see a good driver in-kernel if usb support can be added to rtw89. That may be the best hope.

[bjlockie]

How is the 8852ae (PCIe) driver?

[morrownr]

How is the 8852ae (PCIe) driver?

I don't have any idea but things do NOT make it into the kernel without a lot of quality control taking place.