Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report: TP-Link USB AC600 Archer T2U Nano 1.0 #231

Closed
tukkek opened this issue Aug 17, 2024 · 7 comments
Closed

Report: TP-Link USB AC600 Archer T2U Nano 1.0 #231

tukkek opened this issue Aug 17, 2024 · 7 comments

Comments

@tukkek
Copy link

tukkek commented Aug 17, 2024

I will document my experience with the driver here extensively. I hope it's helpful in some way, perhaps to others who come across the same issues I've found solutions for or for future development.

First: I checked the hard-ware version on the dongle's packaging and it said 1.0 (I believe they go up to 3.0)?

I'm running a 6.9 x86_64 Debian Linux kernel ("amd64").

I already had an internal wireless card and had trouble using Network Manager with both adapters. I would select a saved connection and it would happen on my other card instead - even with the forced-device field set correctly (auto-filled by NM). Clicking on a saved connection would bring up the password prompt again (as if not saved) then load the connection on the older card instead even when selecting the USB device correctly both from the system tray icon and then from the prompt's drop-down.

However, loading a saved connection with nmcli worked. All tests were done with the old PCI card inactive.

DHCP was a major issue. It would take a long time to connect and then connect without IP4, which meant I couldn't access half of the Internet (including Git Hub and the Stack Overflow network). Checking journalctl I saw a message to the effect of "IP is already being used by host with MAC address of"... which continued to appear throughout my tests.

I tried disabling DHCP and configuring a static IP to no good result. It would work once then next connection the same error would happen.

I installed macchanger and wrote a script to randomize my MAC between disconnecting and reconnecting. It still wouldn't work. I reverted back to my permanent MAC after trying this.

I then tried forcing my own actual MAC as a spoof in Network Manager, which also didn't work. You'd think if I had leased the IP a minute earlier, I'd be able to get it back with my own MAC... almost as if the driver was providing a MAC different than mine by default.

What eventually resolved the issue was spoofing a MAC in Network Manager as the owner of the IP being reported by journalctl. This let me reconnect with a static IP but not only I wasn't able to get it working without hours of trouble-shooting but also didn't have DHCP and have no idea if this work-around would break in the mid- or long-term but it was the best setup I could get working.

I have a a 500 mega-bits-per-second 5G fiber-optics Internet. My actual speed once the connectivity issues were fixed was around or below 10 mega-bits-per-second. It varied from 0.5 up to 40 at one point but was mostly around 4-14 Mbps. The signal strength varied from 20 to 100% percent, around 50% most of the time.

I tried disabling power-saving via /etc/NetworkManager/conf.d/ but it had no effect. I set band to 5G on NM to ensure best speed (after having previously tested only 2G as well)..

I have another machine with basically the same Linux setup and packages (but different wireless network adapter) that is getting over 100 megabits-per-second every single time in the very same room - still a far-cry from the full 500 but a lot better than 10.

I happen to have an unused 2G wi-fi extender and decided to give it a try. Setting it right next to my PC, the extensor had 100% signal while the USB dongle only had 50%. Connecting to the extension rather than the router, I had 100% signal but only half speed as before.

Upload speed was dead-flat at around 700 kilobits-per-second, tested multiple times with the same results. The services I used for testing speeds were Google and Ookla.

I uninstalled the driver, installed 8821au instead and had none of these problems (weird GUI behavior; IP4 or DHCP issues)... Speed is still not great but I'll take 40 megabits-per-second over an average of 10 and upload speed is also much better than a flat 0 Mbps.

Compiling, installing and uninstalling were the only seamless parts of the experience but I am genuinely thankful for that.

With all being said, I'd like to thank everyone involved in this project. The supported chip-sets are extremely popular (and cheap) and it's past time they were supported in the kernel.

While my experience was obviously not a good one, I was able to figure out all the work-arounds myself despite being far from an expert in all things networking. If my life depended on having a working Internet connection, I'd be happy to have 10 Mbps over nothing too. The speed was the one thing I couldn't fix but I wish this team all the best in continuing to improve the driver. Cheers and good luck!

@ZerBea
Copy link

ZerBea commented Aug 17, 2024

Just to mention that here: macchanger is an ancient tool that still use ioctl system calls.
Is it possible to set the virtual MAC via RTNETLINK?
https://askubuntu.com/questions/1065871/change-network-mac-address-using-ip-command

@tukkek
Copy link
Author

tukkek commented Aug 17, 2024

I was able to spoof the MAC-address using the Network Manager GUI's field "cloned MAC address".

@ZerBea
Copy link

ZerBea commented Aug 17, 2024

@tukkek
Long live RTNETLINK - "Rest in Peace" ancient tools that still run ioctl system calls.
According to:
https://archlinux.org/packages/extra/x86_64/macchanger/
macchanger is really old:
https://github.com/alobbs/macchanger/commits/master/
Last commit is 11 years old!

I don't have a T2U NANO, but I have a T2Uv3. Changing the virtual MAC via RTNETLINK is no problem.

@morrownr
Copy link
Collaborator

morrownr commented Aug 17, 2024

@tukkek

First: I checked the hard-ware version on the dongle's packaging and it said 1.0 (I believe they go up to 3.0)?

For future reference and to save time reading that can best used on development: The only thing that matters is what chipset is in the adapter. We do not care about who made it and or if it version 1 or version 16.

I'm running a 6.9 x86_64 Debian Linux kernel ("amd64").

Yes, kernel is good to know as well as what chip but what version of Debian is this and what desktop? Gnome?

I already had an internal wireless card and had trouble using Network Manager with both adapters. I would select a saved connection and it would happen on my other card instead - even with the forced-device field set correctly (auto-filled by NM). Clicking on a saved connection would bring up the password prompt again (as if not saved) then load the connection on the older card instead even when selecting the USB device correctly both from the system tray icon and then from the prompt's drop-down.

This should be addressed to your distro. It is not a driver issue.

DHCP was a major issue.

It is hard to test a wifi driver when there are issues with your network. This also needs to be address with Debian but I will add that if this is Debian 12, for testing, you should use the supported kernel which is 6.1.

I read the rest. Now let's start off with what chipset you are testing. Post the results of:

$ lsusb

Reason: we don't know which driver you are testing. Once that is established and you are on the supported kernel, we can go from there.

Regards

@tukkek
Copy link
Author

tukkek commented Aug 17, 2024

I have no idea why you are telling me these are Debiar or network issues when literally all of my problems were immediately solved by switching to another driver. I see no point in further discussion if you don't think any of the issues are driver-related.

@morrownr
Copy link
Collaborator

I see no point in further discussion...

Me either.

@tukkek
Copy link
Author

tukkek commented Aug 17, 2024

Good luck with the project. Looks like you're gonna need it.

@tukkek tukkek closed this as completed Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants