Got 3 COMFAST adapters, would like to help testing

[fishBone000]

Hi! I currently have 3 COMFAST adapters:

1. CF-953AX
2. CF-952AX
3. CF-924AC

The reason why I have so many is that I want an adapter that runs well under AP mode, but I haven't succeeded for now.
I plan to refund CF-953AX (probably) and CF-952AX soon, but 1 or 2 days ago I saw your repo, so I'd like to help testing before I refund them.
I also have some problems with the tx rate under AP mode. I have submitted #316 regarding it.

[morrownr]

Hi @fishBone000

Be glad to help. Can we do this one adapter at a time so we don't get lost in the details?

Give me an idea of what the details of your project are what problems you are seeing?

Nick

[fishBone000]

I want to make my other devices able to connect to my laptop, so that I can do various things like watch movie streams, download files from laptop and external disks.
The problems I see are described in #316 and another issue I'm about to submit tomorrow (kind of late at the time of writing).

316 is about to be closed soon though, because I have already found where the problem is.

So eh...the remaining purpose of this issue is to provide data about those 3 adapters, since I have 3 COMFAST adapters right now, and it seems you want more feedback on adapters.
( Alright I just found that I didn't make my intention clear in my issue detail...What I want is actually provide data feedback instead of doing tests to solve my problems, though I indeed would like to do so. )
So is there any test you want to make, e.g. BT functionality, benchmark regarding CF-924AC?

[morrownr]

it seems you want more feedback on adapters.

I have a Comfast CF-951AX adapter. It uses the mt7921au chipset and I am well aware of the capabilities of the mt7921au chipset. Your CF-952AX and CF-952AX adapters should also use the mt7921au chipset. I am not familiar with the Comfast CF-924AC adapter. Do you know what chipset it contains?

Also, would you mind running the following on all 3 adapters so that I can ensure I am aware of the details?

$ lsusb

The reason why I have so many is that I want an adapter that runs well under AP mode,

Understand. I have a lot of experience with USB WiFi adapters and AP mode so maybe I can help.

Right now my CF-951AX is pulling AP mode duty on a RasPi4B using the example hostapd.conf that I have up for WiFi 6 for testing.

[fishBone000]

I have asked the custom support which chipset CF-924AC contains, waiting for reply.

$ lsusb: CF-924AC:

Bus 003 Device 003: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]

CF-953AX:

Bus 002 Device 004: ID 0e8d:7961 MediaTek Inc. Wireless_Device

CF-952AX:

Bus 002 Device 005: ID 3574:6211 MediaTek Inc. Wireless_Device

[fishBone000]

The other issue I mentioned earlier is here: #317

[morrownr]

I would appreciate it you would close #317 as this is all related and I'd prefer not to go back and forth.

For now let's get the CF-924AC going.

Bus 003 Device 003: ID 0bda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200 Techkey]

This adapter appears to be based on the rtl8812bu chipset but we need to check if it is the rtl8822bu chipset (the one with bluetooth). Does the ad say this this adapter supports bluetooth? The Obda:b812 ID usually indicates this is a WiFi only chipset.

Do you realize that the rtl8812bu and mt7921au chipset use very different hostapd.conf settings? Also, This rtl8812bu chipset is not capable of WiFi 6. What driver are you using for the rtl8812bu chipset?

[fishBone000]

I got reply from the customer support who says it's RTL8812, and in the ad I can also see it's RTL8812BU.
I also confirm that the BT is not available, nor was it mentioned in the ad.

About the driver, I use the in-tree one, but I forgot its name, will go check later.
And about the hostapd conf file, I do realize CF-924AC is a WiFi5 adapter, so I brought it up to AP by disabling AX and several capability as hostapd reports CF-924AC doesn't support them. I will go through more tests later (my laptop is currently not at hand).

Also I forgot to mention that the COMFAST online store where I bought the adapters (not including CF-953AX, bought it elsewhere) stopped selling CF-924AC days ago. It was around 8USD.

