From: wim torfs <wtorfs@gmail.com>
To: "Mário Lopes" <mjlopes@inescporto.pt>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Issue with frame injection on monitor interface (ath9k)
Date: Thu, 19 Feb 2015 19:27:40 +0100 [thread overview]
Message-ID: <54E62B1C.9010908@gmail.com> (raw)
In-Reply-To: <20150219155345.54713ultwqjbtrsp@horde.inescporto.pt>
On 02/19/2015 03:53 PM, Mário Lopes wrote:
> Hi everyone.
>
> When using frame injection over monitor interface, with handmade packet
> with Radiotap header + QoS + Data, at sender I capture the packet with
> tcpdump and it is equal to the one I sent.
> Although, at receiver station, the packet is diferent, FCS was
> recalculated or forced to active and calculated, MCS is not the one I
> supplied, sequence number (QoS field) is not the same, amongst other
> things.
> Also, QoS Ack policy was "No Ack" at sender (QoS Control = 0x0020), a
> Ack frame was transmitted to sender and the received packet arrived with
> QoS Control = 0x0000.
>
Mario,
If I'm not mistaken, the mac80211 parses your injected packet, retrieves
relevant information, such as flags from the radiotap header, removes
the radiotap header from your packet and then proceeds with sending the
packet as any normal packet towards the radio interface.
This, however, means that either the mac80211 rate control algorithm is
calls or the ath9k rate control algorithm, depending on your kernel
configuration. The ath9k driver uses this rate control information to
compose the tx descriptor, after which the packet is handed over to the
hardware.
I believe it is also the hardware (transmitter side or receiver side,
that I don't know), which fills in the actual rate used for the
transmission in your packet, since the hardware is capable of
retransmitting your packet with a lower rate when transmissions fail too
much at the highest rate from the rate selection algorithm.
You mentioned that you monitor interface captures the packet as you have
sent it. If I remember correctly, the mac80211 forwards this packet
towards the monitor interface when the tx status of ath9k has been
received, so basically, you receive transmission status information,
along with your originally sent packet. Sequence numbers should have
been adjusted in this packet I think, however, the transmission rate
will be the same as you have specified.
If you would like to send at a specific rate, you would need to use the
relevant iw commands to fix the transmission rate (or hack ath9k to
transmit at a fixed rate).
Best regards,
Wim.
next prev parent reply other threads:[~2015-02-19 18:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 14:53 Issue with frame injection on monitor interface (ath9k) Mário Lopes
2015-02-19 18:27 ` wim torfs [this message]
2015-02-20 10:11 ` Mário Lopes
2015-02-21 7:13 ` wim torfs
2015-02-23 10:18 ` Mário Lopes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E62B1C.9010908@gmail.com \
--to=wtorfs@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mjlopes@inescporto.pt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).