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

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

Closed
huitc opened this issue Jan 7, 2019 · 98 comments

Comments

Projects
None yet
6 participants
@huitc
Copy link

commented Jan 7, 2019

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

@neheb

This comment has been minimized.

Copy link

commented Jan 7, 2019

Latest kernel should have support for this.

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 7, 2019

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 ZerBea closed this Jan 7, 2019

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 7, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 8, 2019

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.

@ZerBea ZerBea reopened this Jan 8, 2019

@huitc

This comment has been minimized.

Copy link
Author

commented Jan 8, 2019

ok...😀

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 8, 2019

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

@huitc

This comment has been minimized.

Copy link
Author

commented Jan 9, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 9, 2019

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

This comment has been minimized.

Copy link

commented Jan 9, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 10, 2019

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

This comment has been minimized.

Copy link

commented Jan 10, 2019

@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

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

@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

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

Maybe, the time has come to join bugzilla!

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

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?

@huitc

This comment has been minimized.

Copy link
Author

commented Jan 11, 2019

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

@huitc

This comment has been minimized.

Copy link
Author

commented Jan 11, 2019

im sorry ^^''

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 12, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 12, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 15, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 15, 2019

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

This comment has been minimized.

Copy link

commented Jan 15, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 15, 2019

@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

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2019

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

This comment has been minimized.

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 9, 2019

Didn't tested this adapter, yet. But you can find out if the adapter is able to set monitor mode:
Just run this commands on your adapter (where wlan0 is your adapter):
$ ip link set wlan0 down
$ iw dev wlan0 set type monitor
$ ip link set wlan0 up
$ iw dev

You can find it out Qualcomm Atheros AR9485 Wireless Network Adapter

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 10, 2019

I think we can close this issue here, because the hcxdumptool is working (more or less) running this driver. You can watch the progress on fixing the remaining driver issues here:
openwrt/mt76#216

@ZerBea ZerBea closed this Mar 10, 2019

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 16, 2019

I just ordered this on Taobao: tenda u12, and I saw that you already support this chip: RTL8812AU, but I am not sure if it applies to this dongle, BUT (again) I'll test it after I received the package 😀

https://wikidevi.com/wiki/Tenda_U12

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2019

Do not upgrade to kernel 5.0, because the driver isn't working on this kernel any longer running hcxdumptool
It compiles fine (only one small warning).
We can retrieve the channel list and tx power:
$ sudo hcxdumptool -i wlp3s0f0u1 -C
initialization...
available channels:
1 / 2412MHz (18 dBm)
2 / 2417MHz (18 dBm)
3 / 2422MHz (18 dBm)
4 / 2427MHz (18 dBm)
5 / 2432MHz (18 dBm)
6 / 2437MHz (18 dBm)
7 / 2442MHz (18 dBm)
8 / 2447MHz (18 dBm)
9 / 2452MHz (18 dBm)
10 / 2457MHz (18 dBm)
11 / 2462MHz (18 dBm)
12 / 2467MHz (18 dBm)
13 / 2472MHz (18 dBm)
14 / 2484MHz (18 dBm)
36 / 5180MHz (18 dBm)
40 / 5200MHz (18 dBm)
44 / 5220MHz (18 dBm)
48 / 5240MHz (18 dBm)
52 / 5260MHz (18 dBm)
56 / 5280MHz (18 dBm)
60 / 5300MHz (18 dBm)
64 / 5320MHz (18 dBm)
100 / 5500MHz (18 dBm)
104 / 5520MHz (18 dBm)
108 / 5540MHz (18 dBm)
112 / 5560MHz (18 dBm)
116 / 5580MHz (18 dBm)
120 / 5600MHz (18 dBm)
124 / 5620MHz (18 dBm)
128 / 5640MHz (18 dBm)
132 / 5660MHz (18 dBm)
136 / 5680MHz (18 dBm)
140 / 5700MHz (18 dBm)
144 / 5720MHz (18 dBm)
149 / 5745MHz (18 dBm)
153 / 5765MHz (18 dBm)
157 / 5785MHz (18 dBm)
161 / 5805MHz (18 dBm)
165 / 5825MHz (18 dBm)
169 / 5845MHz (18 dBm)
173 / 5865MHz (18 dBm)

But than it will crash:
$ hcxdumptool -i wlp3s0f0u1 --enable_status=1
initialization...
start capturing (stop with ctrl+c)
INTERFACE................: wlp3s0f0u1
ERRORMAX.................: 100 errors
FILTERLIST...............: 0 entries
MAC CLIENT...............: b0febdb30d78
MAC ACCESS POINT.........: 544e4585957f (incremented on every new client)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 61451
ANONCE...................: 7f34b17ce8dcd85c287ca7bc39e55d524a490c997243a513e94f0a2eec29d06c

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

and we will receive no packets!

I decided to remove the driver from the list of working devices and make an issue report here:
aircrack-ng/rtl8812au#299

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 22, 2019

How is the progress now?😅😅

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 22, 2019

Working on actual kernel 4.19, 4.20, 5.0
Not working on 5.1 and kernel < 4.19
You can follow progress here:
openwrt/mt76#216

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 23, 2019

what do you think about this:
https://github.com/chrisk44/Hijacker

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 23, 2019

I don't use graphical user interfaces. So I can't say anything about them.
But from what I read: You need a driver which support monitor mode and packet injection and you need tools to perform the penetration test.

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 23, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 23, 2019

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.

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 23, 2019

ok... ^^''

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 23, 2019

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.

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

~

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

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.

@huitc

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 30, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Mar 30, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 30, 2019

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

This comment has been minimized.

Copy link
Owner

commented Mar 30, 2019

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

@ZerBea

This comment has been minimized.

Copy link
Owner

commented Apr 5, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.