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

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

[Raj Joshi]

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.

--------
Files
--------
* single udp encapsulating unencrypted frame
(https://www.dropbox.com/s/pqmjk2ayw6uwqiw/single_udp_unencrypted_frame.pcap?dl=0)
* single udp encapsulating encrypted frame
(https://www.dropbox.com/s/4zvgb7ls40v46zu/single_udp_encrypted_frame.pcap?dl=0)
Not sure if it is necessary to change the source MAC address to that
of your respective wlan card.

Any help in getting this thing to work is deeply appreciated.

Thanks,
Raj Joshi

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Raj Joshi]

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@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@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

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@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@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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Raj Joshi]

Thanks for such useful info. Setting of multiple rate codes for
channel width, GI, NSS and MCS is what my RA implementation for ath9k
does. It also relies on advanced tx-status reporting to know the
retries etc. I am not planning to account for MU-MIMO for the
beginning. But it helps to know that it would require work and the
support is not ready yet.

For my understanding, I would like to know ath10k vis-a-vis ath9k from
the perspective of rate-adaptation (RA):
1) Scheme/Algorithm: ath9k uses Minstrel-HT and an overview (basis of
the algorithm) is available online [1]. What is the scheme/algorithm
being used by ath10k? Any overview/documentation available?
2) Where implemented?: Minstrel-HT is implemented in mac80211. Where
is ath10k's RA implemented?
3) Where in pipeline is the rate set?: With Minstrel-HT rate is set in
mac80211 before passing the frame onto ath9k. With ath10k, where the
rate is set? Can anyone point me to the line(s) of code where the rate
is it (of course if that part is open-source). As far as I have
investigated, the rate set in mac80211 is not honored by
ath10k/firmware/hardware.

[1] https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel

Thanks,
Raj Joshi


On Thu, May 12, 2016 at 12:13 AM, Ben Greear <greearb@candelatech.com> wrote:
> 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@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@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 <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

On 05/14/2016 07:40 PM, Raj Joshi wrote:
> Thanks for such useful info. Setting of multiple rate codes for
> channel width, GI, NSS and MCS is what my RA implementation for ath9k
> does. It also relies on advanced tx-status reporting to know the
> retries etc. I am not planning to account for MU-MIMO for the
> beginning. But it helps to know that it would require work and the
> support is not ready yet.
>
> For my understanding, I would like to know ath10k vis-a-vis ath9k from
> the perspective of rate-adaptation (RA):
> 1) Scheme/Algorithm: ath9k uses Minstrel-HT and an overview (basis of
> the algorithm) is available online [1]. What is the scheme/algorithm
> being used by ath10k? Any overview/documentation available?

No documentation is available, and the information would be proprietary since
it is in the closed-source firmware.

> 2) Where implemented?: Minstrel-HT is implemented in mac80211. Where
> is ath10k's RA implemented?

In the firmware itself.

> 3) Where in pipeline is the rate set?: With Minstrel-HT rate is set in
> mac80211 before passing the frame onto ath9k. With ath10k, where the
> rate is set? Can anyone point me to the line(s) of code where the rate
> is it (of course if that part is open-source). As far as I have
> investigated, the rate set in mac80211 is not honored by
> ath10k/firmware/hardware.

I am not sure the driver has even implemented the API.  But,the basic idea
is that the driver could set the rateset for a peer (and do so fairly often
as things change), and the firmware will apply that rateset to frames
in it's transmit logic.

Can you tell me the minimum information you need for tx-status to support
your API?

Thanks,
Ben

>
> [1] https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel
>
> Thanks,
> Raj Joshi
>
>
> On Thu, May 12, 2016 at 12:13 AM, Ben Greear <greearb@candelatech.com> wrote:
>> 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@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@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 <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Ben Greear]

I guess another thought comes to mind.

Maybe I could extend the pkt header when sending the frame to the firmware
so that it *already* has the rateset specified.  And rip out the rate-ctrl logic
from the firmware entirely.  I'm not sure this would work for mu-mimo, but might
work for QCA9880 chips...

Thanks,
Ben

On 05/15/2016 08:17 AM, Ben Greear wrote:
>
>
> On 05/14/2016 07:40 PM, Raj Joshi wrote:
>> Thanks for such useful info. Setting of multiple rate codes for
>> channel width, GI, NSS and MCS is what my RA implementation for ath9k
>> does. It also relies on advanced tx-status reporting to know the
>> retries etc. I am not planning to account for MU-MIMO for the
>> beginning. But it helps to know that it would require work and the
>> support is not ready yet.
>>
>> For my understanding, I would like to know ath10k vis-a-vis ath9k from
>> the perspective of rate-adaptation (RA):
>> 1) Scheme/Algorithm: ath9k uses Minstrel-HT and an overview (basis of
>> the algorithm) is available online [1]. What is the scheme/algorithm
>> being used by ath10k? Any overview/documentation available?
>
> No documentation is available, and the information would be proprietary since
> it is in the closed-source firmware.
>
>> 2) Where implemented?: Minstrel-HT is implemented in mac80211. Where
>> is ath10k's RA implemented?
>
> In the firmware itself.
>
>> 3) Where in pipeline is the rate set?: With Minstrel-HT rate is set in
>> mac80211 before passing the frame onto ath9k. With ath10k, where the
>> rate is set? Can anyone point me to the line(s) of code where the rate
>> is it (of course if that part is open-source). As far as I have
>> investigated, the rate set in mac80211 is not honored by
>> ath10k/firmware/hardware.
>
> I am not sure the driver has even implemented the API.  But,the basic idea
> is that the driver could set the rateset for a peer (and do so fairly often
> as things change), and the firmware will apply that rateset to frames
> in it's transmit logic.
>
> Can you tell me the minimum information you need for tx-status to support
> your API?
>
> Thanks,
> Ben
>
>>
>> [1] https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel
>>
>> Thanks,
>> Raj Joshi
>>
>>
>> On Thu, May 12, 2016 at 12:13 AM, Ben Greear <greearb@candelatech.com> wrote:
>>> 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@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@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 <greearb@candelatech.com>
>>> Candela Technologies Inc  http://www.candelatech.com
>>>
>>
>

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Raj Joshi]

I see.. So the RA is implemented in firmware and is closed source.
Also it is unclear if the driver (ath10k) has implemented an API for
it.

Your idea sounds similar to how it is working for me in ath9k - in the
file net/mac80211/tx.c, the HT rate information from the radiotap
header is parsed and set in the struct ieee80211_tx_info (see the
method ieee80211_parse_tx_radiotap()). A recent commit [1] also added
parsing for VHT information from radiotap. This seems to be a standard
way of doing it and it seems to work with "d-link dir-860l rev b1
running OpenWrt trunk and mt76 driver" as the commit description
mentions. However with ath10k, the rate from this tx_info seems to be
not honored :(

But I believe there should be some way of fixing rate settings from
upper layers of the pipeline. iw lets us do manual bitrate
configuration [2] for ath10k which works as expected. But this only
helps in setting of rate per-session. I am still finding answers to
the following questions:
1) What is it that iw does that it manages to get the manual bitrate
configuration?
2) How does it ask the firmware to not do any RA and always honor the
set rate? Basically how does it override the default RA?
3) Can we do the same on a per-packet basis?

It would be very helpful if someone can shed light on these questions
regarding iw's manual bitrate configuration for ath10k.

[1] https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/net/mac80211/tx.c?id=646e76bb5daf4ca38438c69ffb72cccb605f3466
[2] https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#manual_bitrates_configuration

Thanks,
Raj Joshi

On Mon, May 16, 2016 at 1:15 AM, Ben Greear <greearb@candelatech.com> wrote:
> I guess another thought comes to mind.
>
> Maybe I could extend the pkt header when sending the frame to the firmware
> so that it *already* has the rateset specified.  And rip out the rate-ctrl
> logic
> from the firmware entirely.  I'm not sure this would work for mu-mimo, but
> might
> work for QCA9880 chips...
>
> Thanks,
> Ben
>
>
> On 05/15/2016 08:17 AM, Ben Greear wrote:
>>
>>
>>
>> On 05/14/2016 07:40 PM, Raj Joshi wrote:
>>>
>>> Thanks for such useful info. Setting of multiple rate codes for
>>> channel width, GI, NSS and MCS is what my RA implementation for ath9k
>>> does. It also relies on advanced tx-status reporting to know the
>>> retries etc. I am not planning to account for MU-MIMO for the
>>> beginning. But it helps to know that it would require work and the
>>> support is not ready yet.
>>>
>>> For my understanding, I would like to know ath10k vis-a-vis ath9k from
>>> the perspective of rate-adaptation (RA):
>>> 1) Scheme/Algorithm: ath9k uses Minstrel-HT and an overview (basis of
>>> the algorithm) is available online [1]. What is the scheme/algorithm
>>> being used by ath10k? Any overview/documentation available?
>>
>>
>> No documentation is available, and the information would be proprietary
>> since
>> it is in the closed-source firmware.
>>
>>> 2) Where implemented?: Minstrel-HT is implemented in mac80211. Where
>>> is ath10k's RA implemented?
>>
>>
>> In the firmware itself.
>>
>>> 3) Where in pipeline is the rate set?: With Minstrel-HT rate is set in
>>> mac80211 before passing the frame onto ath9k. With ath10k, where the
>>> rate is set? Can anyone point me to the line(s) of code where the rate
>>> is it (of course if that part is open-source). As far as I have
>>> investigated, the rate set in mac80211 is not honored by
>>> ath10k/firmware/hardware.
>>
>>
>> I am not sure the driver has even implemented the API.  But,the basic idea
>> is that the driver could set the rateset for a peer (and do so fairly
>> often
>> as things change), and the firmware will apply that rateset to frames
>> in it's transmit logic.
>>
>> Can you tell me the minimum information you need for tx-status to support
>> your API?
>>
>> Thanks,
>> Ben
>>
>>>
>>> [1]
>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel
>>>
>>> Thanks,
>>> Raj Joshi
>>>
>>>
>>> On Thu, May 12, 2016 at 12:13 AM, Ben Greear <greearb@candelatech.com>
>>> wrote:
>>>>
>>>> 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@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@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 <greearb@candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
Raj Joshi


On Mon, May 16, 2016 at 12:15 AM, Ben Greear <greearb@candelatech.com> wrote:
> I guess another thought comes to mind.
>
> Maybe I could extend the pkt header when sending the frame to the firmware
> so that it *already* has the rateset specified.  And rip out the rate-ctrl
> logic
> from the firmware entirely.  I'm not sure this would work for mu-mimo, but
> might
> work for QCA9880 chips...
>
> Thanks,
> Ben
>
>
> On 05/15/2016 08:17 AM, Ben Greear wrote:
>>
>>
>>
>> On 05/14/2016 07:40 PM, Raj Joshi wrote:
>>>
>>> Thanks for such useful info. Setting of multiple rate codes for
>>> channel width, GI, NSS and MCS is what my RA implementation for ath9k
>>> does. It also relies on advanced tx-status reporting to know the
>>> retries etc. I am not planning to account for MU-MIMO for the
>>> beginning. But it helps to know that it would require work and the
>>> support is not ready yet.
>>>
>>> For my understanding, I would like to know ath10k vis-a-vis ath9k from
>>> the perspective of rate-adaptation (RA):
>>> 1) Scheme/Algorithm: ath9k uses Minstrel-HT and an overview (basis of
>>> the algorithm) is available online [1]. What is the scheme/algorithm
>>> being used by ath10k? Any overview/documentation available?
>>
>>
>> No documentation is available, and the information would be proprietary
>> since
>> it is in the closed-source firmware.
>>
>>> 2) Where implemented?: Minstrel-HT is implemented in mac80211. Where
>>> is ath10k's RA implemented?
>>
>>
>> In the firmware itself.
>>
>>> 3) Where in pipeline is the rate set?: With Minstrel-HT rate is set in
>>> mac80211 before passing the frame onto ath9k. With ath10k, where the
>>> rate is set? Can anyone point me to the line(s) of code where the rate
>>> is it (of course if that part is open-source). As far as I have
>>> investigated, the rate set in mac80211 is not honored by
>>> ath10k/firmware/hardware.
>>
>>
>> I am not sure the driver has even implemented the API.  But,the basic idea
>> is that the driver could set the rateset for a peer (and do so fairly
>> often
>> as things change), and the firmware will apply that rateset to frames
>> in it's transmit logic.
>>
>> Can you tell me the minimum information you need for tx-status to support
>> your API?
>>
>> Thanks,
>> Ben
>>
>>>
>>> [1]
>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel
>>>
>>> Thanks,
>>> Raj Joshi
>>>
>>>
>>> On Thu, May 12, 2016 at 12:13 AM, Ben Greear <greearb@candelatech.com>
>>> wrote:
>>>>
>>>> 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@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@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 <greearb@candelatech.com>
>>>> Candela Technologies Inc  http://www.candelatech.com
>>>>
>>>
>>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 17 May 2016 at 09:14, Raj Joshi <rajjoshi@comp.nus.edu.sg> wrote:
> I see.. So the RA is implemented in firmware and is closed source.
> Also it is unclear if the driver (ath10k) has implemented an API for
> it.
>
> Your idea sounds similar to how it is working for me in ath9k - in the
> file net/mac80211/tx.c, the HT rate information from the radiotap
> header is parsed and set in the struct ieee80211_tx_info (see the
> method ieee80211_parse_tx_radiotap()). A recent commit [1] also added
> parsing for VHT information from radiotap. This seems to be a standard
> way of doing it and it seems to work with "d-link dir-860l rev b1
> running OpenWrt trunk and mt76 driver" as the commit description
> mentions. However with ath10k, the rate from this tx_info seems to be
> not honored :(
>
> But I believe there should be some way of fixing rate settings from
> upper layers of the pipeline. iw lets us do manual bitrate
> configuration [2] for ath10k which works as expected. But this only
> helps in setting of rate per-session. I am still finding answers to
> the following questions:
> 1) What is it that iw does that it manages to get the manual bitrate
> configuration?

It ends up calling driver specific set_bitrate_mask, which is
ath10k_mac_op_set_bitrate_mask() for ath10k. If the bitrate mask is a
single rate (instead of an actual mask/set) driver sends a set of
commands to firmware to force fixed-rate.


> 2) How does it ask the firmware to not do any RA and always honor the
> set rate? Basically how does it override the default RA?

It sends a few per-interface commands to firmware, see
ath10k_mac_set_fixed_rate_params().

Do note this refers to unicast. I think multicast needs a different knob.


> 3) Can we do the same on a per-packet basis?

As it is now there's no easy way to do this.

WMI commands per se don't have any synchronization to them. A few of
them produce feedback events (vdev_start, ping) so you could probably
use them to make sure, e.g. fixed-rate commands were processed before
you submit Tx. You'd also need to flush to avoid changing rate for
frames that are still in Tx ring. I'm not sure how fast that'll be.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Valo, Kalle]

