mt7610u: Active frame injection not working #310
Comments
|
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 commit c38cba1dbb22180767f0e24ff29e70a94bf6b9a5 commit c34058b21e9c075c8ab55e71c1700c823f78ffe8 |
|
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 ***@***.***
Date: Tue Apr 2 10:39:52 2019 +0200
another radiotap change
commit c38cba1dbb22180767f0e24ff29e70a94bf6b9a5
Author: ZeroBeat ***@***.***
Date: Tue Apr 2 10:33:21 2019 +0200
changed radiotap header, again - see changelog
commit c34058b21e9c075c8ab55e71c1700c823f78ffe8
Author: ZeroBeat ***@***.***
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
<#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
|
I am using a 5.2 kernel if that is useful to know? |
|
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. |
|
Downgraded to kernel 4.20.1 and the situation is the same. No difference between 2.4GHz and 5GHz bands. |
|
Some other details from ... which led me to wonder whether the firmware has something to do with this? Is there a specific firmware The ... and they came from Arch somewhere I think. The Is there anything else I can try? @LorenzoBianconi Is this the same |
|
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. |
Gave this a go and sadly no difference.
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: ... which creates an 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: 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. |
|
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. |
|
|
|
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) |
|
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. |
|
This issue could be also device specific, I tested on: |
|
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. |
|
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: @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. |
|
So it turns out that this was a regulatory domain problem. I hadn't configured one so it had defaulted to The hint was actually in the Setting the regulatory domain correctly removed the Really appreciate your help in investigating this with me! |
|
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: Now hcxlabtool use a minimal radiotap header (only 8 bytes long). Everything else is done via NL80211 and RTNETLINK. |
mt76driver was built from commit 2a0edbb .Card is a TP-LINK ARCHER T1U connected via USB, which is a MT7610U:
The
mt76driver reports active frame injection (asDevice 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:
Following drivers are loaded:
The text was updated successfully, but these errors were encountered: