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

[morrownr]

Hey @black-jmyntrn

where do I obtain the 5.19 kernel to compile openwrt for raspberry pi 4?

You don't. It is uncessary. Some of the OpenWRT devs are also Mediatel kernel devs. They backported mt7921u to the 5.10 kernel that is in the current 22.03.x version of OpenWRT.

All you need to do is install the following package:

kmod-mt7921u

Something to be aware of for 22.03.x is that the devs made a mistake that has been fixed in master but probably won't be fixed in 22.03.x: Installing that package should also install the the firmware but the firmware is in the kmod-mt7921e package so you either have to also install it or manual install the firmware. If you go to the Main Menu here and select menu item 8, it has a section on manually installing the firmware.

Keep in mind that Luci is not ready for WiFi 6e so that would have to be setup manually. It does do WiFi 6 just fine.

Nick

[pstlr78]

@morrownr , I read paragraph 2 in the "How to install Firmware" section, but I am wondering if one can update the firmware of CF- 951AX via Windows. It is clear that in Openwrt devices (e.g. router) that use the mt*** chipsets, one can use tftpd64 to "log in" to the device and copy paste the 3 bin files in the lib/firmware directory of that device. Then upon reboot, the new firmware will be used. However how one can perform this on a USB wifi adapter via Windows (how to log in to the root directory of the USB Wifi adapter itself)?

[bcdonadio]

@pstlr78 The USB adapter does not have any persistently updateable firmware. In fact, it doesn't have much at all in terms of stored code. It's cheaper to just put a really small initialization code, capable of loading the heavy-lift program, into a NOR storage bank in the main die (the MT7921 itself) or even just use a litography mask to simply burn this really small code into said die and then add a cheap SRAM chip next to it in the PCB (or even a SRAM chiplet in the same epoxi encapsulation), than to add yet another NAND storage chip into the PCB.

NOR is basically always needed for the first initialization instructions anyway, but it is really expensive compared to NAND. You want to minimize your cost per unit. The same goes for the SRAM: you already need that for it to work. In comparison, the NAND chip would be used just during the first seconds or so and then sit idle (you cannot retrieve code from the NAND chip as fast as you need from SRAM, and NAND has a pretty limited amount of write cycles you can perform).

The task of loading the main firmware into the SRAM then is offloaded to the operating system. When you perform the instructions you referred in OpenWRT, you're just storing the new firmware that OpenWRT will load into the device every boot. Windows needs to do the same, and that is distributed through the generic term of "driver" updates, which includes both the firmware and the OS kernel module needed to properly interact with the device.

With Windows there's a restriction though: the package containing those two pieces of code needs to be signed. You won't be loading random code into these kind of devices with the Windows kernel (actually there's a way, because the developers need to test their code, but it basically means disabling all OS protections and even some OS features).

Basically, you need to wait for Mediatek to publish a new signed driver with this firmware version. The flip side of it is that Mediatek distributes this via the Windows Update mechanism, so you normally don't need to take any further action other than wait patiently.

[bcdonadio]

And just to complement: with Apple's OSX you just... don't. You can't load "non-exempted" third-party modules into the OSX darwin kernel since Catalina in x86, enforced by the infamous T2 security chip. In Apple Silicon... well, f**k you and your peasant USB adapter. :P

There's no third-party kernel module loading anymore (they were known as kext, for Kernel EXTension). Either it's a standardized USB device class that Apple themselves have written the interface code for it (meaning no firmware loading), or you are simply SOL. It has its security advantages, though...

In the grand scheme of things I appreciate this stance Apple has, though. It drove Adobe Flash to extinction, thank god, it ensures that third-party apps and drivers won't ruin the experience Apple wants you to have, and most importantly disencourages lazy software/hardware manufacturers from writing stinky code that drives the user nuts. Notice how much crap used to initialize with Windows if you wanted to use X or Y application (even if you weren't even going to use it!) and how much this has improved in the last few years were Microsoft started tightening the rules just a bit (not by a long shot how much Apple did, of course).

Since you, as a company, always want to reduce your development costs, it makes sense to just adhere to the damn standards than choosing to support a single platform and also have every developer splashing your screen with useless stuff during initialization, bloating your performance by running either useless, tracking or just plain lazily-written stuff in the background, thinking that users have personal devices (desktops, laptops, tables, phones...) just to run their shiny little bit of crappy code and nothing else. This policy made Flash, ActiveX and Java WebStart a thing of the past (again, thank god), and we now just adhere to whatever WebKit/Blink developers think which flavor of HTML5 and JS is good for the world /sarcasm.

This helped the FOSS community immensely. Supporting new peripheric hardware is becoming easier and easier because of adherence to standards. The only barrier I don't want them to cross is the one on preventing custom OSes in PCs, of course. When I buy Apple hardware I'm paying to have the Apple experience, knowingly. When I buy PC hardware I'm paying to run whatever the hell I want, and I don't like surprises... As long as the expectations are in sync beforehand, personally I think that's completely OK.

[pstlr78]

@pstlr78 The USB adapter does not have any persistently updateable firmware. In fact, it doesn't have much at all in terms of stored code. It's cheaper to just put a really small initialization code, capable of loading the heavy-lift program, into a NOR storage bank in the main die (the MT7921 itself) or even just use a litography mask to simply burn this really small code into said die and then add a cheap SRAM chip next to it in the PCB (or even a SRAM chiplet in the same epoxi encapsulation), than to add yet another NAND storage chip into the PCB.

NOR is basically always needed for the first initialization instructions anyway, but it is really expensive compared to NAND. You want to minimize your cost per unit. The same goes for the SRAM: you already need that for it to work. In comparison, the NAND chip would be used just during the first seconds or so and then sit idle (you cannot retrieve code from the NAND chip as fast as you need from SRAM, and NAND has a pretty limited amount of write cycles you can perform).

The task of loading the main firmware into the SRAM then is offloaded to the operating system. When you perform the instructions you referred in OpenWRT, you're just storing the new firmware that OpenWRT will load into the device every boot. Windows needs to do the same, and that is distributed through the generic term of "driver" updates, which includes both the firmware and the OS kernel module needed to properly interact with the device.

With Windows there's a restriction though: the package containing those two pieces of code needs to be signed. You won't be loading random code into these kind of devices with the Windows kernel (actually there's a way, because the developers need to test their code, but it basically means disabling all OS protections and even some OS features).

Basically, you need to wait for Mediatek to publish a new signed driver with this firmware version. The flip side of it is that Mediatek distributes this via the Windows Update mechanism, so you normally don't need to take any further action other than wait patiently.

I wonder how many years have passed since I got such a good and comprehensive response from a community user/developer! Congratulations and many thanks for the time you spent to share your knowledge with other less experienced people like me.

I was (incorrectly) under the impression that always a comprehensive flashed firmware on a chip AND a driver was needed to operate a device in any OS. Your respone answers to my question how the hell would one "log in" to a USB Wifi adapter to update its firmware: You simply don't/can't, because there isn't always a comprehensive flashed firmware on any device, mainly because of the economics you outlined above. I understand now that you can have a "virtual" firmware part in the driver package instead, which loads along with the OS in order to make a device usable. With Linux you have the freedom to change/replace/update the firmware part yourself, while in Windows you just depend on the signed driver package (with the associated delays and sign off procedures) whenever this comes out.

I hope and I trust that Mediatek is quite active in updating its Windows drivers as is in sharing and updating the Linux firmware for MT7921, so that I won't be lagging behind too much.

[Aqua1ung]

Alright guys, so what's the bottom line please? Does anyone care to update the OP with the following details:

1. Do the Comfast adapters support 6Ghz in Linux?
2. What is the main difference between the two Comfast adapters? Just the antennas?

[morrownr]

Hi @Aqua1ung

1. Yes. However, it is interesting. 6 GHz is still evolving and countries around the world either have not approved the use or are in the process. An example of a country that has not approved 6 GHz is Taiwan. Can you imagine being a company that makes wifi adapters? How are you legally going to test your product? The only area that seems to have it together is the EU to include countries such as FR and DE. Trying to use a wifi adapter in the US in AP mode is not easy.

2. I have a CF-951AX so can't speak with first hand experience about the CF-953AX, however I can pass on what others say. The CF-953 probably has a little better range due to the external antennas. Both are single function (wifi only, no BT). Both are single-state. I consider both to be features, not bugs. Both support USB3 and WPA3. 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. Both adapters are wide and will block usb ports to the side on many computers such as a RasPi4B. You can use the following to overcome this:

https://www.amazon.com/dp/B07S6B5X76

My opinion is that both adapters are about the same but I'd lean toward the 953 based on what I have read.

Overall: Both are low end products that will meet the need for many projects. The onboard mt7921au chipset is VERY fast in the 5 GHz band and the in-kernel driver (mt7921u) is stable. The low price makes then attractive for many projects that only require short to medium range.

Nick

[morrownr]

@Aqua1ung

Short follow on: Several adapters are in the works so I expect by mid-year we will have many adapters to choose from. I'm looking forward to Alfa releasing a long range (they call it high power) adapter.

[usama7628674]

@morrownr Have you reached alfa to confirm AWUS036AXML is not a high power adapter? The shape of this adapter resembles much of AWUS036ACH and AWUS036ACHM.

[morrownr]

Have you reached alfa to confirm AWUS036AXML is not a high power adapter?

Yes

[fs30000]

So generally speaking, you guys recommend the mt7921au over the 8832au?

[morrownr]

Hi @fs30000

So generally speaking, you guys recommend the mt7921au over the 8832au?

I certainly recommend the mt7921au chipset over the 8832au and it is not close.

mt7921au has in-kernel driver that is very stable already. It is the mt7921u driver. It has been in the kernel since 5.18.

Mediatek is working hard to increase the capabilities of mt7921u as patches come in weekly, sometimes daily. It currently supports managed, AP and monitor mode with P2P on the way.

Realtek has no -in-kernel driver for the 8832au. I was able to find a copy of the out-of-kernel driver and I did my best to get it into good enough shape to open it up in a public repo but, in the end, I had to give up. The driver is terrible.

If you go to the Main Menu here and then select the option about Realtek drivers, I give a run down of what is good and what is not. My recommendation for Linux users is to avoid adapters with the rtl8852au/8832au chipsets.

Nick

[bcdonadio]

@fs30000 I have both. I can't use the 8832au even as a doorstop because its too light. Too unstable, and a even huger PITA to use it in a fast-paced distro like Fedora which I use. Ditto for the 8814au. Even in a Windows environment these chips are shaky and prone to crashes for no apparent reason.

While with the mt7921au I plugged it in Fedora 36 a few months ago (kernel 5.19 I think) and was going to open @morrownr 's page to build the out-of-tree driver, and instead NetworkManager popped up asking for my WiFi password to which the thing simply worked like a breeze. We even discovered the non-marketed fact (by the OEM at least) that it supported the 6GHz band and it was just a question of time for the regulatory db be properly updated in the kernel for it to work. If you disable the regulatory check in a RF caged lab environment (or live in France) you can already use the band with pretty much the fastest speed that the much bloated 5Gbps USB3.0 bus can provide. Promiscuous mode working, with constant improvements for further stability and performance. AP mode was added a bit later by direct contributions of Mediatek to the mainline kernel, just as with most of their others chips.

The only other candidate in this category I would consider would be the Intel AX210. It works. Lacks a lot of features and imposes regulatory restrictions based on its own collected cues instead of using the database supplied by the kernel, but does a good job overall and actually delivers the promised great performance (also out of the box, no module building needed).

[Aqua1ung]

@Aqua1ung

Short follow on: Several adapters are in the works so I expect by mid-year we will have many adapters to choose from. I'm looking forward to Alfa releasing a long range (they call it high power) adapter.

Now that I have my 953 adapter, what sort of hacks are needed to get it to see my 6 GHz network?

[bcdonadio]

@Aqua1ung Short follow on: Several adapters are in the works so I expect by mid-year we will have many adapters to choose from. I'm looking forward to Alfa releasing a long range (they call it high power) adapter.

Now that I have my 953 adapter, what sort of hacks are needed to get it to see my 6 GHz network?

The regulatory database hasn't been officially updated yet by Set Forshee as of January 22 2023. Of course, developers need to test their hardware before even submitting it for FCC compliance testing. Circumventing the database is not as simple as enabling the boolean that I'm going to link you, but you should be able to follow the breadcrumbs if you're technically capable of guaranteeing that you won't be generating harmful interference or illegal spectrum utilization in your country. Please don't proceed otherwise.

https://github.com/torvalds/linux/blob/master/net/wireless/Kconfig#L71

The reason why I'm stressing the importance of this is not only because it can generate legal repercussions to you, but also because it can affect the whole open source community too. As written in the regdb wiki, that's really important to be aware:

Addressing vendor concerns

Based on discussions and conference calls before and after the 2007 summit it became clear that the main vendor concern over supporting FOSS drivers was to provide a mechanism to enforce regulatory compliance to satisfy their own and their hardware vendors (OEMs like Dell, HP, IBM) legal department's concerns over legal liability. Additional concerns have been that a FOSS driver may force hardware vendors to certify their platforms under new Software Defined Radio regulations. Additionally, also that the FCC is only one of the many regulatory agencies vendors take into consideration for certifying devices – the major vendor's geographies of interest are governed under the FCC, ETSI and MKK. Vendors explained their concerns over getting devices certified under FCC SDR regulations is the uncertainty of the details involved for such certification. Vendors need to provide driver solutions which meet legal criteria on all of their geographies of interest.

Our stance and solution

Security through obscurity is simply not bullet proof but we do have precedents of its use to allow vendors to support drivers on Linux, either through a FOSS driver and binary firmware or through a binary driver. Real technical solutions can be used instead of relying on archaic security through obscurity mechanisms for support of FOSS wireless drivers on the Linux kernel. Our solutions have been to get commitment from the community developers to not accept patches upstream which alter regulatory considerations for drivers and to pave the way for open platforms to embrace a framework supported by the community to further advance regulatory considerations.

Based on the previous release cadence, a new signed version of the regdb is supposed to be available really any week now. I'm sure that both OpenWRT and Fedora, at least, will incorporate the new release when it happens in a matter of just a few days.

Stay safe.

[fs30000]

@Aqua1ung Short follow on: Several adapters are in the works so I expect by mid-year we will have many adapters to choose from. I'm looking forward to Alfa releasing a long range (they call it high power) adapter.

Now that I have my 953 adapter, what sort of hacks are needed to get it to see my 6 GHz network?

Please post iperf results :)

(thanks for the replies guys)

[bjlockie]

Why are countries so slow to get 6GHz approved? That should have been done before any products were released.

To the OP, try a different channel.

[morrownr]

@fs30000

Please post iperf results :)

139

[HappyOtto]

Got Comfast CF-953AX, in ArchLInuxarm on RPi4 latest firmware installed https://github.com/morrownr/USB-WiFi/blob/df8defe56fa1b5507648d74824a9fe99950ac3a4/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md , but usb adaptor is not recognized. Looks like driver is missing? Please advice. P.S. Adapter is working in VMware Fusion, but not in ArchLinuxarm.

[morrownr]

This is likely a kernel version issue. You need kernel 5.19 or later. I can't give specific instructions myself but there should be folks in the Arch forums that can help you.

For what its worth, the current version of RasPiOS is still on 5.15 so I had to download the RasPiOS specific version of the mainline kernel and compile it. It has 6.1. Work fine. I expect the next version of RasPiOS to ship with 6.1.

[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!