News: USB WiFi Adapters based on the mt7921au chipset (WiFi 6e) are now available...

[morrownr]

Updated: 2023-02-26

July 2022
Comfast CF-953AX - chipset: mt7921au (single-state) (BT 5.2)
http://en.comfast.com.cn/index.php?m=content&c=index&a=show&catid=13&id=182

July 2022
Comfast CF- 951AX - chipset: mt7921au (single-state) (BT 5.2)
http://en.comfast.com.cn/index.php?m=content&c=index&a=show&catid=13&id=209

October 2022
Netgear A8000 AX3000 USB Adapter - chipset: mt7921au
https://dongknows.com/netgear-a8000-ax3000-usb-adapter-is-here/

February 2023
ALFA AWUS036AXML
https://www.alfa.com.tw/products/awus036axml?variant=39754360684616

EDIT: 2022-07-22 - Important info: The above adapters use the mt7921u driver. The mt7921 base driver has been in the Linux kernel since 5.12 so internal cards have been working well for some time with the exception of AP mode. The above are usb adapters and usb support was not added to the mt7921 driver until kernel 5.18. Most of the more popular distros provide instructions for upgrading kernels. I can provide instructions for Ubuntu based distros on request. AP mode support was added in kernel 5.19. It requires a firmware upgrade, see Main Menu 8.

EDIT: 2022-07-22 - We now have reports from @foen73 and @yaslama about the CF-953AX. Both report that it is a single-state adapter. That is very encouraging.

EDIT: 2022-08-03 - FYI: I see from an ad that the chipset is called mt7921au. This is the first time I have seen that specific name. It appears the mt7921au chipset has the same capabilities as the mt7921k that we have known about for some time.

EDIT: 2022-07-22 - Disclaimer: While we do have limited positive reports at this point, there could be issues that have not been discovered yet.

Regards,

Nick

[haevalencia]

I confirm that these adapters are multi-state.

EDIT: 2022-08-03 - @haevalencia It is looking like the person providing the information was not well informed. Multiple users that have one of the adapters in hand have reported that the adapters are single state.

Some stores on AliExpress are already preparing devices with this new MediaTek chip like Edup Official Store which will released it soon. The Anddear Store, which makes the current unbranded adapter with the MT7612U chip, said that if there was interest from users, it would work on a new model with the MT7921au chip. So go show your interest wink wink.

[amisix]

Thanks for contacting ANDDEAR. Be wary - they are in my opinion currently selling non-functional mt7612u adapters. My hope would be they don't repeat the same mistake(s) with their mt7621au adapters.

[bcdonadio]

I bought two units of the Comfast CF-953AX dongle with this mt7921au chipset from AliExpress, supposedly to be delivered until August 06. Let's see if they work at all when (and if) they arrive.

Using your really useful, but obviously lacking in features, 8814au module in a TP-Link Archer T9UH has been not so comfortable. Looks like even range is severely reduced when comparing with my (impressively good, featureful and stable on Fedora 35 with kernel 5.18.6, but not really up to date with the standards) onboard Qualcomm Atheros QCA6174 using the ath10k_pci module.

Will report back when I get my hands on them. I will be following this thread, but if someone gets those adapters first, could you test and mention me here? Thanks.

[morrownr]

The vendor confirmed to me that they have received "suggestions from users" to sell adapters with a MediaTek chip including a CD with drivers, just as they do with Realtek chips.

Hopefully we can spread the word to Linux users to be careful what they ask for. We should be asking for single-state adapters and if the maker wants to include a small, cheap flash drive for the Windows and MAC drivers, that would be great. The reason I word it this way is because out-of-kernel drivers, such as those that Realtek makes, do not work well because of the development model of Linux. Unlike Windows or the MAC OS, Linux does not lock apis for long periods. Linux is under constant development so the only way to keep device drivers up to date and working is for them to be located in the mainstream kernel. Linux users do not want Linux drivers on a CD...it will not work. Period.

The 5 out-of-kernel Realtek drivers that I and other maintain here make for a lot of work and we do it with no help from Realtek. Realtek is doing things wrong. Linux device drivers need to be developed in-kernel and they need to meet the applicable standards. In the case of the Realtek out-of-kernel drivers, the driver are not in-kernel and they do not meet published stanards. Thank goodness for Mediatek. They are doing it right.

Some stores on AliExpress are already preparing devices with this new MediaTek chip like Edup Official Store which will released it soon. The Anddear Store, which makes the current unbranded adapter with the MT7612U chip, said that if there was interest from users, it would work on a new model with the MT7921au chip. So go show your interest wink wink.

I will be showing my interest by talking directly to makers and resellers. Come on ALFA!

[morrownr]

Thanks for contacting ANDDEAR. Be wary - they are in my opinion currently selling non-functional mt7612u adapters. My hope would be they don't repeat the same mistake(s) with their mt7621au adapters.

@haevalencia

@amisix speaks words of wisdom. The unbranded mt7612u adapter in the Anddear store is to be avoided. I did have it in the list of recommended adapters for a short period but a serious bug was found. We researched and tested the issue and can only conclude that there is an engineering error somewhere in that adapter. Try to use it in USB3 port 1 and see what happens. The unbranded mt7610u adapter works well and is still listed.

Regards

[morrownr]

Hi @bcdonadio

I bought two units of the Comfast CF-953AX dongle with this mt7921au chipset from AliExpress, supposedly to be delivered until August 06. Let's see if they work at all when (and if) they arrive.

We are waiting on your review. Cool.

Using your really useful, but obviously lacking in features, 8814au module in a TP-Link Archer T9UH has been not so comfortable. Looks like even range is severely reduced when comparing with my (impressively good, featureful and stable on Fedora 35 with kernel 5.18.6, but not really up to date with the standards) onboard Qualcomm Atheros QCA6174 using the ath10k_pci module.

I wish the 8814au driver was better because a lot of Linux users have adapters based on that chipset. At one point last year, a post doctoral student contacted me as he was doing research on beamforming. He was doing a deep dive on the beamforming support in 8814au and he reported that things are not good in 8814au. It is hard to work on the Realtek drivers and we get zero help from Realtek so it is a minor miracle that we have that driver as stable as it is. I really think Linux users that want to work on code should concentrate on the in-kernel Mediatek MT76 and MT7601u drivers.

Will report back when I get my hands on them.

Did I mention that we are waiting? He he.

[bcdonadio]

@morrownr drop a link here to an AliExpress, Amazon wish list or even a Paypal account so I can send this adapter (or another one you may want) your way. It's only fair with all this awesome work you've been doing for the community. My hardware would be an expensive brick without your effort. I would have sent you something already trough Github Sponsors if it weren't a pain to setup. You can send the link to my email too if you prefer.