[fishBone000]

Info from lsmod:

rtw88_8822bu           12288  0
rtw88_usb              28672  1 rtw88_8822bu
rtw88_8822b           229376  1 rtw88_8822bu
rtw88_core            327680  2 rtw88_usb,rtw88_8822b

I also ran more testing on the CF-924AC. I edited the hostapd-WiFi6.conf by disabling AX, [GF] and [TX-STBC] (because 924AC doesn't support them), and AP runs well, transfer rate goes up to ~220Mb/s.

[morrownr]

It appears that this confirms that the 924AC has a rtl8812bu chipset, not the rtl8812au chipset. This very well could cause future problems. You might want to send this 924AC back if you still can get your money back. I like the rtl8812bu chipset but not in a messed up situation like this. Alfa makes a very nice like adapter based on the rtl8812bu that is low cost but high quality. You can find it listed in the Plug and Play List here on the Main Menu.

While you sort this out, would you like to press on with the 953 in AP mode project?

[fishBone000]

I can't refund CF-924AC because I bought it months ago, back then I hadn't come up with the ideas of making my laptop an AP.

I also figured out the crashing problem (#317 ), it was because of the inteference from NetworkManager.
However I noticed that those 3 adapters are causing inteference to each other.
That is, when I set one up in AP it runs well, tried several rounds of iperf3 and got good results. However when I set the other one up in managed mode, the AP one will complain about Failed to set beacon parameter, resulting devices disconnection.

[morrownr]

I would not blame this on the adapters. It sounds like you are basically making a repeater. That can be a challenge from a network configuration standpoint. You'll have to research it. Setting up eth > wifi AP is easy. Setting up wifi > wifi AP is not easy.

[morrownr]

If the old laptop is simply be used to learn networking and wifi, have you consider using OpenWRT? It would make several things easier and you would like learn much more plug OpenWRT 22.05 and later have a driver for the 953. The driver works for the 952 as well but I'm not sure if the driver has been updated for the company specific vid/pid yet but that can be handled. OpenWRT has a lot of apps you can install so your laptop can do a lot of more than just be an AP.

[fishBone000]

Why is that so? I figure it shouldn't be a problem for the kernel as the machine running it is a laptop, so stress on kernel shouldn't be a prob. I also dont think it should be a prob for adapters because...they are operating on different channels. So how does wifi > wifi become a challenge? By the way it's not a repeater: I simply carry my laptop around, so ether > wifi is usually not an option to me. wifi > wifi also brings a benefit when the wifi connection to public WiFi on my laptop is more stable than on my devices. It's also benefitial because I have proxy settings on my laptop, while porting such setting to devices is, actually difficult due to various reasons.

Anyways I will go research it, hope I can find an answer.
So lets proceed to CF-953AX, shall we?

[fishBone000]

As for OpenWRT, my old laptop is my only laptop ;-; It's my daily use. I will go try it when I'm spared though, like on weekends.

[morrownr]

So how does wifi > wifi become a challenge?

Because networking is designed to discourage that use as it can cause routing and other conflicts. There is a history. This is something you will have to research.

By the way it's not a repeater...

If your incoming is via wifi and your AP is via wifi, it is essentially a repeater.

So lets proceed to CF-953AX, shall we?

We shall. Your CF-953AX is using a standard Mediatek vid-pid which has been in the in-kernel driver since kernel 5.18. You need AP mode and that was added with kernel 5.19 so you should be good to go as long as your kernel is at least kernel 5.19. You now know that you have to shut down NM or at least disable it from working on the wifi interface you plan to use as an AP.

There is a menu item on the Main Menu about adding or updating in this case the mt7921au firmware files you may want to make sure your distro has the latest firmware files.

After that, it is mostly a matter of setting up the networking configuration and hostapd.

Nick

[fishBone000]

I did more tests, and I found out that only CF-952AX and CF-953AX will interfere with each other.
Setting them up both in AP or in managed mode is fine (didn't do much stress test though), but setting one of them in AP and the other in managed mode will make the AP one complain Failed to set beacon parameters.

So if I set CF-924AC in managed, and CF-953AX or CF-952AX in AP, I can use my laptop as a router.
I tested this setup by doing speed test, watching videos on my pad for around 15mins, got no problem.
Makes me kind of wonder, if it is a driver bug, as CF-952AX and CF-953AX uses the same chipset and driver?

About the firmware, I didn't upgrade it since I have successfully set my laptop up, plus ethtool -i wlanX shows the firmware version is ____010000-20230526130958 which looks good enough.

[fishBone000]

And...I will have to send one of CF-952AX and CF-953AX back for refund around 4 days later (refund ddl).
I plan to keep CF-952AX, which seems to be faster as AP, plus it looks cooler: it has some reflective pattern on its casing :p
Just in case, am I making the right choice or should I keep 953AX instead?

[morrownr]

am I making the right choice or should I keep 953AX instead?

I have seen generally good reports on both the 953AX and 952AX. The 953 you have a has a Mediatek standard vip/pid so it is plug and play all the way back to lernel 5.18. The 952 you have has a company specific vip/pid that only made it into the kernel with v6.3 I think it was so really, as long as you keep that in mind, you should be fine with either. If the 952 looks cool and seems to have better range then with it. Would you mind passing the link you used to buy the 952AX? Should I add the 952AX to the Plug and Play list based on your experience?

[fishBone000]

Bought it from the official store on JD, an online market in China, so you might need to be able to read Chinese lol . They seem to ship products internationally though, so there is chance you can purchase one.

It is plug and play, my kernel recognizes it and is added as wlan interface after a few seconds of delay.

In addition, about the inteference btw 952 and 953, do you think it might be a bug of the firmware? If it might be I'd like to contact the mail list and help them test it, I can also cancel the refund if necessary. Ofc I will update firmware before that.

Is there any else data I can gather for you?

[morrownr]

so you might need to be able to read Chinese lol

I took a look. I'm fluent in two languages and can get by with a couple of more but Chinese is not one of them. I'll do a search to see if I can find another source. The only reason I have not included the 952AX is the lack of a good solid source as those who have the adapter seem to like it.

do you think it might be a bug of the firmware?

I don't think so. I checked your firmware and it appears to be the latest. These new WiFi 6 and 6e chipsets have drivers and firmware that is really complicated. We have seen like 6 firmware updates in the last year. You are aware that your 953 and 952 are capable of 6 Ghz with Linux? They don't advertise it but it is there.

The AP mode bug that was reported here was reported by @whitslack who is also the poster of issue #309 . He is also the one who developed and submitted the patch that just went into kernel 6.6 so you might ask him if he thinks his patch covers your issue.

Is there any else data I can gather for you?

Keep me posted if you figure something out. I will test two adapters with mt7921au chipsets in AP mode to see what I can see. I do most of my AP mode work on RasPi4B setups and a new version of the RasPiOS is due any day now so I will likely wait until the new version is released. RasPiOS also makes it fairly easy to update to new kernels if you don't mind compiling. I have a guide up on the Main Menu.

[fishBone000]

Roger. Will go ask @whitslack tomorrow.
I also read #309, pretty lucky that MediaTek made such a nice chipset, and COMFAST is selling adapters with this chipset in a low price but also good quality.

Will keep posting if there's sth interesting coming up.

[whitslack]

I don't see anything here, in 316, or in 317 that relates to the kernel crash when using the mt7921au in a bridge with an Ethernet interface. When that crash happens, the machine locks up hard, as the kernel itself essentially triggers a segmentation fault, and there's no lower layer to handle the fault, so the only thing the machine can do is to stop cold.

[morrownr]

@whitslack

Didn't remember exactly what your issue was and didn't have time to find the post. I can see @fishBone000 's issue being a driver issue. It appears the new RasPiOS is out so I'll see about burning a sd and then see what happens with 2 mt7921au adapters in AP mode. If I find a bug, you get to fix it.

Nick

[whitslack]

There's been some churn in the driver code recently to turn global variables into instance variables, so I would suggest building the very latest kernel (HEAD from Git if possible) and see if maybe the work has already been done to make multiple instances of the driver play nice with each other when in different configurations.

That said, there is no guarantee that this chipset and driver can be used to implement a repeater. As you correctly pointed out, 802.11 is not really designed to support multiple MAC addresses hanging off of one managed-mode client association. If you want to use a Wi-Fi link to bridge two Ethernet segments, you really should be using a point-to-point mode, not infrastructure mode.

[morrownr]

There's been some churn in the driver code recently to turn global variables into instance variables, so I would suggest building the very latest kernel (HEAD from Git if possible) and see if maybe the work has already been done to make multiple instances of the driver play nice with each other when in different configurations.

Yes, I intend to pull the latest and thanks for your expertise. I see this as an experiment to see what will happen. I am not a network expert but an familiar with "802.11 is not really designed to support multiple MAC addresses hanging off of one managed-mode client association." My understanding that the design was intentional so as to prevent routing issues so I hope I have made the point to @fishBone000 that what he is doing is challenging.

[fishBone000]

Thanks for the replies, @whitslack ! I will go try build a kernel and test it out. I faced some difficulties though, like ran out of space when using config from my running kernel, or it just won’t boot if I edit the default config directly. It’s actually my first time building a custom kernel.

Anyways I will keep trying tomorrow, will keep you two updated.

[fishBone000]

I successfully build the latest kernel (commit 4016448) today, by changing conf from my running kernel and cleaning up more disk space.
Still failed to set up the repeater: same old error msg.
I also tried to update the firmware according to the tutorial from the Main Menu, however it causes pagefault if I plug in my CF-952AX or CF-953AX. This problem happens on the latest kernel and my original one (6.5.5-arch1-1).

[fishBone000]

I did more tests today, found something: it's more like a regulatory conflict problem than driver problem.

TL; DR

If an adapter is set up in AP mode with regulatory set to US, and another adapter is connected to a WLAN (not the AP one that just got set up) with regulatory set to CN, the adatper in AP mode has chance to get confused, thus fails to set beacon parameter.
I didn't know the regulatory setting is system-wide, the command iw <phy name> reg get gave me an illusion that the reg setting is adapter independent...until I read the kernel document about regulatory setting today.

Full Story

When I was running test under the built-by-myself kernel again to make sure the kernel wasn't tainted as required by the kernel issue reporting guide, I found that the error message didn't show up as usual.
I soon recalled that I modified the hostapd conf file by changing the country_code from US to CN (where I live, to avoid regulatory violation) last night.
I also recalled that I had had a minor issue that I didn't give much attention to it: when one of my adapter is connected to public wlan (reg CN), if I try to start another adapter up in AP with reg set to US and chan set to 36(42), there's a high chance that hostapd will fail to set it up and complains about channel not found for current mode or channel not allowed (RADAR). Because of this, usually I set my AP up before connecting to public WiFi.

So...not after long I imagined that the error Failed to set beacon parameters we were tracking down is probably caused by reg conflict: the reg of the AP is set to US at start, but after I connect to public WiFi the reg of my system will be set to CN, thus causing confuse to my AP.

I also confirmed that this error also happens when AP is set on CF-952AX while managed mode is set on CF-924AC. Ehh...I know I said this error wouldn't happen on 952 and 924, but now I can only say I probably didn't run enough tests. The error is not immediate, it takes some time (usually ~1 min) to happen, plus I observed that sometimes reg of my system is not set to CN even after I connect to public WiFi.

Looking back, now I guess iw <phy name> reg get is actually for getting regulatory setting from adapters that have regulatory solution of their own? If it's correct, it also explains why there's no iw <phy name> reg set <ISO/IEC 3166-1 alpha2>.

Everything seems fine after I set the reg of my AP to CN, no more Failed to set beacon parameters, repeater runs well, tried to watch a few vids on my pad (connected to AP) with no issue.

[whitslack]

@fishBone000: Great sleuthing work! It comes as a shock to me that the regulatory domain is a global parameter and not a per-interface parameter. It makes sense for the regulatory database to be global, but I'd expect each wireless interface to have its own regulatory domain setting pointing into that database. Of course, ordinarily (if every AP were advertising its regulatory domain correctly), we wouldn't expect different interfaces on the same system to be in different regulatory domains at the same time, but APs lie. Imagine connecting as a client to two different APs simultaneously, where the APs specify differing regulatory domains. Which domain will the client system end up using globally? That of the AP to which it last connected? That's fragile and surprising. It doesn't sound like this was thought through very well.

[fishBone000]

Great sleuthing work!

Thanks!

Actually kernel documentation has some pages about regulatory setting:

1. https://wireless.wiki.kernel.org/en/developers/regulatory
2. https://wireless.wiki.kernel.org/en/developers/regulatory/statement

I actually expected each adapter to have their own independent regulatory setting too. Especially that if regulatory setting works in this way, I can "violate" the regulatory a bit by setting my AP to a different domain, thus gain some extra frequency and bandwidth, hehe >:) I remember some time ago I set the region setting on my router (a regular purchased one) to AU for some extra tx power, now I know how that actually works.

Which domain will the client system end up using globally?

I guess the domain setting only affects AP set up on the system? Perhaps even if we have 2 adapters connected to 2 APs with 2 different reg domain setting, the adapters will just connect to them without complaints. Thus the responsibility lie on APs.
Just my guesses though! I do have a purchased router, I will see if I can tweak its reg domain setting, and connect to it and public WiFi and see how things work.

[whitslack]

I guess the domain setting only affects AP set up on the system? Perhaps even if we have 2 adapters connected to 2 APs with 2 different reg domain setting, the adapters will just connect to them without complaints.

Yes, the adapters will connect to the APs with different regulatory domains without complaining, but then only one domain will apply to both adapters. Regulatory domain governs transmit power, so connecting to a lying AP could conceivably cause a pre-existing connection to an honest AP to begin exceeding the regulatory power limit.

[fishBone000]

I noticed that CF-924AC is not recognized as USB 3.0 device, while CF-952AX, CF-953AX and my external disk enclosure are recognized as USB 3.0.
I think it's hardware/driver issue, as I saw some posts on the web complaining about Realtek adapters.
Just in case, any ideas? Whether it's running on USB 3.0 doesn't matter pretty much for me though.

[morrownr]

I saw some posts on the web complaining about Realtek adapters.

I had to chuckle a little when I read this. Realtek's usb wifi drivers were never made for consumers using desktop and server distros. It would seem the Realtek drivers were made for embedded device use by skilled programmers but the drivers are just trouble. However that should come to an end at some point as code has been added to the Linux kernel to prevent non-standards compliant wifi drivers from working with wifi 7 and work continues toward the goal of removing the old Wireless Extentions support. This is a good thing but it also means Linux users are wise if they seek alternatives to usb wifi adapters that use Realtek chipsets... if they want their adapters to have good support for many years.

Just in case, any ideas?

What driver are you using?

[fishBone000]

I had to chuckle a little… Hehehe

What driver are you using? You asked the same question days ago, scroll up a few pages and you will see (rtw88).

[morrownr]

You asked the same question days ago, scroll up a few pages and you will see (rtw88)

Hold on here just a minute. This site gets about 18,000 hits per week and I try to help as much as I can but it all runs together sometimes.

I just tried a 8812bu based adapter with 88rtw and got usb2 here. No idea why that is.

[fishBone000]

This site gets about 18,000 hits per week and I try to help as much as I can but it all runs together sometimes.

Understand. It’s good that your site is helping many people! I remember some time ago finding an adapter for Linux was kind of pain in the ass ‘cause most adapters are for Windows.

No idea why that is. It’s RealTek’s problem then.

[fishBone000]

I have been running into weird AP problem these days. After I set up CF-952AX in AP mode, and run iperf3 tests on my pad, I can see error messages in journalctl:

Oct 21 14:47:22 pootos kernel: mt7921u 4-3:1.0: tx urb failed: -71
Oct 21 14:47:22 pootos kernel: mt7921u 4-3:1.0: tx urb failed: -71
Oct 21 14:47:22 pootos kernel: mt7921u 4-3:1.0: tx urb failed: -71
Oct 21 14:47:22 pootos kernel: mt7921u 4-3:1.0: tx urb failed: -71
...repeats for many times...

Acute speed drop can be observed, from being fast as ~600Mbps for 3 secs to being slow as 17Mbps in average for 10 secs.
Managed mode doesn't seem to be affected.

My kernel even got tainted after I unplug it.
This is weird, the only related stuff I can think out is that I updated my kernel to 6.5.7 (upgraded by pacman, not self-built) days ago. I will run more tests tomorrow, and see if downgrading to 6.5.5 helps.

Any thoughts?

[bjlockie]

Are you using an extension cable?

Maybe try a powered hub.

[fishBone000]

No I’m not, the adapter is connected directly to my USB port.
And I don't think it’s relevant, because days ago I could set up WiFi6 AP with no problem. At that time the adapter is directly connected too.

[whitslack]

I experience unpredictable mt7921u driver crashes due to mismanagement of USB URBs too. The driver has bugs. Hopefully someday someone with a strong background in the Linux USB subsystem will give the mt7921u driver code a thorough audit and will fix all the inconsistencies so we can have a rock solid driver. 🤞

[fishBone000]

Big discovery! First, allow me to yell: LOL! Because what I found is really unexpected! Read on.

At first I thought it’s a driver problem, I compiled kernel 6.5.8 and 6.5.5, and found the issue happens on both kernel. Alright that’s weird, 'cause last time I set up the AP with CF-952AX on 6.5.5 just fine. I also checked the firmware, but the instslled firmware isn’t changed since then.
Any how I decided to send bug report to kernel mailing list, but when I run more tests to fill out the info, I found:
The issue only happens when the antennas are folded!
LOL

Yes, it only happens on USB 3 (which I already know) and when the 2 external antennas are not extended, I guess the blazing fast transmission somehow caused interference with the internal circuit, causing malfunction.
I ran more iperf3 tests. During the process, I gently folded the antennas bit by bit, when they are almost fully folded: Bang! Buncha error messages. When I replug, reset hostapd e.t.c. , unfold antennas, run iperf3: everything is fine again.

Hehehheehehhheheheheh

I also reported this to COMFAST support, hope this helps.

[morrownr]

@fishBone000

At first I thought it’s a driver problem,

I'd estimate 75% of the problems reported in the Realtek repos here over the last few years have been problems with something besides the drivers.

However, like @whitslack said, the driver has bugs. We just need to work toward some good solid bug reports and hopefully we can get this driver very solid. I am seeing regular fixes and additional capability being added so work in ongoing.

With that said, this is a pretty darn solid driver for most uses. It seems that AP mode is most in need of work and since not everyone uses AP mode, it is up to us that do use it to get those bug reports in order.

[kasinjsh]

Big discovery! First, allow me to yell: LOL! Because what I found is really unexpected! Read on. At first I thought it’s a driver problem, I compiled kernel 6.5.8 and 6.5.5, and found the issue happens on both kernel. Alright that’s weird, 'cause last time I set up the AP with CF-952AX on 6.5.5 just fine. I also checked the firmware, but the instslled firmware isn’t changed since then. Any how I decided to send bug report to kernel mailing list, but when I run more tests to fill out the info, I found: The issue only happens when the antennas are folded! LOL Yes, it only happens on USB 3 (which I already know) and when the 2 external antennas are not extended, I guess the blazing fast transmission somehow caused interference with the internal circuit, causing malfunction. I ran more iperf3 tests. During the process, I gently folded the antennas bit by bit, when they are almost fully folded: Bang! Buncha error messages. When I replug, reset hostapd e.t.c. , unfold antennas, run iperf3: everything is fine again. Hehehheehehhheheheheh I also reported this to COMFAST support, hope this helps.

Make sure its not usb related interference. I got Fenvi version of this Mediatek chip usb wifi card and when I plug in my SBC (OrangePi Zero3, usb2.0 port) and move stick a bit I got usb errors and disconnections, so if you have try whit a usb extension cable, preferably short one, 30cm should be fine.

[fishBone000]

I tried to keep the adapter firm when testing the antennas, so I think I didn’t disconnect it by accident.
And…I’m not using any cable, plus I heard that some adapters don’t work well with cables.

[morrownr]

I heard that some adapters don’t work well with cables.

This is a very true statement. My Comfast CF-951AX will not work with a cable. I have several cables and it will not work with any. It will work with the right angle usb adapters but not cables. It won't even work with a powered hub.

[manuelpaulo]

It appears that this confirms that the 924AC has a rtl8812bu chipset, not the rtl8812au chipset. This very well could cause future problems. You might want to send this 924AC back if you still can get your money back. I like the rtl8812bu chipset but not in a messed up situation like this. Alfa makes a very nice like adapter based on the rtl8812bu that is low cost but high quality. You can find it listed in the Plug and Play List here on the Main Menu.

While you sort this out, would you like to press on with the 953 in AP mode project?

Driver is already done and widely used. Why not on kerned yet?

https://github.com/aircrack-ng/rtl8812au

[bjlockie]

Driver is already done and widely used. Why not on kerned yet?

The driver is a hack?

https://forum.openwrt.org/t/rtl8822bu-and-rtl8821cu-usb-drivers/135659/10

Realtek sucks?

[morrownr]

Driver is already done and widely used. Why not on kerned yet?

If I am understanding this statement correctly, you are asking why the driver you posted is not in the Linux kernel.

I can answer this. It is because Realtek out-of-kernel drivers are not Linux Wireless Standards compliant and will not be allowed to be in the kernel.

Realtek sucks?

I can make some good arguments that this is the case when it comes to Linux usb wireless support.

[manuelpaulo]

Driver is already done and widely used. Why not on kerned yet?

If I am understanding this statement correctly, you are asking why the driver you posted is not in the Linux kernel.

I can answer this. It is because Realtek out-of-kernel drivers are not Linux Wireless Standards compliant and will not be allowed to be in the kernel.

Realtek sucks?

I can make some good arguments that this is the case when it comes to Linux usb wireless support.

Thanks, that's what I imagined... but there's hope? rtl8812bu has been recently added. Is it that different from rtl8812au?

2024-01-13 - added generic Realtek rtl8812bu adapter (AC1200) to rtl8812bu chipset section.

https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel_drivers.md

[morrownr]

but there's hope?

For the rtl8812au chipset, probably not much hope. It is the first generation AC1200 chipset while the rtl9912bu is the second generation. The 2nd generation WiFi 5 chipsets are mostly being supported in the in-kernel driver called RTW88 which Realtek made and maintains in the kernel. RTW88 is standards compliant. The usb support was provided by a community member. USB support in RTW88 is not perfect yet but fixes are slowly coming in. It would be better if Realtek took over responsibility for the usb support in RTW88. Right now, the only chipset in RTW88 that I am showing in the Plug and Play list is the 8812bu as I have seen good enough results in managed mode tests that is should work for most people AP mode is not where it should be yet, I wouldn't buy it for monitor mode as the adapters based on the mt7610u, mt7612u and mt7921au are much better.

8812au is not covered in RTW88 and being the older chipset, it is unlikely that we ever see an in-kernel driver. I have warnings about chipsets in this situation in various places around this site.

@morrownr