Raj Joshi <rajjoshi@comp.nus.edu.sg> writes:

> But I believe there should be some way of fixing rate settings from
> upper layers of the pipeline. iw lets us do manual bitrate
> configuration [2] for ath10k which works as expected. But this only
> helps in setting of rate per-session. I am still finding answers to
> the following questions:
> 1) What is it that iw does that it manages to get the manual bitrate
> configuration?
> 2) How does it ask the firmware to not do any RA and always honor the
> set rate? Basically how does it override the default RA?

The firmware has separate WMI vdev parameters for setting a fixed rate,
check ath10k_mac_op_set_bitrate_mask() for more info.

> 3) Can we do the same on a per-packet basis?

The firmware currently doesn't support that.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

QCA9984 VHT160 support

[Sebastian Gottschall]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Attached you will find a testing patch for VHT160 support. i tested it 
today on a QCA9984 device and it seems to work.
feel free to make any corrections


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


[-- Attachment #2: vht160.patch --]
[-- Type: text/plain, Size: 3832 bytes --]

Index: drivers/net/wireless/ath/ath9k/gpio.c
===================================================================
Index: drivers/net/wireless/ath/ath10k/mac.c
===================================================================
--- drivers/net/wireless/ath/ath10k/mac.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/mac.c	(working copy)
@@ -539,10 +539,14 @@
 		case NL80211_CHAN_WIDTH_80:
 			phymode = MODE_11AC_VHT80;
 			break;
+		case NL80211_CHAN_WIDTH_160:
+			phymode = MODE_11AC_VHT160;
+			break;
+		case NL80211_CHAN_WIDTH_80P80:
+			phymode = MODE_11AC_VHT80_80;
+			break;
 		case NL80211_CHAN_WIDTH_5:
 		case NL80211_CHAN_WIDTH_10:
-		case NL80211_CHAN_WIDTH_80P80:
-		case NL80211_CHAN_WIDTH_160:
 			phymode = MODE_UNKNOWN;
 			break;
 		}
@@ -2499,6 +2503,8 @@
 		    !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 				phymode = MODE_11AC_VHT80;
+			else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+				phymode = MODE_11AC_VHT160;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11AC_VHT40;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
@@ -4185,6 +4191,10 @@
 
 		vht_cap.cap |= val;
 	}
+	if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
+		vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
+		vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
+	}
 
 	mcs_map = 0;
 	for (i = 0; i < 8; i++) {
@@ -6798,6 +6808,9 @@
 			bw = WMI_PEER_CHWIDTH_80MHZ;
 			break;
 		case IEEE80211_STA_RX_BW_160:
+			bw = WMI_PEER_CHWIDTH_160MHZ;
+			break;
+		default:
 			ath10k_warn(ar, "Invalid bandwidth %d in rc update for %pM\n",
 				    sta->bandwidth, sta->addr);
 			bw = WMI_PEER_CHWIDTH_20MHZ;
Index: drivers/net/wireless/ath/ath10k/htt_rx.c
===================================================================
--- drivers/net/wireless/ath/ath10k/htt_rx.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/htt_rx.c	(working copy)
@@ -707,6 +707,10 @@
 		/* 80MHZ */
 		case 2:
 			status->vht_flag |= RX_VHT_FLAG_80MHZ;
+			break;
+		case 3:
+			status->vht_flag |= RX_VHT_FLAG_160MHZ;
+			break;
 		}
 
 		status->flag |= RX_FLAG_VHT;
@@ -2193,6 +2197,8 @@
 	case MODE_11AC_VHT20:
 	case MODE_11AC_VHT40:
 	case MODE_11AC_VHT80:
+	case MODE_11AC_VHT160:
+	case MODE_11AC_VHT80_80:
 		band = NL80211_BAND_5GHZ;
 		break;
 	case MODE_11G:
Index: drivers/net/wireless/ath/ath10k/wmi.h
===================================================================
--- drivers/net/wireless/ath/ath10k/wmi.h	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/wmi.h	(working copy)
@@ -1723,8 +1723,10 @@
 	MODE_11AC_VHT20_2G = 11,
 	MODE_11AC_VHT40_2G = 12,
 	MODE_11AC_VHT80_2G = 13,
-	MODE_UNKNOWN    = 14,
-	MODE_MAX        = 14
+	MODE_11AC_VHT80_80 = 14,
+	MODE_11AC_VHT160 = 15,
+	MODE_UNKNOWN    = 16,
+	MODE_MAX        = 16
 };
 
 static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
@@ -1752,6 +1754,10 @@
 		return "11ac-vht40";
 	case MODE_11AC_VHT80:
 		return "11ac-vht80";
+	case MODE_11AC_VHT160:
+		return "11ac-vht160";
+	case MODE_11AC_VHT80_80:
+		return "11ac-vht80+80";
 	case MODE_11AC_VHT20_2G:
 		return "11ac-vht20-2g";
 	case MODE_11AC_VHT40_2G:
@@ -5748,6 +5754,7 @@
 	WMI_PEER_CHWIDTH_20MHZ = 0,
 	WMI_PEER_CHWIDTH_40MHZ = 1,
 	WMI_PEER_CHWIDTH_80MHZ = 2,
+	WMI_PEER_CHWIDTH_160MHZ = 3,
 };
 
 enum wmi_peer_param {
Index: compat/backport-4.5.c
===================================================================
\ No newline at end of file
Index: backport-include/backport/leds-disabled.h
===================================================================
Index: backport-include/linux/leds.h
===================================================================
Index: net/wireless/db.txt
===================================================================

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Michal Kazior]

On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
> Attached you will find a testing patch for VHT160 support. i tested it today
> on a QCA9984 device and it seems to work.
> feel free to make any corrections

Hi,

Send patches inline, please. Preferably via git send-email. It's a lot
easier to review them this way.

From a quick glance vht capabilities setup looks weird:

> if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
>   vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
>   vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
> }

Why? Is this really necessary?

I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
ar->vht_cap_info if the chip supports 160 or 80+80.

You also don't seem to handle 80+80 because you just as phymode to 160
regardless of center frequencies:

> !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
>    if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
>      phymode = MODE_11AC_VHT80;
>    else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
>      phymode = MODE_11AC_VHT160;
>    else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
>      phymode = MODE_11AC_VHT40;
>    else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)

You should probably look at sta->vht_cap and associated chanctx to
check if it isn't 80+80.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Michal Kazior]

+ re-adding ath10k list


On 17 May 2016 at 14:05, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
>Am 17.05.2016 um 14:00 schrieb Michal Kazior:
>> On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
>>> Attached you will find a testing patch for VHT160 support. i tested it today
>>> on a QCA9984 device and it seems to work.
>>> feel free to make any corrections
>> Hi,
>>
>> Send patches inline, please. Preferably via git send-email. It's a lot
>> easier to review them this way.
> unfortunaty i dont work with git right now and i wanted to send it to
> the list first for getting comments.
> since the patch is also very small, it should be that complicated
>>
>>  From a quick glance vht capabilities setup looks weird:
>>
>>> if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
>>>    vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
>>>    vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
>>> }
>> Why? Is this really necessary?
> the firmware does not report correct flags. just SHORT_GI_160.
> i reviewed the firmware sourcecodes and found out that this is maybe a
> misstake of the QCA developers.
> so we need to add the 160MHZ support flags locally using the
> SHORT_GI_160 which is always set on QCA9984.
> otherwise mac80211 will not be capable of running vht160.

I'm not sure if SGI160 implies 80+80.


>> I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
>> ar->vht_cap_info if the chip supports 160 or 80+80.
>me too. but it isnt :-)

Sigh. A comment explaining that would be really nice.


>> You also don't seem to handle 80+80 because you just as phymode to 160
>> regardless of center frequencies:
>>
>>> !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
>>>     if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
>>>       phymode = MODE_11AC_VHT80;
>>>     else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
>>>       phymode = MODE_11AC_VHT160;
>>>     else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
>>>       phymode = MODE_11AC_VHT40;
>>>     else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
> there is no 80+80 STA_RX_BW flag. i dont know how to handle this. and
> yes, just 160 mhz is tested right now. right now it looks like mac80211
> is not 80+80 ready.

Hmm.. I wouldn't advertise 80+80 support then. All the more since
there's no way of telling whether hw/fw actually supports it in the
first place.


Michal

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Sebastian Gottschall]

Am 17.05.2016 um 14:18 schrieb Michal Kazior:
> + re-adding ath10k list
>
>
> On 17 May 2016 at 14:05, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
>> Am 17.05.2016 um 14:00 schrieb Michal Kazior:
>>> On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
>>>> Attached you will find a testing patch for VHT160 support. i tested it today
>>>> on a QCA9984 device and it seems to work.
>>>> feel free to make any corrections
>>> Hi,
>>>
>>> Send patches inline, please. Preferably via git send-email. It's a lot
>>> easier to review them this way.
>> unfortunaty i dont work with git right now and i wanted to send it to
>> the list first for getting comments.
>> since the patch is also very small, it should be that complicated
>>>   From a quick glance vht capabilities setup looks weird:
>>>
>>>> if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
>>>>     vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
>>>>     vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
>>>> }
>>> Why? Is this really necessary?
>> the firmware does not report correct flags. just SHORT_GI_160.
>> i reviewed the firmware sourcecodes and found out that this is maybe a
>> misstake of the QCA developers.
>> so we need to add the 160MHZ support flags locally using the
>> SHORT_GI_160 which is always set on QCA9984.
>> otherwise mac80211 will not be capable of running vht160.
> I'm not sure if SGI160 implies 80+80.
according to the firmware sourcecode of 9984 it seems so. thats the only 
information source i have
>
>
>>> I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
>>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
>>> ar->vht_cap_info if the chip supports 160 or 80+80.
>> me too. but it isnt :-)
> Sigh. A comment explaining that would be really nice.
there is no comment available. the only information source is the 
firmware sourcecode for the 9984 which i reviewed.
let me give you a small snippet
#if defined(CONFIG_160MHZ_SUPPORT)
#define VHT_CAP_WITH_STBC_1SS_VHT160 ((VHT_CAP_WITH_STBC_1SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_2SS_VHT160 ((VHT_CAP_WITH_STBC_2SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_3SS_VHT160 ((VHT_CAP_WITH_STBC_3SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#endif
#if defined(CONFIG_160MHZ_SUPPORT)
     dev_info->vht_cap_info  = VHT_CAP_WITH_STBC_1SS_VHT160;
#else
     dev_info->vht_cap_info  = VHT_CAP_WITH_STBC_1SS_VHT80;
#endif


so the firmware simply does not set the correct flags. thats all.
>
>
>>> You also don't seem to handle 80+80 because you just as phymode to 160
>>> regardless of center frequencies:
>>>
>>>> !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
>>>>      if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
>>>>        phymode = MODE_11AC_VHT80;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
>>>>        phymode = MODE_11AC_VHT160;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
>>>>        phymode = MODE_11AC_VHT40;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
>> there is no 80+80 STA_RX_BW flag. i dont know how to handle this. and
>> yes, just 160 mhz is tested right now. right now it looks like mac80211
>> is not 80+80 ready.
> Hmm.. I wouldn't advertise 80+80 support then. All the more since
> there's no way of telling whether hw/fw actually supports it in the
> first place.
we can leave it out at the end, but the firmware seem to support it. so 
far i just tested 160 in ap mode yet, but found other
things in ath10k which need to be fixed. i'm on it right now
>
>
> Michal
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Sebastian Gottschall]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

this is a updated patchset which adds further corrections.
80p80 support is detected by sta flags right now.


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


[-- Attachment #2: vht160_2.patch --]
[-- Type: text/plain, Size: 6953 bytes --]

Index: drivers/net/wireless/ath/ath10k/mac.c
===================================================================
--- drivers/net/wireless/ath/ath10k/mac.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/mac.c	(working copy)
@@ -539,10 +539,14 @@
 		case NL80211_CHAN_WIDTH_80:
 			phymode = MODE_11AC_VHT80;
 			break;
+		case NL80211_CHAN_WIDTH_160:
+			phymode = MODE_11AC_VHT160;
+			break;
+		case NL80211_CHAN_WIDTH_80P80:
+			phymode = MODE_11AC_VHT80_80;
+			break;
 		case NL80211_CHAN_WIDTH_5:
 		case NL80211_CHAN_WIDTH_10:
-		case NL80211_CHAN_WIDTH_80P80:
-		case NL80211_CHAN_WIDTH_160:
 			phymode = MODE_UNKNOWN;
 			break;
 		}
@@ -2398,6 +2402,9 @@
 	if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 		arg->peer_flags |= ar->wmi.peer_flags->bw80;
 
+	if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+		arg->peer_flags |= ar->wmi.peer_flags->bw160;
+
 	arg->peer_vht_rates.rx_max_rate =
 		__le16_to_cpu(vht_cap->vht_mcs.rx_highest);
 	arg->peer_vht_rates.rx_mcs_set =
@@ -2499,7 +2506,12 @@
 		    !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 				phymode = MODE_11AC_VHT80;
-			else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
+			else if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
+				if (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ) 
+					phymode = MODE_11AC_VHT80_80;
+				else
+					phymode = MODE_11AC_VHT160;
+			} else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11AC_VHT40;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
 				phymode = MODE_11AC_VHT20;
@@ -4185,6 +4197,10 @@
 
 		vht_cap.cap |= val;
 	}
+	if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
+		vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
+		vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
+	}
 
 	mcs_map = 0;
 	for (i = 0; i < 8; i++) {
@@ -6798,6 +6814,9 @@
 			bw = WMI_PEER_CHWIDTH_80MHZ;
 			break;
 		case IEEE80211_STA_RX_BW_160:
+			bw = WMI_PEER_CHWIDTH_160MHZ;
+			break;
+		default:
 			ath10k_warn(ar, "Invalid bandwidth %d in rc update for %pM\n",
 				    sta->bandwidth, sta->addr);
 			bw = WMI_PEER_CHWIDTH_20MHZ;
Index: drivers/net/wireless/ath/ath10k/htt_rx.c
===================================================================
--- drivers/net/wireless/ath/ath10k/htt_rx.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/htt_rx.c	(working copy)
@@ -707,6 +707,10 @@
 		/* 80MHZ */
 		case 2:
 			status->vht_flag |= RX_VHT_FLAG_80MHZ;
+			break;
+		case 3:
+			status->vht_flag |= RX_VHT_FLAG_160MHZ;
+			break;
 		}
 
 		status->flag |= RX_FLAG_VHT;