Thanks for all your effort and be safe!

[haevalencia]

Thanks for contacting ANDDEAR. Be wary - they are in my opinion currently selling non-functional mt7612u adapters. My hope would be they don't repeat the same mistake(s) with their mt7621au adapters.

@haevalencia

@amisix speaks words of wisdom. The unbranded mt7612u adapter in the Anddear store is to be avoided. I did have it in the list of recommended adapters for a short period but a serious bug was found. We researched and tested the issue and can only conclude that there is an engineering error somewhere in that adapter. Try to use it in USB3 port 1 and see what happens. The unbranded mt7610u adapter works well and is still listed.

Regards

Oh. What is the bug? I have been using it on several laptops and even my ThinkPad T495 which has a 3.x and 3.1 gen 2 (10Gbps) USB-A ports and no visible issues.

[morrownr]

Use $ lsusb -t to move the adapter around until it is in a USB3 port 1.

Not a port 2 or port 3 or port 4.

@amisix and I have not been able to get it to get it to work or at least work well in a port 1. If it does work and you put iperf3 on a run of 300 seconds or more it will slow down and eventually stop. Sometimes it will show the same symptoms on port 2. This has happened on a variety of hardware. I have some test results around here somewhere. I'm currently in major maintenance mode so I'll need to to local the file.

[amisix]

It doesn't initialize/work in certain USB3 ports, issue was originally identified on a Raspberry Pi 4B then replicated on several other x86 platforms. USB3 Port 1 "Top" USB port fails, USB3 Port 2 "Bottom" USB Port functions. It will initialize in a USB2 port intermittently but ultimately fail while running iperf3 as referenced by @morrownr.

Original Thread:
#75 (comment)

Discussion with WLAN-PI team regarding this issue (replicated on their Pi setup and x86 hardware).
WLAN-Pi/feedback#21 (reply in thread)

[morrownr]

@morrownr drop a link here to an AliExpress, Amazon wish list or even a Paypal account so I can send this adapter (or another one you may want) your way. It's only fair with all this awesome work you've been doing for the community. My hardware would be an expensive brick without your effort. I would have sent you something already trough Github Sponsors if it weren't a pain to setup. You can send the link to my email too if you prefer.

Thanks for all your effort and be safe!

@bcdonadio

I appreciate the kind words and offer. I might set something up someday but for now let's just say that I am paying forward what others did to help me over the years.

Nick

[croissantpetrichor]

Thank goodness for Mediatek. They are doing it right.

Partly, I mean sure their hardware has good specs and they have great drivers but how much is that really worth when you can't even acquire their products. Let's be honest either they don't care or they've got a little Nvidia market manipulation "chipset shortage" thing going on.

Sure to some extend there is a chipset shortage but RealTek among others seem to be having no issues pushing out there products. Nothing generates profits like a global conflict, am I right?

I will be showing my interest by talking directly to makers and resellers. Come on ALFA!

When's the last time those guys manufactured anything new and interesting? Couple of years ago, yeah, they don't care...

Easier and cheaper to push propaganda and fake articles instead of you know, actually designing a new product.

XXXX all the corporate zombies enabling all this bullshit, but that's the conspiracy man.

Not sure if this one's been spotted yet but here you are, Gigabyte PCIe MT7921K (MT7921K (RZ608)) 40$.

[morrownr]

Sure to some extend there is a chipset shortage but RealTek among others seem to be having no issues pushing out there products. Nothing generates profits like a global conflict, am I right?

@croissantpetrichor

I am all for having a good discussion about economics as it has to do with USB WiFi in some way. Your message is taking the original topic off course so I am requesting that you start a new topic in the Discussion section and I am requesting that you refrain from using foul language is I would like to keep this site G rated.

Would I enjoy a discussion about economics and business practices around the world? Certainly. I don't give much information about my background usually but I will here so that you know: I have undergraduate and graduate degrees in Economics. I have taught economics at the university level. I learned programming using FORTRAN on an IBM mainframe. That should give you an idea of my age. I have little tolerance for conspiracy theories. I do my best to make sure the information on this site is useful and factual.

I understand a great deal about how businesses work and what factors are at work in the world economy. In the world of IT related products, some companies own their own fabs. Some do not. Fab plants are extremely expensive. Whether a company owns their own fab can have a great deal of influence on how they are able to conduct business.

I look forward to you starting a new discussion.

Regards,

Nick

[croissantpetrichor]

I am all for having a good discussion about economics as it has to do with USB WiFi in some way.

Doesn't everything have to do something with something?

Your message is taking the original topic off course

You're right and GitHub isn't exactly the appropriate platform for this.

so I am requesting that you start a new topic in the Discussion section

Do you really want to discuss economics on GitHub? I mean ultimately we can beat around the bush all we want. The new MediaTek chipsets are currently just not available. Blame it on economics, blame it on Admin Smith it doesn't matter, there's nothing we can do in order to change that.

I am requesting that you refrain from using foul language is I would like to keep this site G rated.

I think it's important to note that I normally don't swear at all, more on this later.

Would I enjoy a discussion about economics and business practices around the world? I don't give much information about my background usually but I will here so that you know: I have undergraduate and graduate degrees in Economics.

Given your mention about having studied economics I doubt we'd come to agreement about how things work.

I have taught economics at the university level. I learned programming using FORTRAN on an IBM mainframe. That should give you an idea of my age.

That's a good thing, I personally think the best programmers are born due to their understanding of "low level" languages because grasping them really helps you understand on a deeper level how a computer works.

I have little tolerance for conspiracy theories. I do my best to make sure the information on this site is useful and factual.

I probably should've worded that differently, it's not necessarily a conspiracy theory if there's some truth in it an well I think we all can establish that all markets in the world are in one way or another manipulated.

I don't mean to come across as someone who believes in crazy conspiracy theories and is actively spreading them, that's not at all the case. More so it was a moment of weakness, desperation, because I've been actively searching for new hardware for about a month now and I lost my patience.

I also should probably note, and not as a reason to excuse my actions but I struggle from severe health issues which sometimes cause me to act irrationally.

I understand a great deal about how businesses work and what factors are at work in the world economy. In the world of IT related products, some companies own their own fabs. Some do not. Fab plants are extremely expensive. Whether a company owns their own fab can have a great deal of influence on how they are able to conduct business.

Both RealTek and MediaTek are fabless according to Wikipedia. Undoubtedly these factories are incredibly expensive, but the profit some of these companies turn over, or are able to turn over must make such a expense worth it don't you think?

[bcdonadio]

This one seems pretty humble. I think I want it.
https://www.mediatek.com/products/broadband-wifi/mediatek-filogic-880

