From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]) by merlin.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1b0Ws3-0005BK-Oo for ath10k@lists.infradead.org; Wed, 11 May 2016 16:20:24 +0000 Subject: Re: Setting per-frame tx rate for frames injected in raw tx mode References: <57320C1A.3040604@candelatech.com> From: Ben Greear Message-ID: <57335A43.4050902@candelatech.com> Date: Wed, 11 May 2016 09:13:55 -0700 MIME-Version: 1.0 In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Raj Joshi Cc: ath10k@lists.infradead.org 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 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 >> Candela Technologies Inc http://www.candelatech.com >> > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k