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

Wed May 11 09:13:55 PDT 2016

On 05/10/2016 11:41 PM, Raj Joshi wrote:
> Thanks Ben for the info. Sorry about my ignorance; but I do not know
> the link to your kernel tree. Could you kindly share?

Scroll down this page a bit:

http://www.candelatech.com/ath10k-10.1.php

>
> 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.

For per-packet rate-ctrl, you would need to be able to specify multiple
rate codes, including rate for 80Mhz, 40Mhz, 20Mhz (and 160Mhz for newer
chips, probably).  For mu-mimo, you need to also specify rates based on
the NSS for a peer as well.

You may also need to specify fall-back codes in case of retransmits.

The firmware has at least partial support for configuring the ratesets
on a per-peer basis.  That would let you do per-peer ratectrl, but not
exactly per-packet rate-ctrl.  And, it would require some firmware
patches or at least re-compilation to allow it to work.

To make decisions on rate-ctrl on the host, you need to know advanced
tx-status reporting.  My firmware can report the tx-rate, but I think
you would also need to know retry count for the various rates to have
a good picture of the RF connection to a specific peer.  This would
require a good bit more work in the firmware.

Thanks,
Ben

>
> 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
>>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com