Also, I'm gonna have to agree with @morrownr about Mediatek support on Linux. Look at the sheer amount of work on these chipsets that we have coming in to the mainline tree, with a good chunk of those patches authored by Mediatek employees.

[morrownr]

This one seems pretty humble. I think I want it. https://www.mediatek.com/products/broadband-wifi/mediatek-filogic-880

Also, I'm gonna have to agree with @morrownr about Mediatek support on Linux. Look at the sheer amount of work on these chipsets that we have coming in to the mainline tree, with a good chunk of those patches authored by Mediatek employees.

I monitor linux-wireless so I see the flow on a daily basis:

http://vger.kernel.org/vger-lists.html#linux-wireless

While it is easy to pick out employees of a company since their email address will be something like @mediatek.com or @intel.com, what may not be obvious unless you monitor the list is that individuals such as Lorenzo Bianconi and Felix Fietkau are likely under contract to Mediatek as they do a LOT of work that they could not do unless they were under the direction of Mediatek and were supported by Mediatek with information that would be needed. Both individuals also appear to have contracts with the Foundation as they work on wireless parts that are maintained by the Foundation.

My opinion is that Mediatek is all in. When is the last time you can remember a USB WiFi adapter driver being in the mainline kernel BEFORE the hardware is available to buy? I'm pretty sure the answer is never. I certainly can't this happening. I will not surprise me to see Mediatek grab a lot of market share from several of their competitors over the next few years.

[croissantpetrichor]

My opinion is that Mediatek is all in.

All in is a bold move. I must say however, you're optimism and continual updates are very uplifting and help me remain hope.

When is the last time you can remember a USB WiFi adapter driver being in the mainline kernel BEFORE the hardware is available to buy? I'm pretty sure the answer is never. I certainly can't this happening.

You're very much so right.

While it is easy to pick out employees of a company since their email address will be something like @mediatek.com or @intel.com, what may not be obvious unless you monitor the list is that individuals such as Lorenzo Bianconi and Felix Fietkau are likely under contract to Mediatek as they do a LOT of work that they could not do unless they were under the direction of Mediatek and were supported by Mediatek with information that would be needed. Both individuals also appear to have contracts with the Foundation as they work on wireless parts that are maintained by the Foundation.

That's great, I think this is them @nbd168 and @LorenzoBianconi. Both of them seem to have a lot of experience and primarily devote their attention to wireless communication, they've both developed drivers and worked on OpenWRT.

Felix seems a bit more high profile and has a bigger social media presence, he's even got a speech about open source WiFi drivers, ironically I think I've come across this video on hackaday or a similar site in the past already.

I hope MediaTek can continue supporting developers as such, and considering they made 4 766 832.82 USD this year in Q1 already I doubt it'll be much of an issue for them, financially speaking anyway.

If this deems true however I fully agree with you, I think MediaTek will absolutely dominate the Linux market.

I doubt they're allowed to say anything but maybe these gentlemen can tell us a little more about what the future holds?

[bcdonadio]

Hmm, let's try to take a more "companies are made to be profitable" approach.

USB WiFi devices today are a niche market. Everything is supposed to connect "to the internets" via WiFi or cellular. There's virtually no device today you can buy that does not have adapters for one, the other, or both. Unless you're in a tech conference or something of the sorts, you don't see anyone with a WiFi USB dongle on their notebooks, desktops, home routers, not even mentioning phones. That's where the money is: embedded into all those devices, not dangling out.

Since a real big market share of these kind of devices - namely Android phones, home routers and Chromebooks - run Linux, having drivers for them is a no-brainer. Mainlining that support as GPL was refrained a lot in the past because of licensed intellectual property from third-parties and fears of competitors copying their ideas.

This is changing now because of two main reasons: the most persuasive of those is that a lot of the "real workhorse logic" is being moved to the firmware that you have to load as blobs you have no idea what's in. The second argument is that finally companies are realizing that the open source development model is cheaper than the alternatives in many more scenarios than previously thought, specially if you're targeting a market with a really diverse hardware landscape. Phones and home routers have completely different compromises to be made (power utilization, size, throughput...) and therefore have big different architectural decisions. It really costs less to simply develop a good FOSS interface that gets into mainline (reducing their efforts to maintain the code up to date with ABI changes) than keeping a variety of closed code bases that need to be kept in sync with the mainline and as diverse as customers need.

Having all that, USB support is just a little bit more effort. Of course it's not free, but costs orders of magnitude less than the closed model I defined above. It probably makes sense financially to develop that support even versus the small amount of USB adapters sold. Mediatek is going that route, specially because WiFi-enabled SoCs are their main source of income.

Other companies, specially the really big ones, are slugs. Hard to change course and have lots of money to spend inefficiently yet still turn a profit, specially since WiFi-enabled SoCs isn't their main milk cow. Broadcom's main profits come from the enterprise switches/routers/NICs. Qualcomm has all their cellular base-station hardware and dedicated cellular ASICs. Realtek is... old and apparently not really sure what they want to focus on.

To mention the cliché tech punch-bag, they're the IBMs. Some may be able to overcome this inefficiency, like Microsoft did, others will perish soon, and a few will linger on supporting themselves by income from other market segments. Personally I think Realtek is in a death march already. Let's see for how long they keep existing until they're acquired or file for bankruptcy. Realtek made 8 billion TWD in profits last year, while Mediatek made 493 billion TWD.

Here's Realtek's financials for this first quarter of 2022:

And here is Mediatek's:

Quite a difference in revenue and net profit margins, isn't?

My 2 cents, at least.

[yaslama]

I suspect both of the above adapters are multi-state being that they are from ComFast. See Main Menu 7 for more information.

I ordered and received both devices (CF-951AX & CF-953AX) and they are not multi-state! The box contains a small cdrom with the drivers for Windows.
Alas, the mt7921 module is not enabled in the debian kernel (5.18.0-2-amd64). I opened a bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015808 for the kernel package. I had to recompile the kernel with the module enabled and I also had to upgrade the firmware files from the linux-firmware git repository, but the device works now.

[morrownr]

Hi @yaslama

Thanks for the information. We would appreciate a performance report from you as you are able. Something like the reviews for certain adapters in the following document:

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

I ordered and received both devices (CF-951AX & CF-953AX) and they are not multi-state!

This is great news. Just to be sure, can I get you to disable usb_modeswitch?

Look at the last section at the below link:

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

If they fire up and work with usb_modeswitch deactivated, then we have confirmation that they are single-state.

Difference:
CF-955AX 1800Mbps RTL8832AU with PA 23dbi Antenna support Win 10/11
CF-959AX 1800Mbps RTL8832AU with PA 43dbi Antenna support Win 10/11
CF-957AX 1800Mbps RTL8832AU with PA 22dbi Antenna support Win 10/11
CF-951AX 1800Mbps MT7921AU Built in 23dbi Antenna support Win 10/11
CF-953AX 1800Mbps MT7921AU 2*3dbi Antenna support Win /10/11

I was doing a little research the other day and ran across the above. When it did not mention with PA I thought to myself, could they be single state?

I realize that I am going to need to include instructions for users since adapters based on the mt7921au are going to require some assistance for now:

• need to have at least kernel 5.18 and the mt7921u module has to have been set to compile by the distro maintainers.

Probably should give instructions for at least one popular distro.

• need to have updated firmware installed. Some distros, like Debian, unless you use an unofficial iso, don't include the firmware anyway. I have instructions and could sure use some folks to test the instructions:

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

• for AP mode support, need kernel 5.19 and the most recent firm

Regards

[yaslama]

Thanks for the information. We would appreciate a performance report from you as you are able. Something like the reviews for certain adapters in the following document:

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

I ran iperf3 with an Turris Omia (not upgraded to wifi 6) and a Mini PC (Asus PN51) having also an internal ax200 card at a distance of 50 cm from the Omnia:

• CF-951AX

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   606 MBytes   508 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   605 MBytes   508 Mbits/sec                  receiver

• CF-953AX

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   659 MBytes   553 Mbits/sec    0             sender
[  5]   0.00-10.09  sec   656 MBytes   545 Mbits/sec                  receiver

• AX200

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   498 MBytes   418 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   496 MBytes   416 Mbits/sec                  receiver

-- Wired using an ethernet cable

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.08 GBytes   932 Mbits/sec  220             sender
[  5]   0.00-10.00  sec  1.08 GBytes   930 Mbits/sec                  receiver

This is great news. Just to be sure, can I get you to disable usb_modeswitch?

I made sure that no usb-modeswitch is installed in my test system

# dpkg -l '*modeswitch*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  usb-modeswitch <none>       <none>       (no description available)

# lsusb -t -v
...
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 5000M
        ID 0e8d:7961 MediaTek Inc.
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 5000M
        ID 0e8d:7961 MediaTek Inc.
    |__ Port 1: Dev 2, If 2, Class=Wireless, Driver=, 5000M
        ID 0e8d:7961 MediaTek Inc.
    |__ Port 1: Dev 2, If 3, Class=Vendor Specific Class, Driver=mt7921u, 5000M
        ID 0e8d:7961 MediaTek Inc.
...

Some distros, like Debian, unless you use an unofficial iso, don't include the firmware anyway. I have instructions and could sure use some folks to test the instructions:

I think that your instructions are OK. I copied the same 3 files to /lib/firmware/mediatek/
In debian, the firmware is in the package: firmware-misc-nonfree but it's old and there is a bug to upgrade the firmware files (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015728)

[morrownr]

@yaslama

I made sure that no usb-modeswitch is installed in my test system.

Thanks for checking again. I am also seeing the same from @foen73 in discussion #88 so I am convinced the CF-953AX is indeed a single state adapter and giving the performance reports so far I think I will add it to the in-kernel list soon.

@foen73 sent along the iw list for the CF-953AX. See below. Interestingly enough, it shows Band 4 and the 6 GHz channels.

