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 <gree...@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 <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
