search

cilynx / rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959

rtl88x2bu driver updated for current kernels.
http://www.wolfteck.com/2018/02/22/wsky_1200mbps_wireless_usb_wifi_adapter/
355 stars 117 forks source link

TP-Link T4U v3 #2

Closed mentaluproar closed 5 years ago

mentaluproar commented 5 years ago

Is it possible to fix this so it properly compiles on arm64? It tries to compile on aarch64 on the rock64. Forcing it to arm64 work, but would break the build on other platforms. I don't have the skill to do a proper fix, just this hack.

Also, the TP-Link T4U sometimes includes an rtl8812BU chip, instead of an AU chip. This is the only driver I've found that works. Could you add the USB ID 2357,0115?

cilynx commented 5 years ago

What do you mean by "forcing it to arm64"? Are you doing something like ARCH=amd64 make or something else? I don't have easy access to an arm64 build environment, so I'll need a bit more info to help here.

Re T4U, it's already included here:

https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959/blob/c78ed5a4197fbaca3c94dcbe649f0dccf5203852/os_dep/linux/usb_intf.c#L233-L244

Are you running into issues with your device being detected?

mentaluproar commented 5 years ago

I dint even thing of passing an argument. I just swapped out the ARCH=$(whatevergoeshere) to arm64 in the makefile.

The device has a USB ID that isnt included in the usb....oh goddammit.

cilynx commented 5 years ago

Passing ARCH as an environment variable should work, else it'll automagically be set to uname -m | sed -e s/i.86/i386/. It looks like the Makefile is expecting uname -m to return "amd64" for that sort of system. I assume uname -m returns "aarch64" on yours? Assuming that's the case, try updating line 1033 of the Makefile to be SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ | sed -e s/aarch64/arm64/) and let me know if it builds clean for you then with just a vanilla make.

https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959/blob/c78ed5a4197fbaca3c94dcbe649f0dccf5203852/Makefile#L1033

As for your USB device, what does lsusb show?

mentaluproar commented 5 years ago

passing arch did work, but it did not see my device. When i got it working, I had that device ID under the 8812, not 8822.

cilynx commented 5 years ago

Does updating the Makefile line work? If that works, I should be able to commit that change w/o impacting anyone negatively.

With respect to the device ID sections, I'm seeing a lot of conflicting information:

Can you share your lsusb line for your device? I didn't think it was possible for different chipsets to have the same device ID, but I've been wrong before.

mentaluproar commented 5 years ago

rock64@covfefe_table:~$ lsusb Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 2357:0115
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So is this a V4 then?

cilynx commented 5 years ago

I'm not aware of a V4. Sucks that lsusb doesn't give you any more information than the ID. Here are the T4U revisions to the best of my knowledge:

{USB_DEVICE(0x2357, 0x0101), RTL8812}, /* TP-Link - Archer T4U V1 (AC1200 Base Model) */
{USB_DEVICE(0x2357, 0x0103), RTL8812}, /* TP-Link - Archer T4UH V1 (AC1200 High Gain) */
{USB_DEVICE(0x2357, 0x010D), RTL8812}, /* TP-Link - Archer T4U V2 (AC1300 Base Model) */
{USB_DEVICE(0x2357, 0x010E), RTL8812}, /* TP-Link - Archer T4UH V2 (AC1300 High Gain) */
{USB_DEVICE(0x2357, 0x010F), RTL8812}, /* TP-Link - Archer T4UHP(UN) V1 (AC1300 High Power Wireless Dual Band USB Adapter) */
{USB_DEVICE(0x2357, 0x0115), RTL8822B}, /* TP-Link - Archer T4U V3 (AC1300 Wireless Dual Band USB Adapter) */
{USB_DEVICE(0x2357, 0x0122), RTL8812}, /* TP-Link - Archer T4UHP(US) V1 (AC1300 High Power Wireless Dual Band USB Adapter) */
{USB_DEVICE(0x2357, 0x012D), RTL8822B}, /* TP-Link - Archer T3U (AC1300 Mini Wireless MU-MIMO USB Adapter) */

Is this your adapter? If not, you can flip through pictures of the different versions on that page.

mentaluproar commented 5 years ago

That's it alright.

cilynx commented 5 years ago

Alright -- let's go down this road a little further. What do you get in your syslog when you plug the thing in? You're looking for something vaguely similar to:

Dec 16 18:16:56 xps kernel: [3390056.534113] usb 1-1.4: new high-speed USB device number 47 using xhci_hcd
Dec 16 18:16:57 xps kernel: [3390056.646440] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 2.10
Dec 16 18:16:57 xps kernel: [3390056.646444] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 16 18:16:57 xps kernel: [3390056.646446] usb 1-1.4: Product: 802.11ac NIC
Dec 16 18:16:57 xps kernel: [3390056.646448] usb 1-1.4: Manufacturer: Realtek
Dec 16 18:16:57 xps kernel: [3390056.646449] usb 1-1.4: SerialNumber: 123456
mentaluproar commented 5 years ago

Dec 20 03:22:09 covfefe_table kernel: [ 1304.644852] usb 1-1: new high-speed USB device number 2 using dwc2 Dec 20 03:22:09 covfefe_table kernel: [ 1305.090073] usb 1-1: New USB device found, idVendor=2357, idProduct=0115 Dec 20 03:22:09 covfefe_table kernel: [ 1305.090104] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 20 03:22:09 covfefe_table kernel: [ 1305.090125] usb 1-1: Product: 802.11ac NIC Dec 20 03:22:09 covfefe_table kernel: [ 1305.090145] usb 1-1: Manufacturer: Realtek Dec 20 03:22:09 covfefe_table kernel: [ 1305.090165] usb 1-1: SerialNumber: 123456

Gotta say, it's like TP-Link didn't care when they shipped this.

cilynx commented 5 years ago

A vendor not care about the product they push out the door? Perish the thought! I ordered one of the T4U v3 just for S&G. It should be here on Friday and I can play around with which driver(s) work(s) and why.

mentaluproar commented 5 years ago

Crack it open and check what chip it uses. Mine had me clueless until I opened it up and looked directly at the chip. Mine showed no version number anywhere. I still have the box if that would help you.

The arm64 make you threw in built right. It isn’t seeing any networks yet but I’m going to take a break from it for a few hours. It’s probably something I did.

cilynx commented 5 years ago

Alrighty -- so the T4U v3 is definitely an RTL8812BU chip. You can see it on the internal photos on the FCC registration site. Adding 2357:0115 to either 8812AU or 8822BU driver makes the thing show up, but it never gets past "hardware disabled". I've played around a bit with rfkill to no avail. I've found a few folks who have other 8812BU powered adapters working with the 8822BU driver, but I'm not finding anyone who has this specific adapter working. The CD that comes with the adapter has a text file saying to look online for the Linux driver. Downloading the T4U v3 Linux driver straight from TP-LINK gets you rtl88x2BU v5.3.1_27282.20180419_COEX20180112-5959_beta which compiles and loads fine, but has exactly the same behavior (adapter shows up but perpetually "hardware disabled") as the others. I'm going to have to play around with it a bit and see if I can convince it to work.

cilynx commented 5 years ago

Scratch that -- the adapter is working 100% on Debian Unstable. 

Linux version 4.19.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-12)) #1 SMP Debian 4.19.9-1 (2018-12-16)
rcw@burner:~/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959$ gcc --version
gcc (Debian 8.2.0-13) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rcw@burner:~/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959$

Now I just need to figure out why it doesn't work on Stretch. You said you were having the same symptoms I see on Stretch, right? The adapter is there, but no green LED and no networks?

mentaluproar commented 5 years ago

No. The LED lit up and networks worked fine. The only issue is when using nmtui, it takes longer than normal to activate. I’m running on patched Linux 4.4 for the rock64. It’s on bionic so I don’t think it’s running Debian unstable. I might be able to try it on stretch too. I have some extra boards that I can flash to stretch easy tomorrow.

After family holiday stuff.

That I found out about just this afternoon am expected for at 9 am.

No I’m not bitchy about it.

cilynx commented 5 years ago

...and scratch not working on Stretch. The adapter doesn't seem to like the USB extension cable that I use on my main terminal. Plugging it straight into one of the USB ports on the dock works fine. My best guess is that it can't suck enough power through the extension cable as everything else I plug into that cable works fine.

Enjoy family holiday stuff =)

mentaluproar commented 5 years ago

Holidays over, nuking and starting over on the rock64 project since I lost my place. I cloned this again but the usb id for this weird adapter is still missing from usb_intf.c

cilynx commented 5 years ago

Doesn't https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959/blob/d953d367335e52a5f517fb2a04c4b45d42867eef/os_dep/linux/usb_intf.c#L240 have you covered? If not, what ID are you looking for?

mentaluproar commented 5 years ago

Didn’t work unless I put it in the first group. Let me nuke it and try again. The rock64 does really weird stuff sometimes if power isnt exactly what it wants so I’m wondering if I had it plugged into an insufficient supply last time I tested that issue.

cilynx commented 5 years ago

Any luck? My T4U v3 is working properly on multiple devices at this point.

mentaluproar commented 5 years ago

I've been too busy lately to pick up the project that needs this. It's sort of fallen on the back burner. I can confirm this driver does work, but for whatever reason, I had to do that edit mentioned above. I don't have time to test if it still needs it right now though, sorry.

cilynx commented 5 years ago

No worries -- I know how that goes. I'll close the issue for now just for housekeeping, but feel free to reopen it in the future if it bubbles back up for you.

minusdavid commented 5 years ago

Alrighty -- so the T4U v3 is definitely an RTL8812BU chip. You can see it on the internal photos on the FCC registration site. Adding 2357:0115 to either 8812AU or 8822BU driver makes the thing show up, but it never gets past "hardware disabled". I've played around a bit with rfkill to no avail. I've found a few folks who have other 8812BU powered adapters working with the 8822BU driver, but I'm not finding anyone who has this specific adapter working. The CD that comes with the adapter has a text file saying to look online for the Linux driver. Downloading the T4U v3 Linux driver straight from TP-LINK gets you rtl88x2BU v5.3.1_27282.20180419_COEX20180112-5959_beta which compiles and loads fine, but has exactly the same behavior (adapter shows up but perpetually "hardware disabled") as the others. I'm going to have to play around with it a bit and see if I can convince it to work.

I'm running Debian Stretch with a 4.9.0.8 Kernel and using the 5.3.1 beta driver from https://www.tp-link.com/au/support/download/archer-t4u/#Driver. I can compile it and on the surface it looks like it's working... except the password I put in for the network never works...

minusdavid commented 5 years ago

Tried the steps mentioned at https://askubuntu.com/a/1067500 but still same problem.

Looking at syslog and it says it's the WRONG_KEY which can't be right. So it makes me think that the drivers aren't handling the password correctly.

minusdavid commented 5 years ago

I'm running Debian Stretch with a 4.9.0.8 Kernel and using the 5.3.1 beta driver from https://www.tp-link.com/au/support/download/archer-t4u/#Driver. I can compile it and on the surface it looks like it's working... except the password I put in for the network never works...

It turns out the solution is here: https://wiki.debian.org/WiFi/HowToUse#WiFi_can_scan.2C_but_not_connect_using_NetworkManager_.28Debian_9_Stretch.29

I added the following to /etc/NetworkManager/NetworkManager.conf and did a service NetworkManager restart and all was well afterwards:

[device] wifi.scan-rand-mac-address=no

Polve commented 5 years ago

I've the same problem on Ubuntu 19.04 Disco, I checked the hint by @minusdavid but unfortunately it doesn't help since the setting is already that way :-(

zFlorent commented 5 years ago

Hello,

I edit my post to give following info : A package is available for open suse leak 15.1 for rtl8822bu. And it seems to work fine on x86-64 architecture. 2.1MB/s and still working on next reboot.

I compiled rtl8822bu drivers from jeremyb31 on opensuse 15.1 (Linux version 4.12.14-lp151.28.10-default (geeko@buildhost) (gcc version 7.4.0 (SUSE Linux) ) on a x86-64 PC platform. I had to modify Makefile in order to successfully compile by adding : EXTRA_CFLAGS += -Wno-error=incompatible-pointer-types

My device is a TP-link AC1300 Archer T3U (lsusb -> ID 2357:012d) {USB_DEVICE(0x2357, 0x012D), RTL8822B}, / TP-Link - Archer T3U (AC1300 Mini Wireless MU-MIMO USB Adapter) /

The driver manage to connect to my 2GHz wifi network, but with poor speed (Max 50kB/s). And is not able to use 5GHz network (Configuring the interface -> disconnected).

Any idea why ? I took this adapter because it was supposed to be linux compatible... :-(

I also tried with cilynx version. I had same compilation issue, with same workaround. It worked well, and it was fast (1.5MB/s) compared to JeremyB31 version... But after a reboot, impossible to detect and activate the adapter. I see the adapter with lsusb. I tried to deinstall and reinstall with no further result...

BR, Florent