mt7610u: Active frame injection not working

[neilalexander]

mt76 driver was built from commit 2a0edbb .

Card is a TP-LINK ARCHER T1U connected via USB, which is a MT7610U:

Bus 001 Device 002: ID 2357:0105 TP-Link Archer T1U 802.11a/n/ac Wireless Adapter [MediaTek MT7610U]

The mt76 driver reports active frame injection (as Device supports active monitor (which will ACK incoming frames) is available.

Attempts to use active frame injection in monitor mode using Owl seem to fail (as per issue seemoo-lab/owl#10).

Using monitor mode on another host confirms that no TX frames are transmitted whatsoever from the host trying to use active frame injection, even though monitor mode to RX frames from other devices seems to be working normally.

Card reports the following capabilities:

Wiphy phy0
    max # scan SSIDs: 4
    max scan IEs length: 2247 bytes
    max # sched scan SSIDs: 0
    max # match sets: 0
    max # scan plans: 1
    max scan plan interval: -1
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports RSN-IBSS.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
        * CCMP-256 (00-0f-ac:10)
        * GCMP-128 (00-0f-ac:8)
        * GCMP-256 (00-0f-ac:9)
        * CMAC (00-0f-ac:6)
        * CMAC-256 (00-0f-ac:13)
        * GMAC-128 (00-0f-ac:11)
        * GMAC-256 (00-0f-ac:12)
    Available Antennas: TX 0x1 RX 0x1
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * AP/VLAN
         * monitor
         * mesh point
    Band 2:
        Capabilities: 0x17e
            HT20/HT40
            SM Power Save disabled
            RX Greenfield
            RX HT20 SGI
            RX HT40 SGI
            RX STBC 1-stream
            Max AMSDU length: 3839 bytes
            No DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 4 usec (0x05)
        HT TX/RX MCS rate indexes supported: 0-7
        VHT Capabilities (0x31800120):
            Max MPDU length: 3895
            Supported Channel Width: neither 160 nor 80+80
            short GI (80 MHz)
            RX antenna pattern consistency
            TX antenna pattern consistency
        VHT RX MCS set:
            1 streams: MCS 0-7
            2 streams: not supported
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT RX highest supported: 0 Mbps
        VHT TX MCS set:
            1 streams: MCS 0-7
            2 streams: not supported
            3 streams: not supported
            4 streams: not supported
            5 streams: not supported
            6 streams: not supported
            7 streams: not supported
            8 streams: not supported
        VHT TX highest supported: 0 Mbps
        Bitrates (non-HT):
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 5180 MHz [36] (16.0 dBm) (no IR)
            * 5200 MHz [40] (16.0 dBm) (no IR)
            * 5220 MHz [44] (16.0 dBm) (no IR)
            * 5240 MHz [48] (16.0 dBm) (no IR)
            * 5260 MHz [52] (16.0 dBm) (no IR, radar detection)
            * 5280 MHz [56] (16.0 dBm) (no IR, radar detection)
            * 5300 MHz [60] (16.0 dBm) (no IR, radar detection)
            * 5320 MHz [64] (16.0 dBm) (no IR, radar detection)
            * 5500 MHz [100] (16.0 dBm) (no IR, radar detection)
            * 5520 MHz [104] (16.0 dBm) (no IR, radar detection)
            * 5540 MHz [108] (16.0 dBm) (no IR, radar detection)
            * 5560 MHz [112] (16.0 dBm) (no IR, radar detection)
            * 5580 MHz [116] (16.0 dBm) (no IR, radar detection)
            * 5600 MHz [120] (16.0 dBm) (no IR, radar detection)
            * 5620 MHz [124] (16.0 dBm) (no IR, radar detection)
            * 5640 MHz [128] (16.0 dBm) (no IR, radar detection)
            * 5660 MHz [132] (16.0 dBm) (no IR, radar detection)
            * 5680 MHz [136] (16.0 dBm) (no IR, radar detection)
            * 5700 MHz [140] (16.0 dBm) (no IR, radar detection)
            * 5745 MHz [149] (16.0 dBm) (no IR)
            * 5765 MHz [153] (16.0 dBm) (no IR)
            * 5785 MHz [157] (16.0 dBm) (no IR)
            * 5805 MHz [161] (16.0 dBm) (no IR)
            * 5825 MHz [165] (16.0 dBm) (no IR)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * new_station
         * new_mpath
         * set_mesh_config
         * set_bss
         * authenticate
         * associate
         * deauthenticate
         * disassociate
         * join_ibss
         * join_mesh
         * set_tx_bitrate_mask
         * frame
         * frame_wait_cancel
         * set_wiphy_netns
         * set_channel
         * set_wds_peer
         * probe_client
         * set_noack_map
         * register_beacons
         * start_p2p_device
         * set_mcast_rate
         * connect
         * disconnect
         * set_qos_map
         * set_multicast_to_unicast
    Supported TX frame types:
         * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * IBSS: 0x40 0xb0 0xc0 0xd0
         * managed: 0x40 0xd0
         * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * mesh point: 0xb0 0xc0 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
         * AP/VLAN
         * monitor
    valid interface combinations:
         * #{ IBSS } <= 1, #{ managed, AP, mesh point } <= 2,
           total <= 2, #channels <= 1, STA/AP BI must match
    HT Capability overrides:
         * MCS: ff ff ff ff ff ff ff ff ff ff
         * maximum A-MSDU length
         * supported channel width
         * short GI for 40 MHz
         * max A-MPDU length exponent
         * min MPDU start spacing
    Device supports TX status socket option.
    Device supports HT-IBSS.
    Device supports SAE with AUTHENTICATE command
    Device supports low priority scan.
    Device supports scan flush.
    Device supports AP scan.
    Device supports per-vif TX power setting
    Driver supports full state transitions for AP/GO clients
    Driver supports a userspace MPM
    Device supports active monitor (which will ACK incoming frames)
    Device supports configuring vdev MAC-addr on create.
    Supported extended features:
        * [ VHT_IBSS ]: VHT-IBSS
        * [ RRM ]: RRM
        * [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
        * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
        * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
        * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs

Following drivers are loaded:

mt76x0u                20480  0
mt76x0_common          49152  1 mt76x0u
mt76x02_usb            20480  1 mt76x0u
mt76_usb               36864  2 mt76x02_usb,mt76x0u
mt76x02_lib            81920  3 mt76x02_usb,mt76x0_common,mt76x0u
mt76                   57344  5 mt76_usb,mt76x02_lib,mt76x02_usb,mt76x0_common,mt76x0u
mac80211              999424  6 mt76,mt76_usb,mt76x02_lib,mt76x02_usb,mt76x0_common,mt76x0u
cfg80211              856064  4 mt76,mt76x02_lib,mac80211,mt76x02_usb

[sgruszka]

I believe frame injection is supported and working as it was reported that the driver works with hcxdumptool. However there where some problems with radiotap frame format. Hcxdumptool format worked on older kernels, but stopped working more recent kernels . See those hcxdumptool commits and https://www.kernel.org/doc/Documentation/networking/mac80211-injection.txt

commit 4b58011ad4dc337273ff6a79a1d2436f50ff4c3a Author: ZeroBeat ZeroBeat@gmx.de Date: Tue Apr 2 10:39:52 2019 +0200

another radiotap change

commit c38cba1dbb22180767f0e24ff29e70a94bf6b9a5 Author: ZeroBeat ZeroBeat@gmx.de Date: Tue Apr 2 10:33:21 2019 +0200

changed radiotap header, again - see changelog

commit c34058b21e9c075c8ab55e71c1700c823f78ffe8 Author: ZeroBeat ZeroBeat@gmx.de Date: Mon Apr 1 17:15:18 2019 +0200

modified tx radiotap header

[LorenzoBianconi]

I believe frame injection is supported and working as it was reported that the driver works with hcxdumptool. However there where some problems with radiotap frame format. Hcxdumptool format worked on older kernels, but stopped working more recent kernels . See those hcxdumptool commits and https://www.kernel.org/doc/Documentation/networking/mac80211-injection.txt

commit 4b58011ad4dc337273ff6a79a1d2436f50ff4c3a Author: ZeroBeat ZeroBeat@gmx.de Date: Tue Apr 2 10:39:52 2019 +0200

another radiotap change

commit c38cba1dbb22180767f0e24ff29e70a94bf6b9a5 Author: ZeroBeat ZeroBeat@gmx.de Date: Tue Apr 2 10:33:21 2019 +0200

changed radiotap header, again - see changelog

commit c34058b21e9c075c8ab55e71c1700c823f78ffe8 Author: ZeroBeat ZeroBeat@gmx.de Date: Mon Apr 1 17:15:18 2019 +0200

modified tx radiotap header

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/310?email_source=notifications&email_token=AAOA2CITGIMQRI5APDOQUHLQHEEKFA5CNFSM4ISLNEN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ROTXI#issuecomment-526576093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOA2CPHE7KLTZTGD7LADBDQHEEKFANCNFSM4ISLNENQ .

I tested mt76x0u with aircrack-ng and it was working fine

Lorenzo

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[neilalexander]

I believe frame injection is supported and working as it was reported that the driver works with hcxdumptool. However there where some problems with radiotap frame format. Hcxdumptool format worked on older kernels, but stopped working more recent kernels

I am using a 5.2 kernel if that is useful to know?

Linux wireless 5.2.10-arch1-1-ARCH #1 SMP PREEMPT Sun Aug 25 18:01:31 UTC 2019 x86_64 GNU/Linux

[sgruszka]

I would check it things work on some older kernel i.e. 4.20 . Also if changing the band from 5GHz to 2.4GHz make difference.

[neilalexander]

Downgraded to kernel 4.20.1 and the situation is the same. No difference between 2.4GHz and 5GHz bands.

[neilalexander]

Some other details from dmesg when connecting the adapter:

[ 3218.726692] usb 1-1: new high-speed USB device number 4 using ehci-pci
[ 3219.296100] usb 1-1: New USB device found, idVendor=2357, idProduct=0105, bcdDevice= 1.00
[ 3219.296119] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3219.296131] usb 1-1: Product: WiFi
[ 3219.296141] usb 1-1: Manufacturer: MediaTek
[ 3219.296150] usb 1-1: SerialNumber: 1.0
[ 3219.843368] usb 1-1: reset high-speed USB device number 4 using ehci-pci
[ 3220.442629] mt76x0u 1-1:1.0: ASIC revision: 76100002 MAC revision: 76502000
[ 3221.842912] mt76x0u 1-1:1.0: EEPROM ver:02 fae:01
[ 3221.967528] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'

... which led me to wonder whether the firmware has something to do with this? Is there a specific firmware .bin that I should be using?

The md5sums for the firmware that I have are below:

b9539ae93957792fb98c62cb96e6f4a8  /lib/firmware/mediatek/mt7610e.bin
9a047587617c9c8732b9c546fb4a0152  /lib/firmware/mediatek/mt7610u.bin

... and they came from Arch somewhere I think. The mt7610e.bin is the same md5sum as the one in the mt76 repository, but there is no mt7610u.bin in the repository to compare against.

Is there anything else I can try?

@LorenzoBianconi Is this the same mt7610u.bin that you had locally when you tested with aircrack-ng?

[sgruszka]

Are there some easy steps to reproduce on two linux hosts (one running owl and second wireshark for example )?

Firmware should make no difference, but you can try to use mt7610u.bin , just by removing mt7610e.bin from /lib/firmware/mediatek/ and re-plug the device.

[neilalexander]

Firmware should make no difference, but you can try to use mt7610u.bin , just by removing mt7610e.bin from /lib/firmware/mediatek/ and re-plug the device.

Gave this a go and sadly no difference.

Are there some easy steps to reproduce on two linux hosts (one running owl and second wireshark for example )?

Yes - that is pretty much exactly what I did to test.

To build Owl on a Linux machine I followed the instructions at https://github.com/seemoo-lab/owl - in my case I was using the Arch package. The code has relatively few dependencies though to build from scratch.

I then started Owl on one machine:

owl -i wlan0 -c 44 -v

... which creates an awdl0 virtual adapter and puts wlan0 into monitor mode.

Although having Owl running should ordinarily should be enough to see some AWDL election/synchronisation traffic on channel 44, you can also push some extra traffic over the new AWDL interface for good measure:

ping6 ff02::1%awdl0

I then watched channel 44 from a nearby Mac using Wireshark in monitor mode.

Although Owl on the first device reports being able to "hear" other nearby AWDL hosts (suggesting monitor mode at least works), and I could see traffic on the channel from other hosts in Wireshark on the second device, there was absolutely no traffic originating from the address of the TP-LINK card attached to the Linux host on the air.

[sgruszka]

Running 'owl -i wlan0 -c 44 -v' seems to work for me . I can see lot's of ACTION frames in monitor mode on second system.

[sgruszka]

[sgruszka]

I tested on kernel 5.3-rc7 using driver shipped with that kernel and owl updated to

commit d16adeca558eb6decaeb2ca8208910aaa8a99020 (HEAD -> master, origin/master, origin/HEAD) Author: Milan Stute mstute@seemoo.tu-darmstadt.de Date: Fri Aug 30 15:17:52 2019 +0200

Remove unused flag in TX radiotap header and use lower rate

[neilalexander]

Thanks for taking the time to test, I'll try using kernel 5.3rc7 as well and see if I can recreate your conditions. I'm really not sure where else to look or what else to try apart from that.

[sgruszka]

This issue could be also device specific, I tested on: Bus 001 Device 002: ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter

[neilalexander]

Yes, I'm starting to think so - I am using a T1U Nano to test. Is your T2U a Nano or a Mini factor? (T2Us are hardly expensive so I may just order one...)

[sgruszka]

I tested on this one. But I have also a T1U device and will retest on it, but currently I have no access to it.

[sgruszka]

I finally get this tested on T1U. It works for me (mean I can receive owl frames in monitor mode on remote system, not checked if owl link works).

Device is nano adapter showed in lsusb as: Bus 001 Device 007: ID 2357:0105 TP-Link Archer T1U 802.11a/n/ac Wireless Adapter [MediaTek MT7610U]

@neilalexander I'm not sure why it does not work for you. I would check for some obvious mistakes, i.e. owl compilation with wrong kernel headers, or wireshark/interface misconfiguration on remote system, etc.

[neilalexander]

So it turns out that this was a regulatory domain problem. I hadn't configured one so it had defaulted to DFS-UNSET.

The hint was actually in the iw list output above all along—active frame injection will not work when there are no IR entries next to the channels, which is actually correct behaviour for the driver.

Setting the regulatory domain correctly removed the no IR restrictions on the channels and resolved the issue.

Really appreciate your help in investigating this with me!

[ZerBea]

I know this is an older thread and it is closed, so this is for your information, only.

Active monitor mode is working like a charm (on all mt76 devices). Recently I added this feature to hcxlabtool: https://github.com/ZerBea/wifi_laboratory/commit/bacb796b7997b5a40d74aff3cce8e38132d4be13

Now hcxlabtool use a minimal radiotap header (only 8 bytes long). Everything else is done via NL80211 and RTNETLINK.