@@ -931,7 +935,7 @@
 	*status = *rx_status;
 
 	ath10k_dbg(ar, ATH10K_DBG_DATA,
-		   "rx skb %p len %u peer %pM %s %s sn %u %s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
+		   "rx skb %p len %u peer %pM %s %s sn %u %s%s%s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
 		   skb,
 		   skb->len,
 		   ieee80211_get_SA(hdr),
@@ -944,6 +948,7 @@
 		   status->flag & RX_FLAG_VHT ? "vht" : "",
 		   status->flag & RX_FLAG_40MHZ ? "40" : "",
 		   status->vht_flag & RX_VHT_FLAG_80MHZ ? "80" : "",
+		   status->vht_flag & RX_VHT_FLAG_160MHZ ? "160" : "",
 		   status->flag & RX_FLAG_SHORT_GI ? "sgi " : "",
 		   status->rate_idx,
 		   status->vht_nss,
@@ -2193,6 +2198,8 @@
 	case MODE_11AC_VHT20:
 	case MODE_11AC_VHT40:
 	case MODE_11AC_VHT80:
+	case MODE_11AC_VHT160:
+	case MODE_11AC_VHT80_80:
 		band = NL80211_BAND_5GHZ;
 		break;
 	case MODE_11G:
Index: drivers/net/wireless/ath/ath10k/wmi-tlv.c
===================================================================
--- drivers/net/wireless/ath/ath10k/wmi-tlv.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/wmi-tlv.c	(working copy)
@@ -3503,6 +3503,7 @@
 	.vht = WMI_TLV_PEER_VHT,
 	.bw80 = WMI_TLV_PEER_80MHZ,
 	.pmf = WMI_TLV_PEER_PMF,
+	.bw160 = WMI_TLV_PEER_160MHZ,
 };
 
 /************/
Index: drivers/net/wireless/ath/ath10k/wmi-tlv.h
===================================================================
--- drivers/net/wireless/ath/ath10k/wmi-tlv.h	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/wmi-tlv.h	(working copy)
@@ -543,6 +543,7 @@
 	WMI_TLV_PEER_VHT = 0x02000000,
 	WMI_TLV_PEER_80MHZ = 0x04000000,
 	WMI_TLV_PEER_PMF = 0x08000000,
+        WMI_TLV_PEER_160MHZ = 0x20000000,
 };
 
 enum wmi_tlv_tag {
Index: drivers/net/wireless/ath/ath10k/wmi.c
===================================================================
--- drivers/net/wireless/ath/ath10k/wmi.c	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/wmi.c	(working copy)
@@ -1569,6 +1569,7 @@
 	.bw80 = WMI_PEER_80MHZ,
 	.vht_2g = WMI_PEER_VHT_2G,
 	.pmf = WMI_PEER_PMF,
+	.bw160 = WMI_PEER_160MHZ,
 };
 
 static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
@@ -1586,6 +1587,7 @@
 	.spatial_mux = WMI_10X_PEER_SPATIAL_MUX,
 	.vht = WMI_10X_PEER_VHT,
 	.bw80 = WMI_10X_PEER_80MHZ,
+	.bw160 = WMI_10X_PEER_160MHZ,
 };
 
 static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
@@ -1605,6 +1607,7 @@
 	.bw80 = WMI_10_2_PEER_80MHZ,
 	.vht_2g = WMI_10_2_PEER_VHT_2G,
 	.pmf = WMI_10_2_PEER_PMF,
+	.bw160 = WMI_10_2_PEER_160MHZ,
 };
 
 void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
Index: drivers/net/wireless/ath/ath10k/wmi.h
===================================================================
--- drivers/net/wireless/ath/ath10k/wmi.h	(revision 2910)
+++ drivers/net/wireless/ath/ath10k/wmi.h	(working copy)
@@ -1723,8 +1723,10 @@
 	MODE_11AC_VHT20_2G = 11,
 	MODE_11AC_VHT40_2G = 12,
 	MODE_11AC_VHT80_2G = 13,
-	MODE_UNKNOWN    = 14,
-	MODE_MAX        = 14
+	MODE_11AC_VHT80_80 = 14,
+	MODE_11AC_VHT160 = 15,
+	MODE_UNKNOWN    = 16,
+	MODE_MAX        = 16
 };
 
 static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
@@ -1752,6 +1754,10 @@
 		return "11ac-vht40";
 	case MODE_11AC_VHT80:
 		return "11ac-vht80";
+	case MODE_11AC_VHT160:
+		return "11ac-vht160";
+	case MODE_11AC_VHT80_80:
+		return "11ac-vht80+80";
 	case MODE_11AC_VHT20_2G:
 		return "11ac-vht20-2g";
 	case MODE_11AC_VHT40_2G:
@@ -5748,6 +5754,7 @@
 	WMI_PEER_CHWIDTH_20MHZ = 0,
 	WMI_PEER_CHWIDTH_40MHZ = 1,
 	WMI_PEER_CHWIDTH_80MHZ = 2,
+	WMI_PEER_CHWIDTH_160MHZ = 3,
 };
 
 enum wmi_peer_param {
@@ -5838,6 +5845,7 @@
 	u32 bw80;
 	u32 vht_2g;
 	u32 pmf;
+	u32 bw160;
 };
 
 enum wmi_peer_flags {
@@ -5857,6 +5865,7 @@
 	WMI_PEER_80MHZ = 0x04000000,
 	WMI_PEER_VHT_2G = 0x08000000,
 	WMI_PEER_PMF = 0x10000000,
+	WMI_PEER_160MHZ = 0x20000000
 };
 
 enum wmi_10x_peer_flags {
@@ -5874,6 +5883,7 @@
 	WMI_10X_PEER_SPATIAL_MUX = 0x00200000,
 	WMI_10X_PEER_VHT = 0x02000000,
 	WMI_10X_PEER_80MHZ = 0x04000000,
+	WMI_10X_PEER_160MHZ = 0x20000000
 };
 
 enum wmi_10_2_peer_flags {
@@ -5893,6 +5903,7 @@
 	WMI_10_2_PEER_80MHZ = 0x04000000,
 	WMI_10_2_PEER_VHT_2G = 0x08000000,
 	WMI_10_2_PEER_PMF = 0x10000000,
+	WMI_10_2_PEER_160MHZ = 0x20000000
 };
 
 /*

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Valo, Kalle]

Michal Kazior <michal.kazior@tieto.com> writes:

> On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottschall@dd-wrt.com> wrote:
>> Attached you will find a testing patch for VHT160 support. i tested it today
>> on a QCA9984 device and it seems to work.
>> feel free to make any corrections
>
> Send patches inline, please. Preferably via git send-email. It's a lot
> easier to review them this way.

Also remember to read Developer's Certificate of Origin from
Documentation/SubmittingPatches and add Signed-off-by. Otherwise we
cannot use the patch.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Attached you will find a testing patch for VHT160 support. i tested it
> today on a QCA9984 device and it seems to work.
> feel free to make any corrections

Signed-off-by is missing so I can't take this. Can you resend, please?

Also remember to CC linux-wireless.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Sebastian Gottschall]

Am 14.09.2016 um 12:37 schrieb Valo, Kalle:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Attached you will find a testing patch for VHT160 support. i tested it
>> today on a QCA9984 device and it seems to work.
>> feel free to make any corrections
> Signed-off-by is missing so I can't take this. Can you resend, please
i can send you a updated version. it tested with vht160 so far. however. 
on codeaurore there is a newer firmware for 9984 which provides the 
correct vht flags straight from the firmware
but its crashing in vht160 mode. can you ask the firmware team to 
provide a bugfixed version for the official ath10k? with 80p80 and 
vht160 support?
80p80 works somewhat bug has wrong vht flags per station, vht160 works 
with my quirks so far which are all related to the buggy firmware
>
> Also remember to CC linux-wireless.
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: QCA9984 VHT160 support

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 14.09.2016 um 12:37 schrieb Valo, Kalle:
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> Attached you will find a testing patch for VHT160 support. i tested it
>>> today on a QCA9984 device and it seems to work.
>>> feel free to make any corrections
>> Signed-off-by is missing so I can't take this. Can you resend, please
>
> i can send you a updated version. it tested with vht160 so far.

Great, thanks.

> however. on codeaurore there is a newer firmware for 9984 which
> provides the correct vht flags straight from the firmware but its
> crashing in vht160 mode. can you ask the firmware team to provide a
> bugfixed version for the official ath10k? with 80p80 and vht160
> support? 80p80 works somewhat bug has wrong vht flags per station,
> vht160 works with my quirks so far which are all related to the buggy
> firmware

I can ask but I need more info. What's the exact location of the newer
firmware image? Is there any detailed description about the wrong vht
flags bug?

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH] QCA9984 VHT160 support

[Sebastian Gottschall]

[-- Attachment #1: Type: text/plain, Size: 234 bytes --]

This patch adds full VHT160 support for QCA9984 chipsets
Tested on Netgear R7800. 80+80 is possible, but disabled so far since it 
seems to contain glitches like missing vht station flags (this may be 
firmware or mac80211 related)



[-- Attachment #2: vht160.patch --]
[-- Type: text/plain, Size: 11408 bytes --]

From: Sebastian Gottschall <s.gottschall@dd-wrt.com>

Adds VHT160 support for 9984 Chipsets

Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3785a9..eb7b150 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -702,6 +702,10 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
 		/* 80MHZ */
 		case 2:
 			status->vht_flag |= RX_VHT_FLAG_80MHZ;
