I have a mt7610u and hope that you will be able to support it in the future.

[687766616e]

i'm using this one: 'TL-WDN5200'~~~~~
and.. I don't know what to say....... just.. thx ^^''

[neheb]

Latest kernel should have support for this.

[ZerBea]

Thank's for reporting this dongle. mt7601u (EEPROM ver:0c and EEPROM ver:0d) is working out of the box, using kernel >= 4.2 (https://wikidevi.com/wiki/Mt7601u):
Supported modes
STA (Station) mode: supported
IBSS (Ad-Hoc) mode: supported
AP (Master) mode: supported
Mesh (802.11s) mode: unknown
P2P mode: unsupported
Monitor mode: supported
Packet injection: supported

$ hcxdumptool -I
wlan interfaces:
aca213117f56 wlp0s20f0u2 (mt7601u)

$ dmesg
[ 570.650435] usb 1-2: new high-speed USB device number 6 using xhci_hcd
[ 570.922334] usb 1-2: New USB device found, idVendor=148f, idProduct=7601, bcdDevice= 0.00
[ 570.922345] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 570.922352] usb 1-2: Product: 802.11 n WLAN
[ 570.922358] usb 1-2: SerialNumber: 1.0
[ 571.703373] usb 1-2: reset high-speed USB device number 6 using xhci_hcd
[ 571.857442] mt7601u 1-2:1.0: ASIC revision: 76010001 MAC revision: 76010500
[ 571.866348] mt7601u 1-2:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
[ 572.274716] mt7601u 1-2:1.0: EEPROM ver:0c fae:00
[ 572.480556] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 572.490570] usbcore: registered new interface driver mt7601u
[ 572.532705] mt7601u 1-2:1.0 wlp0s20f0u2: renamed from wlan0

Some more VENDORs using this chipset:
https://wikidevi.com/wiki/MediaTek_MT7610U

I really like this chipset, build in within several nano USB dongles, like the "ALLNET ALLWA015". I have found no issue on that driver, so far. Packet injection is xtreme fast!

[ZerBea]

mt76 (https://wikidevi.com/wiki/Mt76) should work, too (chipset MT7603E and higher) on kernel >= 4.19:
Supported modes
STA (Station) mode: supported
IBSS (Ad-Hoc) mode: supported
AP (Master) mode: supported
Mesh (802.11s) mode: supported
P2P mode: unsupported
Monitor mode: supported
Packet injection: supported

The implementation of this driver is a big step forward, because several new (AC) devices use it.
Also it seems that monitor mode and packet injection is supported - that is a feature, we didn't see on several drivers running on modern chipsets.

[ZerBea]

Had some sleepless nights since you reported this dongle. mt76 is based on m7601u and should work as expected like here described: #42 (comment)
To run some stress tests on that driver, I ordered a TP-LINK ARCHER T2UH from here
https://www.reichelt.de/wlan-adapter-usb-583-mbit-s-tplink-arct2uh-p148569.html?&trstct=pos_4
and decided to reopen this issue until we will know that the driver is working as expected.
According to this
https://wikidevi.com/wiki/TP-LINK_Archer_T2UH
the dongle should have a MT7610U chipset build in (I hope so, because many VENDORs decided to change the chipset without informing the dealers).

So here we go again.

[687766616e]

ok...😀

[ZerBea]

You can test hcxdumptool using mac80211_hwsim.
mac80211_hwsim is a Linux kernel module that can be used to simulate arbitrary number of IEEE 802.11 radios for mac80211. It can be used to test hcxdumptool:
load module:
$ sudo modprobe mac80211_hwsim

run hcxdumptool to retrieve informations about the interface:
$ hcxdumptool -I
wlan interfaces:
020000000000 wlan0 (mac80211_hwsim)
020000000100 wlan1 (mac80211_hwsim)

bring monitor interface up:
$ sudo sudo ip link set hwsim0 up

run hcxdumptool:
$ sudo hcxdumptool -i wlan0
initialization...

start capturing (stop with ctrl+c)
INTERFACE:...............: wlan0
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: c8aacc9c01ec
MAC ACCESS POINT.........: 580943000000 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 62263
ANONCE...................: 513282ebb604e6e10c450d6c3eaa6428d118b54abeef4672be3ef700052305d5

INFO: cha=11, rx=0, rx(dropped)=0, tx=120, powned=0, err=0

run wireshark on wlan0 or hwsim0 to monitor hcxdumptool output.

read more here:
https://www.kernel.org/doc/readme/Documentation-networking-mac80211_hwsim-README

[687766616e]

how about this one? mt7620
can't... right?... 😅😅😔

[ZerBea]

Maybe both of them, mt7620A and 7620N, working with a (patched) rt2x00 driver.
https://wikidevi.com/wiki/MediaTek_MT7620
But I'm not sure if packet injection works.
There is a discussion on OpenWRT about this chipset:
https://forum.archive.openwrt.org/viewtopic.php?id=51608
https://forum.archive.openwrt.org/viewtopic.php?id=50466

[neheb]

Originally, packet injection crashed mt76. Felix fixed that issue a while back: openwrt/mt76@11e0a12

mt76x0u support came later. I would assume it works fine but still needs to be tested.

[ZerBea]

Received the TP-LINK Archer T2UH, tested the dongle and noticed that the driver doesn't work like expected.

$ uname -r
4.20.0-arch1-1-ARCH

$ lsusb
Bus 001 Device 007: ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter

INTEL system:
$ dmesg
[ 132.682145] usb 1-3: new high-speed USB device number 7 using xhci_hcd
[ 132.838532] usb 1-3: New USB device found, idVendor=148f, idProduct=761a, bcdDevice= 1.00
[ 132.838543] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 132.838550] usb 1-3: Product: WiFi
[ 132.838557] usb 1-3: Manufacturer: MediaTek
[ 132.838563] usb 1-3: SerialNumber: 1.0
[ 133.406147] usb 1-3: reset high-speed USB device number 7 using xhci_hcd
[ 133.557810] mt76x0u 1-3:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 134.589471] mt76x0u 1-3:1.0: EEPROM ver:02 fae:01
[ 134.593977] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 134.594305] usbcore: registered new interface driver mt76x0u
[ 134.627225] mt76x0u 1-3:1.0 wlp0s20f0u3: renamed from wlan0

neither NetworkManager nor iw nor hcxdumptool received a signal from that dongle/driver
$ sudo iw dev wlp0s20f0u3 scan
$

AMD RYZEN 1700 system:
IOMMU crashed after plug-in that dongle:
$ dmesg
[ 32.126605] usb 5-4.1: New USB device found, idVendor=148f, idProduct=761a, bcdDevice= 1.00
[ 32.126610] usb 5-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 32.126613] usb 5-4.1: Product: WiFi
[ 32.126615] usb 5-4.1: Manufacturer: MediaTek
[ 32.126617] usb 5-4.1: SerialNumber: 1.0
[ 32.236956] usb 5-4.1: reset high-speed USB device number 4 using xhci_hcd
[ 32.333111] mt76x0u 5-4.1:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 32.675686] xhci_hcd 0000:27:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000ffb50308 flags=0x0000]
[ 33.676816] mt76x0u 5-4.1:1.0: firmware upload timed out

firmware on all systems is up to date:
$ pacman -Q linux-firmware
linux-firmware 20181218.0f22c85-1

We have to wait until the driver issue is fixed by kernel team.

It seems that driver support for newer WiFi USB dongles is a huge desaster:
https://www.reddit.com/r/linux/comments/9dbd7y/why_are_there_no_5ghz_80211ac_usb_wifi_adapters/

[neheb]

@ZerBea it's more generic to any 11ac chip. All of them have moved to offload functionality to firmware. Probably for lower power in mobile devices.

In any case, I've reported the ryzen compatibility problem upstream.

[ZerBea]

@neheb thanks for reporting it to upstream.
Generally it's a good idea that all of them have moved to offload functionality to firmware. The firmware is included in linux-firmware package and seems to be working. I tried fw 2.4 and 2.6 on the INTEL system.
Some parts of the driver seems to work:
WiFi dongle Archer T2U is detected and firmware is loaded
networking tools (NetworkManger, iw, hcxdumptool) see the interface
$ iw dev
phy#1
Interface wlp0s20f0u3
ifindex 4
wdev 0x100000001
addr f2:cf:ef:eb:49:20
type managed
txpower 20.00 dBm

$ hcxdumptool -I
wlan interfaces:
503eaa92e326 wlp0s20f0u3 (mt76x0u)

driver accepts monitor mode set by iw and hcxdumptool
$ iw dev wlp0s20f0u3 set type monitor
$ iw dev wlp0s20f0u3 info
Interface wlp0s20f0u3
ifindex 5
wdev 0x200000001
addr aa:dd:72:61:8c:12
type monitor
wiphy 2
channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
txpower 20.00 dBm

ioctl commands seems to work on the driver, as we can set supported channels (and test if they are really set).

$ hcxdumptool -i wlp0s20f0u3 -C
initialization...
available channels:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,153,157,161,165
terminated...

Unfortunately the driver doesn't receive and doesn't transmit. I checked this, running several tools.
For example running rcascan function of hcxdumptool:
$ hcxdumptool -i wlp0s20f0u3 --do_rcascan
initialization...
INFO: cha=1, rx=0, rx(dropped)=0, tx=1, err=0, aps=0
in that case tx increases, because it shows the outgoing packets delivered from the socket to the driver while rx doesn't increase.

[ZerBea]

Maybe, the time has come to join bugzilla!

[ZerBea]

Tested also latest available firmware, provided by TP-LINK (MT7610_formal_3.1.0401):
Same results as before on the INTEL system.

MT7610_formal_3.1.0401: 201404011018 (identical with mt7610e from linux firmware)
mt7610u from linux firmware seems to be different: 201322081655

...very confusing

[ZerBea]

Took a look into the kernel source (4.20.1) and noticed that the device ID is allready inside usb.c:

{ USB_DEVICE(0x148f, 0x761a) },	/* TP-Link TL-WDN5200 */

TP-Link TL-WDN5200 is the old name for TP-LINK Archer T2UH, but the device ID (0x148f, 0x761a) is correct.
https://wikidevi.com/wiki/TP-LINK_TL-WDN5200
https://wikidevi.com/wiki/TP-LINK_Archer_T2UH

@huitc can you confirm this ($ lsusb) for your TP-LINK_TL-WDN5200?

[687766616e]

maybe next week ^^''
(cause i need to find it out first.........

[687766616e]

im sorry ^^''

[ZerBea]

No problem. It's possible not a hcxdumptool issue, but a driver issue. I think about it, to report that issue (0x148f, 0x761a no tx/rx) on bugzilla: https://bugzilla.kernel.org/
But first I'll take a look into 5.0-rc1

[ZerBea]

I decided to report this bug on kernel.org, because it seems that it is present in 5.0-rc1, too:
https://bugzilla.kernel.org/show_bug.cgi?id=202241

A workaround on AMD RYZEN systems is to disable IOMMU by kernel boot parameter "iommu=off".

[ZerBea]

Also I reported the second issue on kernel. org:
https://bugzilla.kernel.org/show_bug.cgi?id=202243

Now it's time to wait.

[ZerBea]

Got a reply: https://bugzilla.kernel.org/show_bug.cgi?id=202243#c2
and can confirm that hcxdumptool in combination with TP-LINK Archer T2UH is working on kernel 4.19.15

[ZerBea]

Finally I got the interface working:
https://bugzilla.kernel.org/show_bug.cgi?id=202243#c9
Just compiled the 5.0-rc2 kernel and run some tests. I can confirm that the driver is working, like expected:
NetworkManager scan list - ok
iw scan list - ok
hcxdumptool packet injection - ok

Also I compiled the 5.0-rc2 included driver for 4.20.1 and can confirm that the driver is working, too
NetworkManager scan list - ok
iw scan list - ok
hcxdumptool packet injection - ok

[ZerBea]

I did some tests and noticed that the TP-LINK Archer T2UH received twice more packets than my ALFA AWUS036NH. It's really good, to see this new driver for a really good chipset inside the kernel.

[neheb]

mt76x2 has also been working since 4.17 I believe. Here’s a list: https://wikidevi.com/wiki/Special:Ask?title=Special%3AAsk&q=%5B%5BChip1+model::~MT7612U*%5D%5D&po=%3FInterface%0D%0A%3FForm+factor=FF%0D%0A%3FInterface+connector+type=USB+conn.%0D%0A%3FFCC+ID%0D%0A%3FManuf%0D%0A%3FManuf+product+model=Manuf.+mdl%0D%0A%3FVendor+ID%0D%0A%3FDevice+ID%0D%0A%3FChip1+model%0D%0A%3FSupported+802dot11+protocols=PHY+modes%0D%0A%3FMIMO+config%0D%0A%3FOUI%0D%0A%3FEstimated+year+of+release=Est.+year&eq=yes&p%5Bformat%5D=broadtable&order%5B0%5D=ASC&sort_num=&order_num=ASC&p%5Blimit%5D=500&p%5Boffset%5D=&p%5Blink%5D=all&p%5Bsort%5D=&p%5Bheaders%5D=show&p%5Bmainlabel%5D=&p%5Bintro%5D=&p%5Boutro%5D=&p%5Bsearchlabel%5D=…+further+results&p%5Bdefault%5D=&p%5Bclass%5D=sortable+wikitable+smwtable

For x0u: https://wikidevi.com/wiki/Special:Ask?title=Special%3AAsk&q=%5B%5BChip1+model::~MT7610U*%5D%5D&po=%3FInterface%0D%0A%3FForm+factor=FF%0D%0A%3FInterface+connector+type=USB+conn.%0D%0A%3FFCC+ID%0D%0A%3FManuf%0D%0A%3FManuf+product+model=Manuf.+mdl%0D%0A%3FVendor+ID%0D%0A%3FDevice+ID%0D%0A%3FChip1+model%0D%0A%3FSupported+802dot11+protocols=PHY+modes%0D%0A%3FMIMO+config%0D%0A%3FOUI%0D%0A%3FEstimated+year+of+release=Est.+year&eq=yes&p%5Bformat%5D=broadtable&order%5B0%5D=ASC&sort_num=&order_num=ASC&p%5Blimit%5D=500&p%5Boffset%5D=&p%5Blink%5D=all&p%5Bsort%5D=&p%5Bheaders%5D=show&p%5Bmainlabel%5D=&p%5Bintro%5D=&p%5Boutro%5D=&p%5Bsearchlabel%5D=…+further+results&p%5Bdefault%5D=&p%5Bclass%5D=sortable+wikitable+smwtable

[ZerBea]

@neheb thanks for that info. I have not noticed this device yet - until this issue report. Now I walked through the driver code and noticed many changes from 4.19 up to 5.0.
So, this device is worth taking a closer look and ‎I am pleasantly surprised about the receiving sensitivity. Also 20 dBm tx power is more than enough, especially using a high gain panel antenna or a dish.

[ZerBea]

Now we got the interface working on 4.20.3, too:
https://bugzilla.kernel.org/show_bug.cgi?id=202243#c75
https://bugzilla.kernel.org/show_bug.cgi?id=202243#c76

I think we will see the patches soon, maybe in 4.20.4 or 4.20.5

Please test and close issue if everything's ok

[neheb]

@ZerBea can you test the patches for the IOMMU issue? My Arch Linux system blew up recently after the bash update.

https://marc.info/?l=linux-wireless&m=154755566520069&w=2
https://marc.info/?l=linux-wireless&m=154755566220067&w=2
https://marc.info/?l=linux-wireless&m=154755566320068&w=2
https://marc.info/?l=linux-wireless&m=154755566220066&w=2

[ZerBea]

Hmm, not yet. Doesn't work against 4.20.3 and 5.0-rc2:
got several rejects on all 4 patches like this one here:

$ patch -p1 -i p1.patch
patching file drivers/net/wireless/mediatek/mt76/usb.c
Hunk #2 FAILED at 250.
1 out of 2 hunks FAILED -- saving rejects to file drivers/net/wireless/mediatek/mt76/usb.c.rej

[687766616e]

I think you will talk about its support for Android, but... ^^''

[ZerBea]

No, because I am not interested in Android, Windows or MAC OS. My favorite operating system is Arch Linux (only Arch Linux and no other distribution) and, of course, the Linux kernel. So, if hcxtools or hcxdumptool is working in combination with one of the other operating systems, it is fine, but I don't support it.

[687766616e]

ok... ^^''

[ZerBea]

I don't like proprietary operating systems and I'm tired to wrestle against them or to reverse engineer their code to make things work. Arch Linux give me all I need and that in an extreme fast update cycle.

[687766616e]

~

[687766616e]

tenda u12

$ lsusb
Bus 001 Device 002: ID 2604:0012
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0003

[ZerBea]

I can't recommend a WiFi dongle if:

• the driver is not in kernel source
• the driver doesn't support monitor mode
• the driver doesn't support packet injection

Mostly it takes a long, long time until a third party driver will get a fix.
Some third party drivers support monitor mode (you are able to capture packets), but the don't support full packet injection (hcxdumptool will not work).

BTW:
nexmon is also a third party driver and neither part of the kernel,
https://www.kernel.org/
nor part of Arch Linux
https://archlinuxarm.org/packages
https://www.archlinux.org/

I suggest to deactivate the build in Raspberry WiFi chip by adding
dtoverlay=pi3-disable-wifi
to config.txt
and to buy a working adapter, that supports monitor mode and packet injection by kernel source.

[687766616e]

So is TL-WDN5200 better than this?...😐😭😭😭

[ZerBea]

I don't have a TL-WDN5200.

My favorite devices:
EDIMAX EW-7711UAN
https://www.reichelt.de/wifi-usb-mini-adapter-802-11b-g-n-edi-ew-7711uan-p88491.html?&trstct=pos_0

ALLNET ALLWA0150
https://www.reichelt.de/allnet-wireless-nano-usb-adapter-150-mbit-s-allnet-allwa0150-p149756.html?&trstct=pos_0

TENDA W311U+
Currently unavailable.

LogiLink WL0151 (not revision A!)
Currently unavailable.

Warning:
Some VENDORs change the chipset without providing an information about the change!
Do not trust it, if a revision 1 works, that the revision 2 will use the same chipset and will work in the same manner!!!

[ZerBea]

Just removed the next devices from the "known as working" list:

• USB ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter (ALFA AWUS036H)
• USB ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network

Starting with kernel 5.0 we are running into big driver issues:
$ uname -r
5.0.4-arch1-1-ARCH

hcxdumptool -i wlp3s0f0u1 --enable_status=1
initialization...
start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0f0u1
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: e0cb1d480569
MAC ACCESS POINT.........: 0050c7044a81 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 62228
ANONCE...................: 388bddaf0c9e0b971832d1fb8027d19fc258db564d9cfd12e3b663878c1a9e44

INFO: cha=6, rx=0, rx(dropped)=0, tx=20, powned=0, err=0

BTW:
That is not a hcxdumptool issue. Running Wireshark to capture traffic, the driver is not working, too!!!

[ZerBea]

while this Realtek driver is still(!) working fine running kernel 5.0:

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac PCIe Wireless Network Adapter

$ hcxdumptool -i wlp3s0 -C
initialization...
available channels:
1 / 2412MHz (20 dBm)
2 / 2417MHz (20 dBm)
3 / 2422MHz (20 dBm)
4 / 2427MHz (20 dBm)
5 / 2432MHz (20 dBm)
6 / 2437MHz (20 dBm)
7 / 2442MHz (20 dBm)
8 / 2447MHz (20 dBm)
9 / 2452MHz (20 dBm)
10 / 2457MHz (20 dBm)
11 / 2462MHz (20 dBm)
12 / 2467MHz (20 dBm)
13 / 2472MHz (20 dBm)
36 / 5180MHz (23 dBm)
40 / 5200MHz (23 dBm)
44 / 5220MHz (23 dBm)
48 / 5240MHz (23 dBm)
52 / 5260MHz (20 dBm)
56 / 5280MHz (20 dBm)
60 / 5300MHz (20 dBm)
64 / 5320MHz (20 dBm)
100 / 5500MHz (26 dBm)
104 / 5520MHz (26 dBm)
108 / 5540MHz (26 dBm)
112 / 5560MHz (26 dBm)
116 / 5580MHz (26 dBm)
120 / 5600MHz (26 dBm)
124 / 5620MHz (26 dBm)
128 / 5640MHz (26 dBm)
132 / 5660MHz (26 dBm)
136 / 5680MHz (26 dBm)
140 / 5700MHz (26 dBm)
149 / 5745MHz (13 dBm)
153 / 5765MHz (13 dBm)
157 / 5785MHz (13 dBm)
161 / 5805MHz (13 dBm)
165 / 5825MHz (13 dBm)

$ hcxdumptool -i wlp3s0
initialization...
start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: f0a22527b3ee
MAC ACCESS POINT.........: 00269fcd1b16 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 64977
ANONCE...................: 03fc55ad138e332ade00308e4d6c223fb15c60943bc5cf19743ded29dec3cbe2

INFO: cha=6, rx=152, rx(dropped)=53, tx=20, powned=1, err=0

[ZerBea]

Really bad news, running kernel 5.0:
Tested ALFA AWUS036NH and it looks like the RT3070 set doesn't work any longer:
hcxdumptool -i wlp3s0f0u10
initialization...
start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0f0u10
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: a4a6a9064750
MAC ACCESS POINT.........: 00006c9ebbe5 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 63359
ANONCE...................: b261911b07542056e4d856ccd321c90ec057d0800ae6322dd6d45608d37e2507

INFO: cha=1, rx=0, rx(dropped)=0, tx=10, powned=0, err=0

Wireshark doesn't receive packets, too!

Can somebody confirm this?

[strasharo]

I can test it. Does any distro ship the kernel stock or you're building it from source?

[ZerBea]

That will be fine. Thanks.
Some distros are still on 4.19 LTS, but I think 5.0 is upcoming during the next weeks. Arch is on 5.0.4, while UBUNTU announced 5.0 on 19.04.
I had to remove many "known as working devices" from the list, since I'm running 5.0 on my main machines (Intel and AMD). Arch Arm (Raspberry) is running 4.19.30-2 and here is the world still in order. 4.20 was running fine, too, but I wan't go back to that kernel.
Beside hcxdumptool, I tried tshark / wireshark and noticed similar issues running monitor mode.
Now, I'm hunting for the cause. Perhaps it's no coincidence that so many drivers are broken and we are running into an issue caused by the kernel itself. But I'm not sure about it.
The last test was a double test: ALFA AWUS036NH and TENDA W311U+
Both of them using the same chipset. While the 311U is still working, the 036NH failed.

TENDA W311U+
$ lsusb
ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
$ hcxdumptool -i wlp3s0f0u1
initialization...

start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0f0u1
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: c02250d857d9
MAC ACCESS POINT.........: 00bb3a2ac5d7 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 62381
ANONCE...................: 5765eff8c9812f3eea43bcdb51379e0156d021a0dd229d89a7e6bc87ac270b05

INFO: cha=1, rx=1626, rx(dropped)=328, tx=114, powned=2, err=0

ALFA AWUS036NH:
$ lsusb
ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
$ hcxdumptool -i wlp3s0f0u10
initialization...

start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0f0u10
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: b0ece12cb441
MAC ACCESS POINT.........: 1100aa652b72 (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 63803
ANONCE...................: 1ee5e55ae88c4ee2587714d791a640893da902fb9729d26152c1f0b33ab9a4d7

INFO: cha=1, rx=0, rx(dropped)=0, tx=10, powned=0, err=0

tshark show similar results:
AWUSH036NH
$ tshark -w tst.pcap -i wlp3s0f0u10
Capturing on 'wlp3s0f0u10'

tst.pcap remains empty

W311U+:
$ tshark -w tst.pcap -i wlp3s0f0u1
Capturing on 'wlp3s0f0u1'
155
packet count increased very fast.

[ZerBea]

re-added RTL8187. Chipset is working. Only RT3070 is affected.

[ZerBea]

Also I added a new option (--silent) to hcxdumptool.
Silent disable all active parts, so that no packet will be transmitted. Now hcxdumptool is acting like a passive dumper. I noticed that some of the drivers will not crash, if we doesn't try to inject packets.

[ZerBea]

With the latest update, I was able to fix many issues and re-added some chipset to the "known as working list". Unfortunately the RT3070 chipset ALFA AWUS036NH doesn't work with the latest fixes.

[ZerBea]

By latest commit, TP-LINK Archer T2UH is working fine, too, running kernel 5.1.
ALFA AWUS036NH still failed.

[ZerBea]

The issue is related to usb/xhci drivers (>= kernel 4.20) and reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=202541

[parkerlreed]

Anybody have mt7610u working on 5.1+? Only 7601 is in the kernel.

[parkerlreed]

Ok mt76x0u works. I had to manually probe mt7-usb since my USB ID isnt in the list.

[ZerBea]

Please report the missing USB ID here:
https://github.com/openwrt/mt76/issues
and also here:
https://bugzilla.kernel.org/

[parkerlreed]

Turns out something was just weird with my setup. After a fresh reboot everything loaded as epected. I hit some errors once but I think the adapter is failing physically on the data connection.

[kimocoder]

@ZerBea I just got interested in the mt76 driver myself, as I got a special device that runs it.. https://openwrt.org/toh/hwdata/alfa_network/alfa_network_awusfree1

[ZerBea]

I'm running several mt76 devices. The Mediatek chipset is really, really good. All attack modes running out of the box with high performance. All driver issues are fixed and everything is working fine in combination with hcxdumptool.
Right now this are my favorite devices mt7601:
https://github.com/ZerBea/hcxdumptool/wiki/Penetration-testing-system-1
(Sempre w150-1 is similar to the ALLNET)
https://github.com/ZerBea/hcxdumptool/wiki/Penetration-testing-system-2

The TP-Link Archer T2UH (mt7610) is nice, too:
$ sudo hcxdumptool -i wlan0 --check_driver
driver tests passed - all required ioctl() system calls are supported by driver

$ sudo hcxdumptool -i wlan0 --do_rcascan
initialization...
INFO: cha=1, rx=261, rx(dropped)=0, tx=37, err=0, aps=9 (5 in range)

Interface wlan0
ifindex 4
wdev 0x100000001
addr 12:9f:e8:83:cd:02
type monitor
wiphy 1
channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
txpower 14.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0

[q4a]

Hi all. I have TP-LINK TL-WN727N usb wifi, which has MT7601U chip (148f:7601).
I'm using Ubuntu 19.10 with driver mt7601u from kernel:

$ uname -a
Linux hi 5.3.0-18-generic #19-Ubuntu SMP Tue Oct 8 20:14:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I build hcxdumptool 6.0.1 release and I getting no one BSSID with do_rcascan:

$ sudo hcxdumptool -i tpwlan --check_driver
initialization...
starting driver test...
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ sudo hcxdumptool -i tpwlan --do_rcascan
 BSSID         CH COUNT   HIT ESSID                 [21:02:53]
---------------------------------------------------------------

terminating...

Can somebody help me?

UPD: I found a lot of errors in dmesg:

[ 3248.441845] mt7601u 1-3.2:1.0: Error: send MCU cmd failed:-110
[ 3248.693498] mt7601u 1-3.2:1.0: Error: MCU response pre-completed!
[ 3249.209893] mt7601u 1-3.2:1.0: Error: send MCU cmd failed:-110
[ 3249.461441] mt7601u 1-3.2:1.0: Error: MCU response pre-completed!

I will try to update kernel and may be apply some patches from:
kuba-moo/mt7601u#64 (comment)

UPD2: Updating kernel helps me:

$ uname -a
Linux hi 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[ZerBea]

tpwlan is an unusual name for an interface!

$ hcxdumptool -I
wlan interfaces:
00e62d05131a wlp39s0f3u3u1u2 (mt7601u)

$ lsusb
Bus 005 Device 004: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter

$ lsmod | grep mac802
mac80211 1007616 1 mt7601u
libarc4 16384 1 mac80211
cfg80211 860160 2 mt7601u,mac80211

$ dmesg
[ 960.168737] usb 5-3.1.2: Product: 802.11 n WLAN
[ 960.168740] usb 5-3.1.2: Manufacturer: MediaTek
[ 960.168741] usb 5-3.1.2: SerialNumber: 1.0
[ 960.437249] usb 5-3.1.2: reset high-speed USB device number 4 using xhci_hcd
[ 960.456710] mt7601u 5-3.1.2:1.0: ASIC revision: 76010001 MAC revision: 76010500
[ 960.459492] mt7601u 5-3.1.2:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146____
[ 960.887669] mt7601u 5-3.1.2:1.0: EEPROM ver:0d fae:00
[ 961.119429] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 961.119879] usbcore: registered new interface driver mt7601u
[ 961.131749] mt7601u 5-3.1.2:1.0 wlp39s0f3u3u1u2: renamed from wlan0

MT76 chipset is working fine (out of the box) on stock kernel 4.19 up to 5.5. There is no need to install a custom driver.
Do you use a custom driver or the kernel build in driver?