phy7
	wiphy index: 7
	max # scan SSIDs: 4
	max scan IEs length: 482 bytes
	max # sched scan SSIDs: 10
	max # match sets: 16
	Retry short limit: 7
	Retry long limit: 4
	Coverage class: 0 (up to 0m)
	Device supports AP-side u-APSD.
	Device supports T-DLS.
	Supported Ciphers:
		* WEP40 (00-0f-ac:1)
		* WEP104 (00-0f-ac:5)
		* TKIP (00-0f-ac:2)
		* CCMP-128 (00-0f-ac:4)
		* CCMP-256 (00-0f-ac:10)
		* GCMP-128 (00-0f-ac:8)
		* GCMP-256 (00-0f-ac:9)
		* CMAC (00-0f-ac:6)
		* CMAC-256 (00-0f-ac:13)
		* GMAC-128 (00-0f-ac:11)
		* GMAC-256 (00-0f-ac:12)
	Available Antennas: TX 0x3 RX 0x3
	Configured Antennas: TX 0x3 RX 0x3
	Supported interface modes:
		 * managed
		 * monitor
	Band 1:
		Capabilities: 0x9ff
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 7935 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-15
		HE Iftypes: managed
			HE MAC Capabilities (0x08011a000040):
				+HTC HE Supported
				Trigger Frame MAC Padding Duration: 2
				OM Control
				Maximum A-MPDU Length Exponent: 3
				A-MSDU in A-MPDU
			HE PHY Capabilities: (0x2270ce120dc0b306423f00):
				HE40/2.4GHz
				242 tone RUs/2.4GHz
				Device Class: 1
				LDPC Coding in Payload
				HE SU PPDU with 1x HE-LTF and 0.8us GI
				NDP with 4x HE-LTF and 3.2us GI
				STBC Tx <= 80MHz
				STBC Rx <= 80MHz
				Full Bandwidth UL MU-MIMO
				Partial Bandwidth UL MU-MIMO
				DCM Max Constellation: 2
				DCM Max Constellation Rx: 2
				SU Beamformee
				Beamformee STS <= 80Mhz: 3
				Ng = 16 SU Feedback
				Ng = 16 MU Feedback
				Codebook Size SU Feedback
				Codebook Size MU Feedback
				Triggered CQI Feedback
				Partial Bandwidth Extended Range
				PPE Threshold Present
				Power Boost Factor ar
				HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
				20MHz in 40MHz HE PPDU 2.4GHz
				DCM Max BW: 1
				Longer Than 16HE SIG-B OFDM Symbols
				Non-Triggered CQI Feedback
				TX 1024-QAM
				RX 1024-QAM
				RX Full BW SU Using HE MU PPDU with Compression SIGB
				RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
			HE RX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			PPE Threshold 0x39 0x1c 0xc7 0x71 0x1c 0x07 
		Bitrates (non-HT):
			* 1.0 Mbps (short preamble supported)
			* 2.0 Mbps (short preamble supported)
			* 5.5 Mbps (short preamble supported)
			* 11.0 Mbps (short preamble supported)
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 2412 MHz [1] (20.0 dBm)
			* 2417 MHz [2] (20.0 dBm)
			* 2422 MHz [3] (20.0 dBm)
			* 2427 MHz [4] (20.0 dBm)
			* 2432 MHz [5] (20.0 dBm)
			* 2437 MHz [6] (20.0 dBm)
			* 2442 MHz [7] (20.0 dBm)
			* 2447 MHz [8] (20.0 dBm)
			* 2452 MHz [9] (20.0 dBm)
			* 2457 MHz [10] (20.0 dBm)
			* 2462 MHz [11] (20.0 dBm)
			* 2467 MHz [12] (20.0 dBm)
			* 2472 MHz [13] (20.0 dBm)
			* 2484 MHz [14] (disabled)
	Band 2:
		Capabilities: 0x9ff
			RX LDPC
			HT20/HT40
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 7935 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-15
		VHT Capabilities (0x339071b1):
			Max MPDU length: 7991
			Supported Channel Width: neither 160 nor 80+80
			RX LDPC
			short GI (80 MHz)
			TX STBC
			SU Beamformee
			MU Beamformee
			RX antenna pattern consistency
			TX antenna pattern consistency
		VHT RX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT RX highest supported: 0 Mbps
		VHT TX MCS set:
			1 streams: MCS 0-9
			2 streams: MCS 0-9
			3 streams: not supported
			4 streams: not supported
			5 streams: not supported
			6 streams: not supported
			7 streams: not supported
			8 streams: not supported
		VHT TX highest supported: 0 Mbps
		HE Iftypes: managed
			HE MAC Capabilities (0x08011a000040):
				+HTC HE Supported
				Trigger Frame MAC Padding Duration: 2
				OM Control
				Maximum A-MPDU Length Exponent: 3
				A-MSDU in A-MPDU
			HE PHY Capabilities: (0x4470ce120dc0b306423f00):
				HE40/HE80/5GHz
				242 tone RUs/5GHz
				Device Class: 1
				LDPC Coding in Payload
				HE SU PPDU with 1x HE-LTF and 0.8us GI
				NDP with 4x HE-LTF and 3.2us GI
				STBC Tx <= 80MHz
				STBC Rx <= 80MHz
				Full Bandwidth UL MU-MIMO
				Partial Bandwidth UL MU-MIMO
				DCM Max Constellation: 2
				DCM Max Constellation Rx: 2
				SU Beamformee
				Beamformee STS <= 80Mhz: 3
				Ng = 16 SU Feedback
				Ng = 16 MU Feedback
				Codebook Size SU Feedback
				Codebook Size MU Feedback
				Triggered CQI Feedback
				Partial Bandwidth Extended Range
				PPE Threshold Present
				Power Boost Factor ar
				HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
				20MHz in 40MHz HE PPDU 2.4GHz
				DCM Max BW: 1
				Longer Than 16HE SIG-B OFDM Symbols
				Non-Triggered CQI Feedback
				TX 1024-QAM
				RX 1024-QAM
				RX Full BW SU Using HE MU PPDU with Compression SIGB
				RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
			HE RX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			PPE Threshold 0x39 0x1c 0xc7 0x71 0x1c 0x07 
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5180 MHz [36] (23.0 dBm)
			* 5200 MHz [40] (23.0 dBm)
			* 5220 MHz [44] (23.0 dBm)
			* 5240 MHz [48] (23.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (radar detection)
			* 5280 MHz [56] (20.0 dBm) (radar detection)
			* 5300 MHz [60] (20.0 dBm) (radar detection)
			* 5320 MHz [64] (20.0 dBm) (radar detection)
			* 5500 MHz [100] (26.0 dBm) (radar detection)
			* 5520 MHz [104] (26.0 dBm) (radar detection)
			* 5540 MHz [108] (26.0 dBm) (radar detection)
			* 5560 MHz [112] (26.0 dBm) (radar detection)
			* 5580 MHz [116] (26.0 dBm) (radar detection)
			* 5600 MHz [120] (26.0 dBm) (radar detection)
			* 5620 MHz [124] (26.0 dBm) (radar detection)
			* 5640 MHz [128] (26.0 dBm) (radar detection)
			* 5660 MHz [132] (26.0 dBm) (radar detection)
			* 5680 MHz [136] (26.0 dBm) (radar detection)
			* 5700 MHz [140] (26.0 dBm) (radar detection)
			* 5720 MHz [144] (13.0 dBm) (radar detection)
			* 5745 MHz [149] (13.0 dBm)
			* 5765 MHz [153] (13.0 dBm)
			* 5785 MHz [157] (13.0 dBm)
			* 5805 MHz [161] (13.0 dBm)
			* 5825 MHz [165] (13.0 dBm)
			* 5845 MHz [169] (13.0 dBm)
			* 5865 MHz [173] (13.0 dBm)
	Band 4:
		HE Iftypes: managed
			HE MAC Capabilities (0x08011a000040):
				+HTC HE Supported
				Trigger Frame MAC Padding Duration: 2
				OM Control
				Maximum A-MPDU Length Exponent: 3
				A-MSDU in A-MPDU
			HE PHY Capabilities: (0x4470ce120dc0b306423f00):
				HE40/HE80/5GHz
				242 tone RUs/5GHz
				Device Class: 1
				LDPC Coding in Payload
				HE SU PPDU with 1x HE-LTF and 0.8us GI
				NDP with 4x HE-LTF and 3.2us GI
				STBC Tx <= 80MHz
				STBC Rx <= 80MHz
				Full Bandwidth UL MU-MIMO
				Partial Bandwidth UL MU-MIMO
				DCM Max Constellation: 2
				DCM Max Constellation Rx: 2
				SU Beamformee
				Beamformee STS <= 80Mhz: 3
				Ng = 16 SU Feedback
				Ng = 16 MU Feedback
				Codebook Size SU Feedback
				Codebook Size MU Feedback
				Triggered CQI Feedback
				Partial Bandwidth Extended Range
				PPE Threshold Present
				Power Boost Factor ar
				HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
				20MHz in 40MHz HE PPDU 2.4GHz
				DCM Max BW: 1
				Longer Than 16HE SIG-B OFDM Symbols
				Non-Triggered CQI Feedback
				TX 1024-QAM
				RX 1024-QAM
				RX Full BW SU Using HE MU PPDU with Compression SIGB
				RX Full BW SU Using HE MU PPDU with Non-Compression SIGB
			HE RX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			HE TX MCS and NSS set <= 80 MHz
				1 streams: MCS 0-11
				2 streams: MCS 0-11
				3 streams: not supported
				4 streams: not supported
				5 streams: not supported
				6 streams: not supported
				7 streams: not supported
				8 streams: not supported
			PPE Threshold 0x39 0x1c 0xc7 0x71 0x1c 0x07 
		Bitrates (non-HT):
			* 6.0 Mbps
			* 9.0 Mbps
			* 12.0 Mbps
			* 18.0 Mbps
			* 24.0 Mbps
			* 36.0 Mbps
			* 48.0 Mbps
			* 54.0 Mbps
		Frequencies:
			* 5955 MHz [1] (23.0 dBm)
			* 5975 MHz [5] (23.0 dBm)
			* 5995 MHz [9] (23.0 dBm)
			* 6015 MHz [13] (23.0 dBm)
			* 6035 MHz [17] (23.0 dBm)
			* 6055 MHz [21] (23.0 dBm)
			* 6075 MHz [25] (23.0 dBm)
			* 6095 MHz [29] (23.0 dBm)
			* 6115 MHz [33] (23.0 dBm)
			* 6135 MHz [37] (23.0 dBm)
			* 6155 MHz [41] (23.0 dBm)
			* 6175 MHz [45] (23.0 dBm)
			* 6195 MHz [49] (23.0 dBm)
			* 6215 MHz [53] (23.0 dBm)
			* 6235 MHz [57] (23.0 dBm)
			* 6255 MHz [61] (23.0 dBm)
			* 6275 MHz [65] (23.0 dBm)
			* 6295 MHz [69] (23.0 dBm)
			* 6315 MHz [73] (23.0 dBm)
			* 6335 MHz [77] (23.0 dBm)
			* 6355 MHz [81] (23.0 dBm)
			* 6375 MHz [85] (23.0 dBm)
			* 6395 MHz [89] (23.0 dBm)
			* 6415 MHz [93] (23.0 dBm)
			* 6435 MHz [97] (disabled)
			* 6455 MHz [101] (disabled)
			* 6475 MHz [105] (disabled)
			* 6495 MHz [109] (disabled)
			* 6515 MHz [113] (disabled)
			* 6535 MHz [117] (disabled)
			* 6555 MHz [121] (disabled)
			* 6575 MHz [125] (disabled)
			* 6595 MHz [129] (disabled)
			* 6615 MHz [133] (disabled)
			* 6635 MHz [137] (disabled)
			* 6655 MHz [141] (disabled)
			* 6675 MHz [145] (disabled)
			* 6695 MHz [149] (disabled)
			* 6715 MHz [153] (disabled)
			* 6735 MHz [157] (disabled)
			* 6755 MHz [161] (disabled)
			* 6775 MHz [165] (disabled)
			* 6795 MHz [169] (disabled)
			* 6815 MHz [173] (disabled)
			* 6835 MHz [177] (disabled)
			* 6855 MHz [181] (disabled)
			* 6875 MHz [185] (disabled)
			* 6895 MHz [189] (disabled)
			* 6915 MHz [193] (disabled)
			* 6935 MHz [197] (disabled)
			* 6955 MHz [201] (disabled)
			* 6975 MHz [205] (disabled)
			* 6995 MHz [209] (disabled)
			* 7015 MHz [213] (disabled)
			* 7035 MHz [217] (disabled)
			* 7055 MHz [221] (disabled)
			* 7075 MHz [225] (disabled)
			* 7095 MHz [229] (disabled)
			* 7115 MHz [233] (disabled)
	Supported commands:
		 * new_interface
		 * set_interface
		 * new_key
		 * start_ap
		 * new_station
		 * new_mpath
		 * set_mesh_config
		 * set_bss
		 * authenticate
		 * associate
		 * deauthenticate
		 * disassociate
		 * join_ibss
		 * join_mesh
		 * remain_on_channel
		 * set_tx_bitrate_mask
		 * frame
		 * frame_wait_cancel
		 * set_wiphy_netns
		 * set_channel
		 * tdls_mgmt
		 * tdls_oper
		 * start_sched_scan
		 * probe_client
		 * set_noack_map
		 * register_beacons
		 * start_p2p_device
		 * set_mcast_rate
		 * connect
		 * disconnect
		 * channel_switch
		 * set_qos_map
		 * set_multicast_to_unicast
		 * set_sar_specs
	WoWLAN support:
		 * wake up on disconnect
		 * wake up on magic packet
		 * wake up on pattern match, up to 1 patterns of 1-128 bytes,
		   maximum packet offset 0 bytes
		 * can do GTK rekeying
		 * wake up on network detection, up to 10 match sets
	software interface modes (can always be added):
		 * monitor
	valid interface combinations:
		 * #{ managed } <= 4,
		   total <= 4, #channels <= 1, STA/AP BI must match
	HT Capability overrides:
		 * MCS: ff ff ff ff ff ff ff ff ff ff
		 * maximum A-MSDU length
		 * supported channel width
		 * short GI for 40 MHz
		 * max A-MPDU length exponent
		 * min MPDU start spacing
	Device supports TX status socket option.
	Device supports HT-IBSS.
	Device supports SAE with AUTHENTICATE command
	Device supports scan flush.
	Device supports per-vif TX power setting
	Driver supports full state transitions for AP/GO clients
	Driver supports a userspace MPM
	Device supports active monitor (which will ACK incoming frames)
	Device supports configuring vdev MAC-addr on create.
	Device supports randomizing MAC-addr in scans.
	Device supports randomizing MAC-addr in sched scans.
	max # scan plans: 1
	max scan plan interval: 65535
	max scan plan iterations: 0
	Supported TX frame types:
		 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
		 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
	Supported RX frame types:
		 * IBSS: 0x40 0xb0 0xc0 0xd0
		 * managed: 0x40 0xb0 0xd0
		 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * mesh point: 0xb0 0xc0 0xd0
		 * P2P-client: 0x40 0xd0
		 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
		 * P2P-device: 0x40 0xd0
	Supported extended features:
		* [ RRM ]: RRM
		* [ SET_SCAN_DWELL ]: scan dwell setting
		* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
		* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
		* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
		* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
		* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
		* [ AQL ]: Airtime Queue Limits (AQL)
		* [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
		* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
		* [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support

[morrownr]

I'm curious as to why the 6 GHz channels are shown?

[objelf]

I'm curious as to why the 6 GHz channels are shown?

Based on the press release https://corp.mediatek.com/news-events/press-releases/mediatek-and-samsung-introduce-worlds-first-wi-fi-6e-enabled-8k-tv, It said: MT7921AU supports Wi-Fi 6E and Bluetooth 5.2 from a single, highly integrated platform. ... Wi-Fi 6E is designed to make use of uncongested bandwidth in the 6GHz spectrum .... so should it be reasonable to see 6GHz to be supported in the device?

[morrownr]

Hi @objelf

I am aware of that press release. I found it yesterday when trying to get to the bottom of this 6 GHz issue. Is the MT7921AU chipset that is used in the new CF-953AX the same as the chipset used in the Samsung TV? That is not clear to me.

If we select Product Information at the COMFAST CF-953AX site, I see specs for dual band capability:

http://en.comfast.com.cn/index.php?m=content&c=index&a=show&catid=13&id=182

I would love it if the CF-953AX really is a tri-band adapter. That is what we want.

Regards

[yaslama]

I'm curious as to why the 6 GHz channels are shown?

@morrownr It seems that indeed CF-953AX (and CF-951AX) supports 6 GHz channels ans is a tri-band adapter even if Comfast is not advertising it. I tried to run hostapd (from git because the debian version is too old) with a configuration using channel 93 from Band 4 with the CF-953AX and tried to connect to this AP with the CF-951AX in another PC and the connection didn't work (I need to work more on that), but I saw that data was exchanged in the 6415 MHz frequency.

[morrownr]

I saw that data was exchanged in the 6415 MHz frequency.

Oh wow!

I have not set up hostapd with 6 GHz due to the lack of a usb wifi adapter that supports 6 GHz. Reading the hostapd.conf docs is probably needed. Would you like for me to read the docs and make suggestions to your hostapd.conf?

[pstlr78]

2. . I have had problems with my CF-951AX works with extension cables but I have heard from some who own a CF-953AX that they have had no such problem.

FYI, the manual of COMFAST CF-951AX mentions: "Note: When using a desktop computer, it is recommended to use a USB extension cord base to connect to the port on the back of the computer case (some desktop ports have an insufficient power supply or cannot be used), and extend it to the Desktop computer USB ports."

I observed this in my case; using the Comfast extension cable CF-U316 I could not get the wifi adapter working using the front-panel USBs. It was working though either on its own plugged on the front-panel USBs or using the extension cable plugged on the back ports of the M/B.

@bcdonadio , on another note, the Windows driver package for this device includes both wifi_mt7961u_patch_mcu_1_2_hdr.bin and wifi_ram_code_mt7961u_1.bin, which are the linux firmware files. I was wondering if I would be successful and the adapter would work fine with the latest firmware if I just replaced such files with the latest ones (e.g. dated 20.01.2023) and re-installed the existing (older) windows driver. Or are the latest linux firmware files tied with the specific respective driver/.inf/.sys files ?

[bcdonadio]

@pstlr78 I believe you can edit the .sys file or whatever and point to the new filename, or replace the content with the old name. Regardless, you will almost sure run into driver signature issues (the file hash won't be accepted).

You can disable the Driver Signature Enforcement, which is OK for a test system, but you probably won't want that in your production system. Simply too much of a target for malware. Anyway, it's your choice.

In order to disable DSE you have to disable Secure Boot as well, which also entails in disabling the Core Isolation protection (Windows 11 now run in a transparent Hyper-V VM with this feature enabled, and offers a good amount of protection against kernel vulnerabilities, since you would need to exploit both the guest kernel and the Hyper-V hypervisor, the later having a much smaller vulnerability surface exactly because it is a hypervisor and not a fully-fledged OS).

So, almost a Windows 98 in terms of security. :)

Maybe run a minimalistic Linux distro with Hyper-V, perform a USB passthrough, and point your default route towards that VM?

[bcdonadio]

Regarding the power issues: I had to increase the voltage a little bit on my front ports, or use a powered USB hub to get it working on my desktop without reaching for the back ports. On my small NUC the front ports worked well with standard settings.

[bcdonadio]

Ah, the new firmware might come packaged in the Update Tuesday (second Tuesday of the month), which is when Microsoft releases batches of patches, fixes and also driver updates as well. You might need to wait just until Feb 14 (guesswork though).

[morrownr]

Ah, the new firmware might come packaged in the Update Tuesday (second Tuesday of the month), which is when Microsoft releases batches of patches, fixes and also driver updates as well. You might need to wait just until Feb 14 (guesswork though).

I'll admit that I know little about Windows as I followed this path on small computers: CP/M, PC-DOS, DR-DOS, OS/2 and Linux. But... it almost sounds like you expect Microsoft to ship updated Linux firmware files.

I was wondering if I would be successful and the adapter would work fine with the latest firmware if I just replaced such files with the latest ones (e.g. dated 20.01.2023)

Yes, you can always upgrade firmware files to the latest in Linux. The Main Menu here has a menu item that gives the locations and filenames for the firmware that most regular users would use.

Or are the latest linux firmware files tied with the specific respective driver/.inf/.sys files ?

Okay. Windows drivers and Linux drivers have nothing to do with each other. As far as I know, Windows doesn't have the equivalent of the Linux firmware files because the entire Windows driver is already a binary blob. Linux uses 2 part drivers (for the in-kernel drivers) so that as much as possible can be open source and included in the kernel which also allows companies to maintain some company secrets in firmware (binary blob that we can't read). Firmware is not part of the kernel. It is part of the distro and each distro has to have one or more people that keep the firmware in the distro up to date. Often it boils down to us out here in userland to file bugs or otherwise contact the person that maintains the firmware. Firmware generally does not get updated too often. The mt7921 firmware has been seeing new firmware drops every one to two month for some time now but I think that mostly has to do with adding new capability and not so much with fixing bugs. The new Wifi 6/6e drivers are big and incredibly complicated.

[bcdonadio]

I'll admit that I know little about Windows as I followed this path on small computers: CP/M, PC-DOS, DR-DOS, OS/2 and Linux. But... it almost sounds like you expect Microsoft to ship updated Linux firmware files.

Maybe I misunderstood, but I thought that you were talking about the firmware blobs that run on the adapter's SoC itself. I couldn't think of a reason an engineer would choose to have different firmwares for different OSes.

Seems like completely unnecessary pain since you need to support more than one system anyway. And don't forget the cost saving of not having to put an extra NAND chip that will be read just once per initialization, while you can get away with just a tiny NOR chip (that you already need anyway because you can't access instruction per instruction with NAND for the very beginning of the initialization process and big NOR chips are hellish expensive).

The part that differ is the driver (as in the kernel module) which of course are completely different. The blobs are usually the same, you can copy from one system to another. The OS is oblivious to what is in there, it just knows that it needs to transfer that thingy during the device initialization.

Curiously, even this was not entiiiiirely true a little bit more than a decade ago (god, I'm getting old). There was a complete lack of Linux drivers for these adapters, and one solution was to use ndiswrapper to horseshoe Windows Ethernet/WiFi drivers into Linux by means of translating the Windows ABI which the driver library expected to interact with. There was no hope that the manufacturers would bother writing these drivers for Linux and reverse-engineering is always a PITA.

And now we have the interesting situation where a firmware blob is available first (with a little bit of manual work) for Linux, a few weeks in advance.

Weird, but I will take it. :)

[bcdonadio]

And Microsoft is doing only the "delivery" part here. Mediatek has probably submitted the updated driver+firmware combo a while ago, but Microsoft keeps a regular cadence of updates in order not to drive the sysadmins (even more) nuts.

[pstlr78]

Ah, the new firmware might come packaged in the Update Tuesday (second Tuesday of the month), which is when Microsoft releases batches of patches, fixes and also driver updates as well. You might need to wait just until Feb 14 (guesswork though).

For some reason Windows Update Catalog does not have any drivers with reference to mtkwl6eux.inf . No drivers for Netgear A8000 there either. If you search on the internet you could only find the drivers on Comfast's website (older version 1.0.0.68), on 3rd party driver websites (v1.0.0.76) and on Netgear's website for A8000 (v1.0.0.108). Hence I would not expect anything on Feb 14th or whenever the new update is out.
Does it mean that Mediatek has developed some bespoke drivers for CF-951AX and A8000 that have never been distributed to Microsoft for regular updates?

@morrownr , the Windows driver pack (consisitng of various files) does include wifi_mt7961u_patch_mcu_1_2_hdr.bin and wifi_ram_code_mt7961u_1.bin firmware files too. If they are not used anywhere then why are they part of the package?

[whitslack]

FWIW: I have a new Alfa AWUS036AXML, and I can confirm that it Just Works™ when plugged into a machine running Linux 6.1.14. No USB mode switch is required.

It's so refreshing to see a Linux Wi-Fi driver that fully and correctly implements cfg80211/mac80211 rather than rolling its own proprietary garbage.

[bjlockie]

Nice adapter. Seems kind of expensive (especially outside the US) and not widely available yet.

[morrownr]

@whitslack

Congrats of the new Alfa. It would be cool if you take a some pics and start a new issue...if you have time.

[morrownr]

Seems kind of expensive (especially outside the US) and not widely available yet.

I'm going to defend Alfa on the price. I certainly would like to see a lower price but my experience is that Alfa products are generally worth it as they tend to use higher quality parts and their adapters tend to hold up better over the long term. Every Alfa adapter I have ever bought still works fine.

Something else to consider with this adapter is that it comes with a nice cable that plugs into either USB-C or USB-A. Good quality cables like this can cost $20 USD or more.

USB adapters can be problematic and the CF-951AX I have annoys me. The chipset works well and, as we know, the mt7921u driver is stabilizing out nicely. What gets me about the CF-951AX is that it will not work reliably unless it is plugged directly into a port on my desktop. This is likely a power issue which is a problem caused by the maker of the adapter, not the supplier of the chipset and driver. I'm thinking about dropping the CF-951AX from the in-kernel list as I have had it long enough now to see.

I'd really like a good report from @whitslack .

[BuyukBang]

Hello @morrownr,

Do you have a range comparison information between AWUS036AXML and AWUS036ACHM at 2.4Ghz? AWUS036AXML's TX Power is listed above as 30dBm at 2.4Ghz which seems similar to the AWUS036ACHM's 2.4Ghz PA SE2576L's output power listed in its specs. (Couldn't compare directly to AWUS036ACHM's iw list output since it reports absurdly low, whatever) Can we say that they both perform similar at 2,4Ghz in terms of range?

[morrownr]

Hi @BuyukBang

Do you have a range comparison information between AWUS036AXML and AWUS036ACHM at 2.4Ghz?

I do now. The AXML I have is a pre-production test model but I don't think there is anything that would have changed ragarding the results of this test.

2.4 GHz range test
Channel 1
Light congestion
22 feet and 2 walls between wifi router and adapters
Data comes from wavemon and iperf3

AXML
Link Quality: 100%
Signal Level: -28 dBm
iperf3 test: 97.5 Mbps

ACHM
Link Quality: 100%
Signal Level: -13 dBm
iperf3 test: 25.2 Mbps

Summary: The AXML shows higher throughput while the ACHM shows a signal level indicating it has longer range. This checks with Alfa's system of ratings. Alfa has 3 categories: Nornal, High Power and Max Power. The ACHM is a Max Power rated adapter while the AXML is a High Power rated adapter.

Power is not actually a good way to put it as the range is actually coming from the quality of the antennas and amp. Good antennas and AMPs are costly which is why you see Alfa's adapters usually costing more.

The reason for the AXML having higher throughput is that it is simply a later generation of 2.4 GHz technology. Both adapters are good quality adapters that should last for years. There are adapters on the market that would struggle to produce the signal levels from this test if they were 5 ft away from the router. Both of these adapter have really good range in the 2.4 band with the ACHM having extraordinary range.

Hope this helps.

@morrownr

[BuyukBang]

@morrownr ,

Thank you very much for sharing this information!

I really impressed how AXML performed in 2,4 GHz. I mean I didn't expected so much throughput difference at 2,4 GHz.

Signal level difference is 15dBm and this number seems to be matching how a PA in this price range amplificates WiFi signal. Now I better understood the difference between Alfa's "Max Power" and "High Power" categorisation. I wonder if there will be a "Max Power" version of AXML with a replaceble antenna.

Best regards,

[morrownr]

I wonder if there will be a "Max Power" version of AXML with a replaceble antenna.

The following is basically a rumor so take it as such.

I have heard there will be a Max Power version at some point this year. It won't be called AXML as it will have a new product number. It may use the mt7922u chipset. That is a sister chipset to the mt7921au but it has 160 MHz channel width capability.

[BuyukBang]

Sound as an effective and all-rounder solution in terms of speed and range.I wish this would happen.

[morrownr]

That 160 MHz channel width capability... whew! Can you say greater than 1 Gbps wifi?

[Snuupy]

Found a CF-953AX clone: https://www.aliexpress.com/item/1005005935638503.html

[bjlockie]

I don't see the chipset.

[whitslack]

Found a CF-953AX clone: https://www.aliexpress.com/item/1005005935638503.html

For $9.44, shipped, I'll bite.

I don't see the chipset.

It's in the product description. MT7921, it says. Doesn't specifically say it's the "AU" variant.

[Snuupy]

I don't see the chipset.

You need to have hawkeyes to read specs on anything tech related on aliexpress 😂

[morrownr]

@Snuupy

Thanks for the link.

If any of you get this adapter, how about letting us know the details on this adapter.

[whitslack]

If any of you get this adapter, how about letting us know the details on this adapter.

#309

[morrownr]

Hi @whitslack

Great post! I like the design as it includes a lot of vent holes even though the chipset has not shown to have any heating problems. It appears to be single-state as it includes a CD and no mention of bluetooth probably means single-function.

Should this adapter be in the Plug and Play list? If you think so after using it, tell me and I make it happen.

@morrownr

[whitslack]

Should this adapter be in the Plug and Play list?

I unplugged a Qualcomm/Atheros AR9271 802.11n adapter from a headless Raspberry Pi, plugged in the Fenvi, and powered up, and it came right up on my network with no config changes needed. I would call that pretty Plug-and-Play!