+			break;
+		case 3:
+			status->vht_flag |= RX_VHT_FLAG_160MHZ;
+			break;
 		}
 
 		status->flag |= RX_FLAG_VHT;
@@ -926,7 +930,7 @@ static void ath10k_process_rx(struct ath10k *ar,
 	*status = *rx_status;
 
 	ath10k_dbg(ar, ATH10K_DBG_DATA,
-		   "rx skb %pK len %u peer %pM %s %s sn %u %s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
+		   "rx skb %p len %u peer %pM %s %s sn %u %s%s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
 		   skb,
 		   skb->len,
 		   ieee80211_get_SA(hdr),
@@ -940,6 +944,7 @@ static void ath10k_process_rx(struct ath10k *ar,
 		   status->flag & RX_FLAG_VHT ? "vht" : "",
 		   status->flag & RX_FLAG_40MHZ ? "40" : "",
 		   status->vht_flag & RX_VHT_FLAG_80MHZ ? "80" : "",
+		   status->vht_flag & RX_VHT_FLAG_160MHZ ? "160" : "",
 		   status->flag & RX_FLAG_SHORT_GI ? "sgi " : "",
 		   status->rate_idx,
 		   status->vht_nss,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0a44dab..0b47d6d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -568,10 +568,14 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
 		case NL80211_CHAN_WIDTH_80:
 			phymode = MODE_11AC_VHT80;
 			break;
+		case NL80211_CHAN_WIDTH_160:
+			phymode = MODE_11AC_VHT160;
+			break;
+		case NL80211_CHAN_WIDTH_80P80:
+			phymode = MODE_11AC_VHT80_80;
+			break;
 		case NL80211_CHAN_WIDTH_5:
 		case NL80211_CHAN_WIDTH_10:
-		case NL80211_CHAN_WIDTH_80P80:
-		case NL80211_CHAN_WIDTH_160:
 			phymode = MODE_UNKNOWN;
 			break;
 		}
@@ -970,6 +974,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
 	arg.vdev_id = vdev_id;
 	arg.channel.freq = channel->center_freq;
 	arg.channel.band_center_freq1 = chandef->center_freq1;
+	arg.channel.band_center_freq2 = chandef->center_freq2;
 
 	/* TODO setup this dynamically, what in case we
 	   don't have any vifs? */
@@ -1381,6 +1386,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
 
 	arg.channel.freq = chandef->chan->center_freq;
 	arg.channel.band_center_freq1 = chandef->center_freq1;
+	arg.channel.band_center_freq2 = chandef->center_freq2;
 	arg.channel.mode = chan_to_phymode(chandef);
 
 	arg.channel.min_power = 0;
@@ -2444,6 +2450,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 	if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 		arg->peer_flags |= ar->wmi.peer_flags->bw80;
 
+	if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+		arg->peer_flags |= ar->wmi.peer_flags->bw160;
+
 	arg->peer_vht_rates.rx_max_rate =
 		__le16_to_cpu(vht_cap->vht_mcs.rx_highest);
 	arg->peer_vht_rates.rx_mcs_set =
@@ -2545,7 +2554,17 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
 		    !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
 			if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 				phymode = MODE_11AC_VHT80;
-			else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
+			else if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
+				phymode = MODE_11AC_VHT160;
+				switch (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
+				case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
+					phymode = MODE_11AC_VHT160;
+				break;
+				case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ:
+					phymode = MODE_11AC_VHT80_80;
+				break;
+				}
+			} else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
 				phymode = MODE_11AC_VHT40;
 			else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
 				phymode = MODE_11AC_VHT20;
@@ -4277,6 +4296,10 @@ static struct ieee80211_sta_vht_cap ath10k_create_vht_cap(struct ath10k *ar)
 		vht_cap.cap |= val;
 	}
 
+	if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) && !(ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)) {
+		vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
+	}
+
 	mcs_map = 0;
 	for (i = 0; i < 8; i++) {
 		if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
@@ -6913,6 +6936,9 @@ static void ath10k_sta_rc_update(struct ieee80211_hw *hw,
 			bw = WMI_PEER_CHWIDTH_80MHZ;
 			break;
 		case IEEE80211_STA_RX_BW_160:
+			bw = WMI_PEER_CHWIDTH_160MHZ;
+			break;
+		default:
 			ath10k_warn(ar, "Invalid bandwidth %d in rc update for %pM\n",
 				    sta->bandwidth, sta->addr);
 			bw = WMI_PEER_CHWIDTH_20MHZ;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e64f593..fb4c2cb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2468,7 +2468,7 @@ ath10k_wmi_tlv_op_gen_force_fw_hang(struct ath10k *ar,
 }
 
 static struct sk_buff *
-ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u64 module_enable,
+ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u32 module_enable,
 				 u32 log_level) {
 	struct wmi_tlv_dbglog_cmd *cmd;
 	struct wmi_tlv *tlv;
@@ -3560,6 +3560,7 @@ static const struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
 	.vht = WMI_TLV_PEER_VHT,
 	.bw80 = WMI_TLV_PEER_80MHZ,
 	.pmf = WMI_TLV_PEER_PMF,
+	.bw160 = WMI_TLV_PEER_160MHZ,
 };
 
 /************/
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index b8aa600..d0a6b92 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -543,6 +543,7 @@ enum wmi_tlv_peer_flags {
 	WMI_TLV_PEER_VHT = 0x02000000,
 	WMI_TLV_PEER_80MHZ = 0x04000000,
 	WMI_TLV_PEER_PMF = 0x08000000,
+        WMI_TLV_PEER_160MHZ = 0x20000000,
 };
 
 enum wmi_tlv_tag {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 38993d7..899f4cb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -28,6 +28,7 @@
 #include "wmi-ops.h"
 #include "p2p.h"
 #include "hw.h"
+#include "hif.h"
 
 #define ATH10K_WMI_BARRIER_ECHO_ID 0xBA991E9
 #define ATH10K_WMI_BARRIER_TIMEOUT_HZ (3 * HZ)
@@ -1576,6 +1577,7 @@ static const struct wmi_peer_flags_map wmi_peer_flags_map = {
 	.bw80 = WMI_PEER_80MHZ,
 	.vht_2g = WMI_PEER_VHT_2G,
 	.pmf = WMI_PEER_PMF,
+	.bw160 = WMI_PEER_160MHZ,
 };
 
 static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
@@ -1593,6 +1595,7 @@ static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
 	.spatial_mux = WMI_10X_PEER_SPATIAL_MUX,
 	.vht = WMI_10X_PEER_VHT,
 	.bw80 = WMI_10X_PEER_80MHZ,
+	.bw160 = WMI_10X_PEER_160MHZ,
 };
 
 static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
@@ -1612,6 +1615,7 @@ static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
 	.bw80 = WMI_10_2_PEER_80MHZ,
 	.vht_2g = WMI_10_2_PEER_VHT_2G,
 	.pmf = WMI_10_2_PEER_PMF,
+	.bw160 = WMI_10_2_PEER_160MHZ,
 };
 
 void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
