Before trying Radiotap header approach, I did disable Ack's with iw
but the transmition rate remained at basic rate (6 Mbit/s) despite
forcing higher MCS with iw, so it was useless.
Could be this a bug in the driver, unicast traffic sent with NoAck
flag treated as a broadcast, despite higher bitrate forcing?
Returning to Radiotap, what's the point of injecting a frame with
radiotap header if it isn't going to be used? I didn't try all the
possible combinations, but the ones I tryied, they where changed
before arriving at receiver.
Thanks.
BR,
Mário Lopes.
Quoting wim torfs <wtorfs@xxxxxxxxx>:
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.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
