Sending frames on monitor interface?

[Michal Kazior]

On 20 February 2015 at 18:27, Ben Greear <greearb at candelatech.com> wrote:
> On 02/19/2015 10:43 PM, Michal Kazior wrote:
>> On 19 February 2015 at 22:38, Ben Greear <greearb at candelatech.com> wrote:
>>> Do any of the firmware versions support sending (raw) frames on
>>> the monitor interface?
>>>
>>> It seems 10.1 just asserts if someone tries this.  I can fix at least
>>> some of this, but firmware seems to want a peer in order to transmit
>>> any packets...maybe adding self-peer to the monitor interface is
>>> a way to get around this?
>>
>> Just an idea: Once upon a time we had to create temporary DA peer for
>> offchannel tx (the code is still in ath10k). 10.1 might want something
>> like that as well for data frames.
>
> I hacked my CT firwmare to allow transmit on monitor interfaces, including
> logic to allow setting up a (fake) peer and rate-ctrl structures.
>
> I tweaked ath10k to create a peer when starting the monitor interface,
> using the local radio's MAC as the peer address (this could easily be part
> of the problem).  I hacked the firmware to always use this peer object when
> transmitting on a monitor interface.
>
> Packets now appear to be accepted for transmit, but I do not see anything on
> the air.  I'll dig into it more if I find time...but not sure exactly how useful
> the feature is anyway.

Are these frames tx completed by firmware or are they stuck in
firmware? Are you transmitting nwifi or raw? Did you try my old RFC
patch[1] for raw tx?

[1]: https://www.mail-archive.com/ath10k@lists.infradead.org/msg00241.html

Also be aware what frames you're injecting. 10.1 doesn't allow mgmt
frames to go through HTT (in case you're trying to force them through
HTT instead of WMI).


> I see the code for off-channel work that you are talking about.  That seems like
> a pretty awful hack if you wanted to do any realistic throughput, but I bet that
> whatever issue this works around is the same issue that I am having trying to
> get monitor TX to work.

This was mainly for P2P discovery/provision so throughput was not a concern.


Michał