[New Adapter] tp-link Archer TXE50UH (uses the mt7921au chip and mt7921u driver)

[morrownr]

I normally pay no attention to tp-link usb wifi products for reasons outlined in menu item 1 on the Main Menu but I do hear from people around the world where usb wifi adapter choices can be very limited. I often hear them say that tp-link products are available when other brands are not so I am posting this message and will consider adding this product to The Plug and Play List IF I get good reports from users of this adapter and people express their opinion that it should be included in the List. Given that Realtek does not make a AXE3000 class chip, it would be hard for tp-link to change the chip and keep the product number and packaging so this might be a case where this is a safe long term pick if it is a good adapter. With that said:

The tp-link site to the TXE50UH is as follows:

https://www.tp-link.com/us/home-networking/usb-adapter/archer-txe50uh

It is a very recent product almost no reviews at this time. Evidence points to it being a single-state (no windows driver onboard which is great). The evidence is that the ads I read said the package contains a cd. Why ship a cd if the driver is in the adapter?

It comes with a nice looking extension cable/cradle which is very welcome in order to place the adapter at a location where it can get good reception. The chipset is the mt7921au so it should be plug and play. Something confusing on tp-link's support site for this product is that they list a v1 and a v1.6. tp-link is notorious for changing chipsets without changing product model numbers which is a killer for us Linux users but in this case, the limited evidence I can find points to both versions using the same Mediatek chip. I have no idea what the real difference is in the 2 versions.

WARNING: If you decide you want to buy this adapter, I noticed that tp-link has numerous adapters with similar product names. I see the TX50UH name but that is NOT this product. You need to be very careful to get the TXE50UH

I'll wait for feedback before taking any action so please let me know what you think and if you have this adapter, please post the details and your opinion as to whether this is a good adapter that Linux users should consider.

@morrownr

[dogkeeper886]

I want to express my thanks for your helpful documentation. I have a TP-Link AXE3000 USB dongle, specifically the Archer TXE50UH (US) Version 1.0. I'm running Rocky Linux 5.14, which requires me to compile the kernel myself; I'm using version 6.1.119.

I encountered the same issue you described with the Netgear A8000. After creating a udev rule, I ran into a hardware initialization error. Luckily, I came across a post suggesting that adjusting the USB version to 2.0 might help. After doing so, the device finally worked, though it wasn’t a fun experience.

Thanks again for your support!

[morrownr]

G'day @dogkeeper886

Thanks for the report. Not exactly plug and play but it is a start.

What vid/pid does the adapter have?

I can help get the vid/pid into the kernel with a bit more testing and confirmation from another user. I hate to be picky but mistakes are a pain to clean up.

Did you use the latest firmware files?

While 6.1 should be okay, I generally recommend 6.6 or later if that is doable.

Keep me posted. I want to know how this adapter is working out.

[dogkeeper886]

Here is the lsusb info.
Bus 001 Device 003: ID 35bc:0107 MediaTek Inc. Wireless_Device
I think the kernel or linux distribution did a great job. We just missing a udev rule. I remember trying it on Fedora before, which already has the mt7921u module, but it still wasn't plug-and-play. At the time, I didn't realize where the problem was.

[morrownr]

@dogkeeper886

Okay, so the vid/pid is ID 35bc:0107 . Do you mind running and posting the results of the following just to double check:

$ lsmod | grep mt79

I think the kernel or linux distribution did a great job. We just missing a udev rule.

We have Mediatek to thank for doing their Linux driver the right way. In fact, Mediatek already has the mt7925u driver in the kernel. That is a WiFi 7 chip. I run a M.2 card with a mt7925 chip and it runs well. It uses the mt7925e driver.

For educational purposes:

It is best if the adapter makers use a chip maker standard vid/pid but some, like Netgear and TP-Link, use their own. Edup, Panda, Alfa and Fenvi generally use the standard vid/pid. You can see this in the Plug and Play List in the mt7921au section. Right now, the Netgear adapter is the only one where we had to add a udev rule and send a patch to linux-wireless.

Adding a udev rule is a temp fix. The real fix is to send a patch to linux-wireless to get the new vid-pid included in the mainline kernel. Would you like to assist me in doing that?