@@ -1636,7 +1640,10 @@ void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
 
 	ch->mhz = __cpu_to_le32(arg->freq);
 	ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
-	ch->band_center_freq2 = 0;
+	if (arg->mode == MODE_11AC_VHT80_80)
+		ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
+	else
+		ch->band_center_freq2 = 0;
 	ch->min_power = arg->min_power;
 	ch->max_power = arg->max_power;
 	ch->reg_power = arg->max_reg_power;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 48e04b9..aa90c67 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1728,8 +1728,10 @@ enum wmi_phy_mode {
 	MODE_11AC_VHT20_2G = 11,
 	MODE_11AC_VHT40_2G = 12,
 	MODE_11AC_VHT80_2G = 13,
-	MODE_UNKNOWN    = 14,
-	MODE_MAX        = 14
+	MODE_11AC_VHT80_80 = 14,
+	MODE_11AC_VHT160 = 15,
+	MODE_UNKNOWN    = 16,
+	MODE_MAX        = 16
 };
 
 static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
@@ -1757,6 +1759,10 @@ static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
 		return "11ac-vht40";
 	case MODE_11AC_VHT80:
 		return "11ac-vht80";
+	case MODE_11AC_VHT160:
+		return "11ac-vht160";
+	case MODE_11AC_VHT80_80:
+		return "11ac-vht80+80";
 	case MODE_11AC_VHT20_2G:
 		return "11ac-vht20-2g";
 	case MODE_11AC_VHT40_2G:
@@ -1811,6 +1817,7 @@ struct wmi_channel {
 struct wmi_channel_arg {
 	u32 freq;
 	u32 band_center_freq1;
+	u32 band_center_freq2;
 	bool passive;
 	bool allow_ibss;
 	bool allow_ht;
@@ -1875,9 +1882,18 @@ enum wmi_channel_change_cause {
 #define WMI_VHT_CAP_MAX_MPDU_LEN_MASK            0x00000003
 #define WMI_VHT_CAP_RX_LDPC                      0x00000010
 #define WMI_VHT_CAP_SGI_80MHZ                    0x00000020
+#define WMI_VHT_CAP_SGI_160MHZ                   0x00000040
 #define WMI_VHT_CAP_TX_STBC                      0x00000080
 #define WMI_VHT_CAP_RX_STBC_MASK                 0x00000300
 #define WMI_VHT_CAP_RX_STBC_MASK_SHIFT           8
+#define WMI_VHT_CAP_SU_BFER                      0x00000800
+#define WMI_VHT_CAP_SU_BFEE                      0x00001000
+#define WMI_VHT_CAP_MAX_CS_ANT_MASK              0x0000E000
+#define WMI_VHT_CAP_MAX_CS_ANT_MASK_SHIFT        13
+#define WMI_VHT_CAP_MAX_SND_DIM_MASK             0x00070000
+#define WMI_VHT_CAP_MAX_SND_DIM_MASK_SHIFT       16
+#define WMI_VHT_CAP_MU_BFER                      0x00080000
+#define WMI_VHT_CAP_MU_BFEE                      0x00100000
 #define WMI_VHT_CAP_MAX_AMPDU_LEN_EXP            0x03800000
 #define WMI_VHT_CAP_MAX_AMPDU_LEN_EXP_SHIFT      23
 #define WMI_VHT_CAP_RX_FIXED_ANT                 0x10000000
@@ -1926,6 +1942,8 @@ enum {
 	REGDMN_MODE_11AC_VHT40PLUS   = 0x40000, /* 5Ghz, VHT40 + channels */
 	REGDMN_MODE_11AC_VHT40MINUS  = 0x80000, /* 5Ghz  VHT40 - channels */
 	REGDMN_MODE_11AC_VHT80       = 0x100000, /* 5Ghz, VHT80 channels */
+	REGDMN_MODE_11AC_VHT160      = 0x200000,     /* 5Ghz, VHT160 channels */
+	REGDMN_MODE_11AC_VHT80_80    = 0x400000,     /* 5Ghz, VHT80+80 channels */
 	REGDMN_MODE_ALL              = 0xffffffff
 };
 
@@ -5769,6 +5787,7 @@ enum wmi_peer_chwidth {
 	WMI_PEER_CHWIDTH_20MHZ = 0,
 	WMI_PEER_CHWIDTH_40MHZ = 1,
 	WMI_PEER_CHWIDTH_80MHZ = 2,
+	WMI_PEER_CHWIDTH_160MHZ = 3,
 };
 
 enum wmi_peer_param {
@@ -5859,6 +5878,7 @@ struct wmi_peer_flags_map {
 	u32 bw80;
 	u32 vht_2g;
 	u32 pmf;
+	u32 bw160;
 };
 
 enum wmi_peer_flags {
@@ -5878,6 +5898,7 @@ enum wmi_peer_flags {
 	WMI_PEER_80MHZ = 0x04000000,
 	WMI_PEER_VHT_2G = 0x08000000,
 	WMI_PEER_PMF = 0x10000000,
+	WMI_PEER_160MHZ = 0x20000000
 };
 
 enum wmi_10x_peer_flags {
@@ -5895,6 +5916,7 @@ enum wmi_10x_peer_flags {
 	WMI_10X_PEER_SPATIAL_MUX = 0x00200000,
 	WMI_10X_PEER_VHT = 0x02000000,
 	WMI_10X_PEER_80MHZ = 0x04000000,
+	WMI_10X_PEER_160MHZ = 0x20000000
 };
 
 enum wmi_10_2_peer_flags {
@@ -5914,6 +5936,7 @@ enum wmi_10_2_peer_flags {
 	WMI_10_2_PEER_80MHZ = 0x04000000,
 	WMI_10_2_PEER_VHT_2G = 0x08000000,
 	WMI_10_2_PEER_PMF = 0x10000000,
+	WMI_10_2_PEER_160MHZ = 0x20000000
 };
 
 /*

[-- Attachment #3: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

unusual event

[Sebastian Gottschall]

unusual event

latest ath10k version brings up the following issue on qca9984


[70300.488428] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70300.693091] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70300.897865] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70301.102779] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70301.307574] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70301.512389] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70301.717181] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70301.921989] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70302.126803] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70302.331583] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
root@apreithalle:~#  0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70295.368301] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70295.573106] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70295.777898] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70295.982745] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70296.187537] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70296.392354] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70296.597152] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode
[70296.801958] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind 
event: in push mode

>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> This patch adds full VHT160 support for QCA9984 chipsets
> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
> it seems to contain glitches like missing vht station flags (this may
> be firmware or mac80211 related)

There are some compilation and checkpatch warnings. Also you forgot to
CC linux-wireless and sent the patch as an attachment. I'll send v2 to
fix those.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Valo, Kalle]

Kalle Valo <kvalo@qca.qualcomm.com> writes:

> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> This patch adds full VHT160 support for QCA9984 chipsets
>> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
>> it seems to contain glitches like missing vht station flags (this may
>> be firmware or mac80211 related)
>
> There are some compilation and checkpatch warnings. Also you forgot to
> CC linux-wireless and sent the patch as an attachment. I'll send v2 to
> fix those.

Forgot the actual warnings:

drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:2: warning: (near initialization for 'wmi_tlv_ops.gen_dbglog_cfg') [enabled by default]
drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27: warning: incorrect type in initializer (incompatible argument 2 (different type sizes))
drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27:    expected struct sk_buff *( *gen_dbglog_cfg )( ... )
drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27:    got struct sk_buff *( static [toplevel] *<noident> )( ... )
drivers/net/wireless/ath/ath10k/wmi-tlv.h:546: code indent should use tabs where possible
drivers/net/wireless/ath/ath10k/wmi-tlv.h:546: please, no spaces at the start of a line
drivers/net/wireless/ath/ath10k/mac.c:2556: braces {} should be used on all arms of this statement
drivers/net/wireless/ath/ath10k/mac.c:2560: line over 90 characters
drivers/net/wireless/ath/ath10k/mac.c:4301: line over 90 characters
drivers/net/wireless/ath/ath10k/mac.c:4301: braces {} are not necessary for single statement blocks

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Sebastian Gottschall]

Am 10.10.2016 um 18:06 schrieb Valo, Kalle:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> This patch adds full VHT160 support for QCA9984 chipsets
>>> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
>>> it seems to contain glitches like missing vht station flags (this may
>>> be firmware or mac80211 related)
>> There are some compilation and checkpatch warnings. Also you forgot to
>> CC linux-wireless and sent the patch as an attachment. I'll send v2 to
>> fix those.
gen_dbglog_cfg? i did not touch anything on this struct in my patch. 
this warning doesnt seem to belong to my patch
> Forgot the actual warnings:
>
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:2: warning: (near initialization for 'wmi_tlv_ops.gen_dbglog_cfg') [enabled by default]
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27: warning: incorrect type in initializer (incompatible argument 2 (different type sizes))
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27:    expected struct sk_buff *( *gen_dbglog_cfg )( ... )
> drivers/net/wireless/ath/ath10k/wmi-tlv.c:3520:27:    got struct sk_buff *( static [toplevel] *<noident> )( ... )
> drivers/net/wireless/ath/ath10k/wmi-tlv.h:546: code indent should use tabs where possible
> drivers/net/wireless/ath/ath10k/wmi-tlv.h:546: please, no spaces at the start of a line
> drivers/net/wireless/ath/ath10k/mac.c:2556: braces {} should be used on all arms of this statement
> drivers/net/wireless/ath/ath10k/mac.c:2560: line over 90 characters
> drivers/net/wireless/ath/ath10k/mac.c:4301: line over 90 characters
> drivers/net/wireless/ath/ath10k/mac.c:4301: braces {} are not necessary for single statement blocks
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> Am 10.10.2016 um 18:06 schrieb Valo, Kalle:
>> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>>
>>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>>
>>>> This patch adds full VHT160 support for QCA9984 chipsets
>>>> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
>>>> it seems to contain glitches like missing vht station flags (this may
>>>> be firmware or mac80211 related)
>>> There are some compilation and checkpatch warnings. Also you forgot to
>>> CC linux-wireless and sent the patch as an attachment. I'll send v2 to
>>> fix those.
>
> gen_dbglog_cfg? i did not touch anything on this struct in my patch.
> this warning doesnt seem to belong to my patch

According to patchwork you did, see below. Most likely just merge damage
from rebasing, I fixed it in v2.

--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2468,7 +2468,7 @@  ath10k_wmi_tlv_op_gen_force_fw_hang(struct ath10k *ar,
 }
 
 static struct sk_buff *
-ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u64 module_enable,
+ath10k_wmi_tlv_op_gen_dbglog_cfg(struct ath10k *ar, u32 module_enable,
 				 u32 log_level) {
 	struct wmi_tlv_dbglog_cmd *cmd;
 	struct wmi_tlv *tlv;

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Valo, Kalle]

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> This patch adds full VHT160 support for QCA9984 chipsets
> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
> it seems to contain glitches like missing vht station flags (this may
> be firmware or mac80211 related)

So how did you disable 80+80 exactly? I can't find it and I would like
to add a comment to the code so that it's easy to enable it later (once
it's working).

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Sebastian Gottschall]

Am 14.10.2016 um 12:14 schrieb Valo, Kalle:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> This patch adds full VHT160 support for QCA9984 chipsets
>> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
>> it seems to contain glitches like missing vht station flags (this may
>> be firmware or mac80211 related)
> So how did you disable 80+80 exactly? I can't find it and I would like
> to add a comment to the code so that it's easy to enable it later (once
> it's working).


IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ  =vht160 only
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ = vht160 and 80+80 
support

+    if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
+        !(ar->vht_cap_info & 
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ))
+        vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
+

so if the firmware itself doesnt contain the correct vht flags but just 
short_gi_160 flag. i assume it supports vht160 and set the vht160 only 
flag.
newer firmwares on codeaurora contain the correct flags. so this code 
here gets avoided. unfortunatly the newer i found is also not stable and 
crashes often.
you can also enable 80+80 support with the current firmware.but all 
station ht and vht flags seem to be empty then in vht160 mode too. so it 
might be a firmware issue still with 80+80 or mac80211.
i did not debug that much. but vht160 works. i also tested it now with a 
88w6964 marvell client in vht160 which worked too


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH] QCA9984 VHT160 support

[Sebastian Gottschall]

i've seen you added a new firmware for 9984. is there anything you can 
tell about already?

Am 18.10.2016 um 10:20 schrieb Sebastian Gottschall:
> Am 14.10.2016 um 12:14 schrieb Valo, Kalle:
>> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>>
>>> This patch adds full VHT160 support for QCA9984 chipsets
>>> Tested on Netgear R7800. 80+80 is possible, but disabled so far since
>>> it seems to contain glitches like missing vht station flags (this may
>>> be firmware or mac80211 related)
>> So how did you disable 80+80 exactly? I can't find it and I would like
>> to add a comment to the code so that it's easy to enable it later (once
>> it's working).
>
>
> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ  =vht160 only
> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ = vht160 and 80+80 
> support
>
> +    if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
> +        !(ar->vht_cap_info & 
> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ))
> +        vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
> +
>
> so if the firmware itself doesnt contain the correct vht flags but 
> just short_gi_160 flag. i assume it supports vht160 and set the vht160 
> only flag.
> newer firmwares on codeaurora contain the correct flags. so this code 
> here gets avoided. unfortunatly the newer i found is also not stable 
> and crashes often.
> you can also enable 80+80 support with the current firmware.but all 
> station ht and vht flags seem to be empty then in vht160 mode too. so 
> it might be a firmware issue still with 80+80 or mac80211.
> i did not debug that much. but vht160 works. i also tested it now with 
> a 88w6964 marvell client in vht160 which worked too
>
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k