Setting per-frame tx rate for frames injected in raw tx mode

Tue May 10 23:41:04 PDT 2016

Thanks Ben for the info. Sorry about my ignorance; but I do not know
the link to your kernel tree. Could you kindly share?

Let me explain why I need this functionality in first place - I want
to use a custom rate-adaptation (RA) scheme instead of the default.
With ath9k, it was straight-ward to implement a custom RA scheme in
user-space. My user-space daemon gets the packets from an IP
interface, adds the radiotap header with rate information as per my
custom RA scheme and then injects the frame into a monitor interface.
By disabling minstrel-ht in mac80211, I ensure that the rate set in
the radiotap header is what remains the final tx rate at which the
frame is transmitted.

Now things seem drastically different if I were to do the same with
ath10k. Thus I would like to further know:
1) Where exactly in the ath10k packet/frame flow does the RA algorithm
come in picture? Where is it implemented and how can I tweak it to my
liking? Also is there any documentation about the default RA scheme?
2) Or if #1 is not possible, then what changes would be required to
override the default RA on a per-packet basis at any easily accessible
level - mac80211 or user-space. From what I discern from the
description of this commit
(https://github.com/kvalo/ath/commit/646e76bb5daf4ca38438c69ffb72cccb605f3466),
it seems that with a different driver-firmware-chipset combination,
such a thing is possible to do.

Any help is deeply appreciated.

Thanks,
Raj Joshi

On Wed, May 11, 2016 at 12:28 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 05/09/2016 11:11 PM, Raj Joshi wrote:
>>
>> Hi all,
>>
>> For a research project, I need to inject frames in monitor mode and
>> have them sent out with rate settings as set in the radiotap header -
>> basically setting per-frame tx rate. I have tried doing so, but the
>> frame is transmitted at a basic rate with 802.11a instead of a VHT
>> rate as set in the radiotap. Following are the setup and methodology
>> details. Sorry about email length; but wanted to provide as much
>> relevant information.
>>
>> ---------------
>> Setup Info
>> ---------------
>> * x86-64 board running Ubuntu 12.04.5 LTS
>> * Chipset: QCA9880 hw2.0 with 3 x 3 antennas
>> * Kernel: 3.8.0-29-generic x86_64
>> * Firmware: Initially QCA's 10.2.4.70.42-2 obtained via
>> https://github.com/kvalo/ath10k-firmware. After experiencing crashes,
>> later changed to one from CT (10.2.4.70-31-ct-xtW-003-3b0444c) | Both
>> the firmwares support raw-mode.
>> * ath10k: https://github.com/kvalo/ath (snapshot of commit
>> 7de1931eec121045e4e35d0b519ce8bad9b10b51 | Wed Mar 23 14:27:35 2016
>> +0200)
>>   => backport generated using backports.git
>> (https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git)
>> backports-20160122-0-ga91a3e6. Backporting was not clean; had to fix a
>> few compile errors due to missing files by manually copying those
>> files.
>>
>> -------------------
>> Methodology
>> -------------------
>> * Setup up a hostapd 802.11ac AP on one of the boards with 80 MHz
>> channel width and correctly specified center frequencies.
>> * Setup monitor mode on another board for sniffing traffic on the same
>> 80 MHz channel width.
>> * Connect an 802.11ac capable laptop (Windows/Ubuntu) and exchange
>> data frames with the AP | Capture them on the sniffer board (with all
>> the VHT info in radiotap) so that they could be used as reference to
>> construct injection frame.
>> * Now shutdown the AP and change the interface on the AP board to
>> monitor mode. Re-load ath10k_core with rawmode=1 and then ath10k_pci
>> as well. Inject one of the captured frame with radiotap VHT rate info
>> into the monitor interface and use the sniffer to check if it was
>> transmitted.
>> * The firmware (QCA 10.2.4.70.42-2) crashed in this case => couldn't
>> understand the firmware crash dump. Changed the firmware to CT
>> 10.2.4.70-31-ct-xtW-003-3b0444c.
>> * Now the frame is transmitted and detected by the sniffer. However,
>> the radio information via radiotap shows that it was sent with a basic
>> rate of 802.11a.
>> * Tried for both encrypted (WPA2) and non-encrypted frames. Result is the
>> same.
>>
>> --------------------------------
>> Other Considerations
>> --------------------------------
>> * The raw tx patch: As suggested on the CT firmware page, I looked
>> into the so called "out-of-tree" raw tx patch
>> (http://comments.gmane.org/gmane.linux.drivers.ath10k.devel/246) and
>> tried to reconcile it with the current ath10k source. Apparently other
>> than changes to cmd_tx.len,  the suggested changes in the patch are
>> either already in place by use of 'txmode' variable or they are no
>> more relevant with the new source code. For my non-encrypted frame, I
>> got my custom ASCII string inside the frame correctly transmitted and
>> so I 'believe' the changes to cmd_tx.len are no more required due to
>> correct msdu->len. Thus, it seems that this patch is no more necessary
>> and that this patch has nothing to do with correct tx rate setting.
>> * QoS versus non-QoS: Both of my sample injection frames are QoS data
>> with radiotap on top of it. I couldn't find a way to disable QoS and
>> it seems that it is not required either as there is no length issue
>> anymore as was discussed in the raw tx patch discussion; my frame is
>> transmitted whole and correct.
>> * VHT Parsing in Radiotap: I have double checked that my
>> net/mac80211/tx.c has the relevant updated code wrt parsing of VHT
>> rate information
>>
>> (https://github.com/kvalo/ath/commit/646e76bb5daf4ca38438c69ffb72cccb605f3466)
>> * Disabling A-MSDU: I didn't have to do this as I could resolve my
>> firmware crash by switching to the CT firmware.
>> * Using the ath10k master development branch: I also tried backporting
>> master of https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git,
>> but compilation of backported code failed due to lack of some methods
>> such as nla_put_net64, nla_put_be64, etc. in include/net/netlink.h of
>> my stock kernel headers (I believe). So I am not sure if things have
>> changed since the Mar 23 2016 snapshot of ath10k github repo and now
>> that rate is correctly set for VHT raw tx injection.
>
>
> There is no way to specify the TX rate for individual frames with
> CT firmware, nor with any other firmware that I am aware of.
>
> This is probably something I could fix, but it would be a fair bit of
> work, and would require even more changes to the ath10k driver, so
> at best you would have to use my kernel tree...
>
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>