Back to business: Can I get you to do a test on the adapter to see if it is a single-state (no storage for Windows driver) adapter? If so, we can turn usb_modeswwitch off and if you reboot, your adapter should still come right up and be useable. Here is how to turn usb_modeswitch off:

How to deactivate usb_modeswitch:

sudo nano /etc/usb_modeswitch.conf

Change

DisableSwitching=0

to

DisableSwitching=1

sudo reboot

[dogkeeper886]

Thanks, bro! I never had the chance to understand that before. I'll give the usb_modeswitch thing a try.

`HTML

mt7921u                24576  0
mt7921_common          94208  1 mt7921u
mt76_connac_lib        81920  2 mt7921_common,mt7921u
mt76_usb               40960  1 mt7921u
mt76                  106496  4 mt76_usb,mt7921_common,mt76_connac_lib,mt7921u
mac80211             1261568  3 mt76,mt7921_common,mt76_connac_lib
cfg80211             1110016  5 mt76,mac80211,mt7921_common,mt76_connac_lib

`

[morrownr]

Thanks for confirming that the adapter is using the mt7921u driver. Let me know the results of the usb_modeswitch test.

After creating a udev rule, I ran into a hardware initialization error. Luckily, I came across a post suggesting that adjusting the USB version to 2.0 might help.

As you have time, give me more details about this issue What were you seeing when in USB3 mode?

Let me know when you are ready to step through the process of sending a patch to linux-wireless and I will start sending information so that you can walk through it with me. If we can finish within 2 weeks or so then the patch should go into kernel 6.14 just in time for Ubuntu 25.04 and if we say the right things, the patch will be backported to the 6.12, 6.6 and 6.1 LTS kernels. Cool huh? This will make your adapter truly plug and play going forward.

[dogkeeper886]

I connected it to another Windows 10 PC, but it doesn't have the storage folder, similar to what happened with my Rocky Linux setup. Is this the information you need?

By the way. I verified the USB3 initialization problem on another desktop, and it didn't occur.

[morrownr]

I connected it to another Windows 10 PC, but it doesn't have the storage folder, similar to what happened with my Rocky Linux setup. Is this the information you need?

Yes, I am looking for confirmation that this adapter is single-state (no onboard Windows driver). It sounds like you are confirming that the adapter is single-state.

I go through a list of bad things to filter out adapters that should not go into the Plug and play List. Another on the list is multi-function (wifi and bluetooth support). Can you confirm that no bluetooth support is turned on?

So far, this adapter looks like a good candidate to go into the Plug and Play List. Are you seeing anything, other than the vid/pid not being in the kernel yet, that would cause you to tell me not to put this adapter in the Plug and Play List? If not, let me know when you are ready to work with me on getting the vid/pid in the kernel. We can take it one step at a time.

Since you are compiling a mainline kernel for Rocky anyway, that would make it easy for you to test the patch that we come up with.

[dogkeeper886]

My TP-Link Archer TXE50UH doesn't have Bluetooth. It would be nice if we can use it without all the extra effort.

[morrownr]

It would be nice if we can use it without all the extra effort.

We can fix that. It would have been best if TP-Link had used the Mediatek standard vid/pid for the mt7921au chip. This would have meant the adapter would have worked immediately in modern Linux distro from the beginning. But they did not do this so we need to submit the vid/pid to have it included in the kernel. At that point, anyone else that buys the same adapter will have an adapter that works...plug and play as long as they are using the right kernels. We can have the patch backported all the way back to kernel 6.1.

If you want to go ahead and test my patch, I will tell you which file in the kernel source so that you can modify it and compile it.

[morrownr]

@dogkeeper886

It would be nice if we can use it without all the extra effort.

I'm willing to submit a patch so that the "extra effort" goes away. I need you to test the patch. Are you willing to do that?

[dogkeeper886]

Sure, no problem. I can do it tomorrow.

[morrownr]

For the test:

Edit the following file in the kernel source:

drivers/net/wireless/mediatek/mt76/mt7921.usb.c

Starting on or about line 15, note the section of code below:

static const struct usb_device_id mt7921u_device_table[] = {
	{ USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7961, 0xff, 0xff, 0xff),
		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
	/* Comfast CF-952AX */
	{ USB_DEVICE_AND_INTERFACE_INFO(0x3574, 0x6211, 0xff, 0xff, 0xff),
		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
	/* Netgear, Inc. [A8000,AXE3000] */
	{ USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9060, 0xff, 0xff, 0xff),
		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
	/* TP-Link TXE50UH */
	{ USB_DEVICE_AND_INTERFACE_INFO(0x35bc, 0x0107, 0xff, 0xff, 0xff),
		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
	{ },
};

Note the line /* TP-Link TXE50UH */ , add it and the next 2 lines and save.

Compile and install the kernel.

Remove the udev rule that you had installed.

Boot and see if the adapter comes to life

Let me know how it goes.

Thanks.

[dogkeeper886]

I found the relevant code at /usr/src/kernels/linux-6.1.120/drivers/net/wireless/mediatek/mt76/mt7921/usb.c. The device ID for the MT7921U is mt7921u_device_table. Although the format is slightly different, it's still functional.

static const struct usb_device_id mt7921u_device_table[] = {
        { USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7961, 0xff, 0xff, 0xff) },
        /* TP-Link TXE50UH */
        { USB_DEVICE_AND_INTERFACE_INFO(0x35bc, 0x0107, 0xff, 0xff, 0xff) },
        { },
};

I found the code at /usr/src/kernels/linux-6.12.4/drivers/net/wireless/mediatek/mt76/mt7921/usb.c. The code matches what you previously provided, and it's working as expected.

static const struct usb_device_id mt7921u_device_table[] = {
        { USB_DEVICE_AND_INTERFACE_INFO(0x0e8d, 0x7961, 0xff, 0xff, 0xff),
                .driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
        /* Comfast CF-952AX */
        { USB_DEVICE_AND_INTERFACE_INFO(0x3574, 0x6211, 0xff, 0xff, 0xff),
                .driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
        /* Netgear, Inc. [A8000,AXE3000] */
        { USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9060, 0xff, 0xff, 0xff),
                .driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
        /* TP-Link TXE50UH */
        { USB_DEVICE_AND_INTERFACE_INFO(0x35bc, 0x0107, 0xff, 0xff, 0xff),
                .driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
        { },
};

[morrownr]

@dogkeeper886

Okay, so it tested good. I'll make a patch to send in. I'd like to add a Report-by line and a Tested by line and use your name and email address if that is okay.

[morrownr]

@dogkeeper886

FYI: Here is the patch minus your information in Report-by: and Tested-by:

Forward your info to me as you can so we can get this patch in mainline.

From 647960fed3629e0ae112a6c76c8ed2d5dcd3a727 Mon Sep 17 00:00:00 2001
From: Nick Morrow <[email protected]>
Date: Tue, 17 Dec 2024 06:40:50 -0600
Subject: [PATCH] wifi:mt76:mt7921au:Add new VID/PID 35bc/0107 for TP-Link TXE50UH
Add new VID/PID 35bc/0107 for TP-Link TXE50UH

Reported-by:
Tested-by:
Signed-off-by: Nick Morrow <[email protected]>
Cc: [email protected]
---
 drivers/net/wireless/mediatek/mt76/mt7921/usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
index 8aa4f0203208..e3459295ad88 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
@@ -21,6 +21,9 @@ static const struct usb_device_id mt7921u_device_table[] = {
 	/* Netgear, Inc. [A8000,AXE3000] */
 	{ USB_DEVICE_AND_INTERFACE_INFO(0x0846, 0x9060, 0xff, 0xff, 0xff),
 		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
+	/* TP-Link TXE50UH */
+	{ USB_DEVICE_AND_INTERFACE_INFO(0x35bc, 0x0107, 0xff, 0xff, 0xff),
+		.driver_info = (kernel_ulong_t)MT7921_FIRMWARE_WM },
 	{ },
 };
 
-- 
2.39.5

[dogkeeper886]

Sure, go ahead.

[morrownr]

I'd like to give you credit for reporting and testing. See the following section of the above message:

Reported-by:
Tested-by:
Signed-off-by: Nick Morrow <[email protected]>

With your name and email address, you will get credit for reporting and testing this issue. Cool. If that is not what you want to do then I can leave it off and submit the message.

[BlanceIsBetter]

I read this post and buy TXE500UH(US) Ver.1 for my openwrt 23.05.5 device on raspiberry pi 4.(build in AC wireless range is so short.)

Easy way to use this device is download mt7921 and pain file put in right place,write device id to new_id file.
It is easy as morrownrs say.
Some information give you know.

TXE500UH use USB 3 port is fast than USB2 port (test by iferf3,android and ios device),USB2 never over 300Mbps USB3 can run 6-700Mbps maybe is hardward limit.
Pi 4 tempture will effert wifi speed.
6Ghz not run,I change country code to US,it can see 6G in luci control,but my 6E mobile device can't see SSID.

Very thanks both.

[dogkeeper886]

I'd like to give you credit for reporting and testing. See the following section of the above message:

Reported-by:
Tested-by:
Signed-off-by: Nick Morrow <[email protected]>

With your name and email address, you will get credit for reporting and testing this issue. Cool. If that is not what you want to do then I can leave it off and submit the message.

Reported-by: Nick Morrow [email protected]
Tested-by: Shang Chieh Tseng [email protected]
Signed-off-by: Nick Morrow [email protected]

[morrownr]

@dogkeeper886

Message sent to linux-wireless. If things go as expected, the patch will initially go into kernel 6.14 and then will be also be applied to kernels 6.13, 6.12, 6.6 and 6.1. So, depending on the distro you use, within maybe 2 months. you may not need the udev rule anymore and your adapter will be plug and play for as long as you use it. Thanks for the report and the help.

One last thing for now: As you use the adapter, let me know if you think the TXE50UH should be included in The Plug and Play List.

[morrownr]

@BlanceIsBetter

Very thanks both.

I hope the adapter works well for you. Give us reports about it as you have time. We need to determine if this adapter should be in the Plug and Play List.

I change country code to US, it can see 6G in luci control, but my 6E mobile device can't see SSID.

The current regdb may not allow AP mode with the adapter in the US. You can run the following to see what it says about the 6 GHz channels:

iw list

If it says No IR then AP mode is not going to work for now. Given the serious reduction in txpwr for 6 GHz, it is of somewhat limited benefit.

[BlanceIsBetter]

@morrownr

I hope the adapter works well for you. Give us reports about it as you have time. We need to determine if this adapter should be in the Plug and Play List.

I have tested the Plug and Play as below describes.

Power off the Pi and unplug usb dongle, then restart Pi. I plug in a new usb port that never used, It will generate new interface and default wifi, just need to setup it can run well.

Then I direct to pull out usb dongle to another used usb port,it can run well too.

The current regdb may not allow AP mode with the adapter in the US. You can run the following to see what it says about the 6 GHz channels:

iw list

If it says No IR then AP mode is not going to work for now. Given the serious reduction in txpwr for 6 GHz, it is of somewhat limited benefit.

As you say, 6 GHz list No IR....(Country code:US JP TW)
I think it's a pity, it would be better if it can operate at full frequency.

Thanks for teaching, I learned more.

====

To correct the previous test.
USB2 port can rut faster about 400Mbps, it need run at high frequency.

[dogkeeper886]

I read this post and buy TXE500UH(US) Ver.1 for my openwrt 23.05.5 device on raspiberry pi 4.(build in AC wireless range is so short.)

Easy way to use this device is download mt7921 and pain file put in right place,write device id to new_id file. It is easy as morrownrs say. Some information give you know.

TXE500UH use USB 3 port is fast than USB2 port (test by iferf3,android and ios device),USB2 never over 300Mbps USB3 can run 6-700Mbps maybe is hardward limit. Pi 4 tempture will effert wifi speed. 6Ghz not run,I change country code to US,it can see 6G in luci control,but my 6E mobile device can't see SSID.

Very thanks both.

Nice to hear that. Thank you.

[morrownr]

The patch to add the ID for this TXE50UH adapter has been accepted as you can see a the below link:

https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/

This means it should go into kernel 6.14 which should go into testing early next month. I also requested that the patch be applied to the existing supported kernels which as 6.13, 6.12, 6.6, 6.1. Can't go back further than that as the driver went into kernel 5.18.

So, this adapter should be plug and play soon.

I do need reports from everyone that has this adapter: The question that I needed answered is:

Should this adapter be in the Plug and Play List?

[morrownr]

I have added this adapter to The Plug and Play List based on information here and in other locations. If any problems come up, please let me know so that I can reevaluate whether the adapter should be included in The Plug and Play List.