search

ZerBea / hcxdumptool

Small tool to capture packets from wlan devices.
MIT License
1.83k stars 395 forks source link

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

Closed 687766616e closed 5 years ago

687766616e commented 5 years ago

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

neheb commented 5 years ago

Latest kernel should have support for this.

ZerBea commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Had some sleepless nights since you reported this dongle. mt76 is based on m7601u and should work as expected like here described: https://github.com/ZerBea/hcxdumptool/issues/42#issuecomment-451873973 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 commented 5 years ago

ok...😀

ZerBea commented 5 years ago

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 commented 5 years ago

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

ZerBea commented 5 years ago

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 commented 5 years ago

Originally, packet injection crashed mt76. Felix fixed that issue a while back: https://github.com/openwrt/mt76/commit/11e0a12ce44940be55ed43f5e1638e532520255b

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

ZerBea commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

Maybe, the time has come to join bugzilla!

ZerBea commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

687766616e commented 5 years ago

im sorry ^^''

ZerBea commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

neheb commented 5 years ago

Yeah I had to rebase them. Probably enough fuzz.

ZerBea commented 5 years ago

But I expect that 4.20.4 (or 4.20.5) will fix all. 4.20.3 isn't fixed. Received that kernel yesterday during Arch update.

ZerBea commented 5 years ago

The good news: From 4.20.4 on, we have a hcxdumptool proved driver within the kernel.

ZerBea commented 5 years ago

So, according to usb.c ((mt76x0)), this devices should work (including the TP-LINK Archer T2UH = TP-Link TL-WDN5200): { USB_DEVICE(0x148F, 0x7610) }, / MT7610U / { USB_DEVICE(0x13B1, 0x003E) }, / Linksys AE6000 / { USB_DEVICE(0x0E8D, 0x7610) }, / Sabrent NTWLAC / { USB_DEVICE(0x7392, 0xa711) }, / Edimax 7711mac / { USB_DEVICE(0x7392, 0xb711) }, / Edimax / Elecom / { USB_DEVICE(0x148f, 0x761a) }, / TP-Link TL-WDN5200 / { USB_DEVICE(0x148f, 0x760a) }, / TP-Link unknown / { USB_DEVICE(0x0b05, 0x17d1) }, / Asus USB-AC51 / { USB_DEVICE(0x0b05, 0x17db) }, / Asus USB-AC50 / { USB_DEVICE(0x0df6, 0x0075) }, / Sitecom WLA-3100 / { USB_DEVICE(0x2019, 0xab31) }, / Planex GW-450D / { USB_DEVICE(0x2001, 0x3d02) }, / D-LINK DWA-171 rev B1 / { USB_DEVICE(0x0586, 0x3425) }, / Zyxel NWD6505 / { USB_DEVICE(0x07b8, 0x7610) }, / AboCom AU7212 / { USB_DEVICE(0x04bb, 0x0951) }, / I-O DATA WN-AC433UK / { USB_DEVICE(0x057c, 0x8502) }, / AVM FRITZ!WLAN USB Stick AC 430 / { USB_DEVICE(0x293c, 0x5702) }, / Comcast Xfinity KXW02AAA / { USB_DEVICE(0x20f4, 0x806b) }, / TRENDnet TEW-806UBH / { USB_DEVICE(0x7392, 0xc711) }, / Devolo Wifi ac Stick / { USB_DEVICE(0x0df6, 0x0079) }, / Sitecom Europe B.V. ac Stick / { USB_DEVICE(0x2357, 0x0105), .driver_info = 1, }, / TP-LINK Archer T1U / { USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7630, 0xff, 0x2, 0xff)}, / MT7630U / { USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7650, 0xff, 0x2, 0xff)}, / MT7650U /

and that ones (mt76x2) should work, too: { USB_DEVICE(0x0e8d, 0x7612) }, / Alfa AWUS036ACM / { USB_DEVICE(0x0b05, 0x1833) }, / Asus USB-AC54 / { USB_DEVICE(0x0b05, 0x17eb) }, / Asus USB-AC55 / { USB_DEVICE(0x0b05, 0x180b) }, / Asus USB-N53 B1 / { USB_DEVICE(0x0e8d, 0x7612) }, / Aukey USB-AC1200 / { USB_DEVICE(0x057c, 0x8503) }, / Avm FRITZ!WLAN AC860 / { USB_DEVICE(0x7392, 0xb711) }, / Edimax EW 7722 UAC / { USB_DEVICE(0x0846, 0x9053) }, / Netgear A6210 / { USB_DEVICE(0x045e, 0x02e6) }, / XBox One Wireless Adapter /

We have to test it.....

neheb commented 5 years ago

Lorenzo asked me to test it, but I will be unable for a few days as I don’t have enough time to rebuild my setup.

Oh well. I guess iommu=off is good enough.

ZerBea commented 5 years ago

Right now we are in the situation, that several parts of the code are new aligned and/or moved (mt76x0 and 76x2) to simplify code. That makes it very hard to run tools like diff and patch over them. Additional to that, we have a firmware change (mt7610e.bin / mt7610u.bin). And, AMD I/O Virtualization Technology (IOMMU) Specification is really hard core to understand: https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf

neheb commented 5 years ago

I don’t think this was a regression. I think it was there since day 1.

ZerBea commented 5 years ago

I agree and I wonder, why nobody reported that issue. Well, let's wait for the first patches on 4.20.x and/or 5.0-rcx. BTW: Running some more tests on the Archer and noticed that the newer firmware has many improvements. Also, the driver from 5.0-rc2 works fine.

ZerBea commented 5 years ago

I decided to add this device to documentation (README.md and changelog), because it works on every kernel version >= 4.19 (4.20 with manual intervention until kernel issues get a final fix).

ZerBea commented 5 years ago

Bought another cheep device mt7601u and noticed that the VENDOR changed EEPROM version from 0c to 0d: https://www.reichelt.de/wlan-adapter-usb-150-mbit-s-allnet-allwa0150-p149756.html?&trstct=pos_0 So I extended the issue report on bugzilla.kernel.org, because this devices are working fine, too: https://bugzilla.kernel.org/show_bug.cgi?id=202243#c77

ZerBea commented 5 years ago

Now reported the issue here, too: https://github.com/openwrt/mt76/issues/216#issuecomment-457077825

ZerBea commented 5 years ago

Bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=202243 is closed, because the driver is working on 4.20.

The tx power issue is discussed here: https://github.com/openwrt/mt76/issues/216

neheb commented 5 years ago

https://patchwork.kernel.org/patch/10782801/

ZerBea commented 5 years ago

@neheb that are some good news. Thanks for sharing this link.

ZerBea commented 5 years ago

It looks like the tx power patch didn't make it into the 5.0-rc4: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v5.0-rc4&id2=v5.0-rc3&dt=2 (and Arch Linux Arm is still on 4.14.94 - we wait for 4.19, here)

neheb commented 5 years ago

No the patch only recently got posted. First it has to get into linux-next and after get backported.

ZerBea commented 5 years ago

Ok, will check linux-next from time to time.

ZerBea commented 5 years ago

Ordered some more Mediatek devices to have some playground: mt7610u: ASUS USB-AC51 TPLINK Archer T2UH (it's good to have a second one)

mt7601: EDIMAX EW-7711UAN (not sure about the chipset, here: V1 RT3070 or V2 MT7601U - the dealer doesn't know it) ALLNET ALLWA0150 (it's good to have a second one)

ZerBea commented 5 years ago

Just received official Arch Linux kernel update (4.20.6-arch1-1-ARCH) via package management system. TP-LINK Archer T2UH is working like expected. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=v4.20.6&id2=v4.20.5&dt=2 Unfortunately, the iommu issue isn't fixed yet. The same applies for the driver included in kernel 5.0.

ZerBea commented 5 years ago

mt7601u eeprom version 0d is also on its way: https://patchwork.kernel.org/patch/10775455/ So this devices will work out of the box running hcxdumptool: EDIMAX EW-7711UAN v2 ALLNET ALL-WA0150N / ALL0235NANO

Here are the values of ASUS USB-AC51: https://github.com/openwrt/mt76/issues/216#issuecomment-459721380 Like the Archer T2UH too, this device isn't working like expected running wireless-drivers-next.

687766616e commented 5 years ago

I can't find it.... sorry t.t but you have already tested it, so... ^^'' sorry! maybe next time then~~

ZerBea commented 5 years ago

No problem. W've tested 2 devices from the device table (mt76x0 - usb.c) and we can assume that hcxdumptool is working fine if the driver is fixed. Also we can assume that all other devices, listened in the the device tables (mt76x0 and mt76x2) will work, too. The same applies tor the mt7601 devices from this device table (mt7601u - usb.c) { USB_DEVICE(0x0b05, 0x17d3) }, { USB_DEVICE(0x0e8d, 0x760a) }, { USB_DEVICE(0x0e8d, 0x760b) }, { USB_DEVICE(0x13d3, 0x3431) }, { USB_DEVICE(0x13d3, 0x3434) }, { USB_DEVICE(0x148f, 0x7601) }, { USB_DEVICE(0x148f, 0x760a) }, { USB_DEVICE(0x148f, 0x760b) }, { USB_DEVICE(0x148f, 0x760c) }, { USB_DEVICE(0x148f, 0x760d) }, { USB_DEVICE(0x2001, 0x3d04) }, { USB_DEVICE(0x2717, 0x4106) }, { USB_DEVICE(0x2955, 0x0001) }, { USB_DEVICE(0x2955, 0x1001) }, { USB_DEVICE(0x2a5f, 0x1000) }, { USB_DEVICE(0x7392, 0x7710) },

$ lsusb confirmed: EDIMAX EW-7711UAN v2 ID 7392:7710 Edimax Technology Co., Ltd

confirmed: ALLNET ALL-WA0150N / ALLNET ALL0235NANO 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter

So, if the driver support monitor mode and packet injection and the device is in the device table, hcxdumptool should work

You can verify this in 3 steps (example TP-LINK Archer T2UH):

1) get chipset information from wikidevi https://wikidevi.com/wiki/TP-LINK_Archer_T2UH build in chipset: WI1 chip1: MediaTek MT7610U take care about different versions of the device v1, v2, ..., vx - the can use different chipsets

2) get informations about the supported modes: https://wikidevi.com/wiki/Mt76 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

If you encountered an issue related to the Linux kernel, you can report it here: https://bugzilla.kernel.org If the issue is related to the driver, report it here: https://github.com/openwrt/mt76