* Setting per-frame tx rate for frames injected in raw tx mode @ 2016-05-10 6:11 Raj Joshi 2016-05-10 16:28 ` Ben Greear 0 siblings, 1 reply; 28+ messages in thread From: Raj Joshi @ 2016-05-10 6:11 UTC (permalink / raw) To: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-10 6:11 Setting per-frame tx rate for frames injected in raw tx mode Raj Joshi @ 2016-05-10 16:28 ` Ben Greear 2016-05-11 6:41 ` Raj Joshi 0 siblings, 1 reply; 28+ messages in thread From: Ben Greear @ 2016-05-10 16:28 UTC (permalink / raw) To: Raj Joshi, ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-10 16:28 ` Ben Greear @ 2016-05-11 6:41 ` Raj Joshi 2016-05-11 16:13 ` Ben Greear 0 siblings, 1 reply; 28+ messages in thread From: Raj Joshi @ 2016-05-11 6:41 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-11 6:41 ` Raj Joshi @ 2016-05-11 16:13 ` Ben Greear 2016-05-15 2:40 ` Raj Joshi 0 siblings, 1 reply; 28+ messages in thread From: Ben Greear @ 2016-05-11 16:13 UTC (permalink / raw) To: Raj Joshi; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-11 16:13 ` Ben Greear @ 2016-05-15 2:40 ` Raj Joshi 2016-05-15 15:17 ` Ben Greear 0 siblings, 1 reply; 28+ messages in thread From: Raj Joshi @ 2016-05-15 2:40 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-15 2:40 ` Raj Joshi @ 2016-05-15 15:17 ` Ben Greear 2016-05-15 17:15 ` Ben Greear 0 siblings, 1 reply; 28+ messages in thread From: Ben Greear @ 2016-05-15 15:17 UTC (permalink / raw) To: Raj Joshi; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-15 15:17 ` Ben Greear @ 2016-05-15 17:15 ` Ben Greear 2016-05-17 7:14 ` Raj Joshi 0 siblings, 1 reply; 28+ messages in thread From: Ben Greear @ 2016-05-15 17:15 UTC (permalink / raw) To: Raj Joshi; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-15 17:15 ` Ben Greear @ 2016-05-17 7:14 ` Raj Joshi 2016-05-17 7:36 ` Michal Kazior 2016-05-17 7:43 ` Valo, Kalle 0 siblings, 2 replies; 28+ messages in thread From: Raj Joshi @ 2016-05-17 7:14 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-17 7:14 ` Raj Joshi @ 2016-05-17 7:36 ` Michal Kazior 2016-05-17 7:43 ` Valo, Kalle 1 sibling, 0 replies; 28+ messages in thread From: Michal Kazior @ 2016-05-17 7:36 UTC (permalink / raw) To: Raj Joshi; +Cc: Ben Greear, ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Setting per-frame tx rate for frames injected in raw tx mode 2016-05-17 7:14 ` Raj Joshi 2016-05-17 7:36 ` Michal Kazior @ 2016-05-17 7:43 ` Valo, Kalle 2016-05-17 11:43 ` QCA9984 VHT160 support Sebastian Gottschall 1 sibling, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-05-17 7:43 UTC (permalink / raw) To: Raj Joshi; +Cc: Ben Greear, ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* QCA9984 VHT160 support 2016-05-17 7:43 ` Valo, Kalle @ 2016-05-17 11:43 ` Sebastian Gottschall 2016-05-17 12:00 ` Michal Kazior 2016-09-14 10:37 ` Valo, Kalle 0 siblings, 2 replies; 28+ messages in thread From: Sebastian Gottschall @ 2016-05-17 11:43 UTC (permalink / raw) To: ath10k [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-05-17 11:43 ` QCA9984 VHT160 support Sebastian Gottschall @ 2016-05-17 12:00 ` Michal Kazior [not found] ` <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com> 2016-05-17 13:20 ` Valo, Kalle 2016-09-14 10:37 ` Valo, Kalle 1 sibling, 2 replies; 28+ messages in thread From: Michal Kazior @ 2016-05-17 12:00 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com>]
* Re: QCA9984 VHT160 support [not found] ` <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com> @ 2016-05-17 12:18 ` Michal Kazior 2016-05-17 12:22 ` Sebastian Gottschall 0 siblings, 1 reply; 28+ messages in thread From: Michal Kazior @ 2016-05-17 12:18 UTC (permalink / raw) To: Sebastian Gottschall, ath10k + 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-05-17 12:18 ` Michal Kazior @ 2016-05-17 12:22 ` Sebastian Gottschall 2016-05-17 12:35 ` Sebastian Gottschall 0 siblings, 1 reply; 28+ messages in thread From: Sebastian Gottschall @ 2016-05-17 12:22 UTC (permalink / raw) To: Michal Kazior, ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-05-17 12:22 ` Sebastian Gottschall @ 2016-05-17 12:35 ` Sebastian Gottschall 0 siblings, 0 replies; 28+ messages in thread From: Sebastian Gottschall @ 2016-05-17 12:35 UTC (permalink / raw) To: ath10k [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-05-17 12:00 ` Michal Kazior [not found] ` <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com> @ 2016-05-17 13:20 ` Valo, Kalle 1 sibling, 0 replies; 28+ messages in thread From: Valo, Kalle @ 2016-05-17 13:20 UTC (permalink / raw) To: michal.kazior; +Cc: ath10k, Sebastian Gottschall 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-05-17 11:43 ` QCA9984 VHT160 support Sebastian Gottschall 2016-05-17 12:00 ` Michal Kazior @ 2016-09-14 10:37 ` Valo, Kalle 2016-09-14 14:38 ` Sebastian Gottschall 1 sibling, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-09-14 10:37 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-09-14 10:37 ` Valo, Kalle @ 2016-09-14 14:38 ` Sebastian Gottschall 2016-09-14 14:44 ` Valo, Kalle 0 siblings, 1 reply; 28+ messages in thread From: Sebastian Gottschall @ 2016-09-14 14:38 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: QCA9984 VHT160 support 2016-09-14 14:38 ` Sebastian Gottschall @ 2016-09-14 14:44 ` Valo, Kalle 2016-09-16 7:51 ` [PATCH] " Sebastian Gottschall 0 siblings, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-09-14 14:44 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH] QCA9984 VHT160 support 2016-09-14 14:44 ` Valo, Kalle @ 2016-09-16 7:51 ` Sebastian Gottschall 2016-09-17 6:21 ` unusual event Sebastian Gottschall ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Sebastian Gottschall @ 2016-09-16 7:51 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k [-- 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 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* unusual event 2016-09-16 7:51 ` [PATCH] " Sebastian Gottschall @ 2016-09-17 6:21 ` Sebastian Gottschall 2016-10-10 16:04 ` [PATCH] QCA9984 VHT160 support Valo, Kalle 2016-10-14 10:14 ` Valo, Kalle 2 siblings, 0 replies; 28+ messages in thread From: Sebastian Gottschall @ 2016-09-17 6:21 UTC (permalink / raw) To: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-09-16 7:51 ` [PATCH] " Sebastian Gottschall 2016-09-17 6:21 ` unusual event Sebastian Gottschall @ 2016-10-10 16:04 ` Valo, Kalle 2016-10-10 16:06 ` Valo, Kalle 2016-10-14 10:14 ` Valo, Kalle 2 siblings, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-10-10 16:04 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-10-10 16:04 ` [PATCH] QCA9984 VHT160 support Valo, Kalle @ 2016-10-10 16:06 ` Valo, Kalle 2016-10-11 1:30 ` Sebastian Gottschall 0 siblings, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-10-10 16:06 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-10-10 16:06 ` Valo, Kalle @ 2016-10-11 1:30 ` Sebastian Gottschall 2016-10-14 10:06 ` Valo, Kalle 0 siblings, 1 reply; 28+ messages in thread From: Sebastian Gottschall @ 2016-10-11 1:30 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-10-11 1:30 ` Sebastian Gottschall @ 2016-10-14 10:06 ` Valo, Kalle 0 siblings, 0 replies; 28+ messages in thread From: Valo, Kalle @ 2016-10-14 10:06 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-09-16 7:51 ` [PATCH] " Sebastian Gottschall 2016-09-17 6:21 ` unusual event Sebastian Gottschall 2016-10-10 16:04 ` [PATCH] QCA9984 VHT160 support Valo, Kalle @ 2016-10-14 10:14 ` Valo, Kalle 2016-10-18 8:20 ` Sebastian Gottschall 2 siblings, 1 reply; 28+ messages in thread From: Valo, Kalle @ 2016-10-14 10:14 UTC (permalink / raw) To: Sebastian Gottschall; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-10-14 10:14 ` Valo, Kalle @ 2016-10-18 8:20 ` Sebastian Gottschall 2016-10-18 9:16 ` Sebastian Gottschall 0 siblings, 1 reply; 28+ messages in thread From: Sebastian Gottschall @ 2016-10-18 8:20 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] QCA9984 VHT160 support 2016-10-18 8:20 ` Sebastian Gottschall @ 2016-10-18 9:16 ` Sebastian Gottschall 0 siblings, 0 replies; 28+ messages in thread From: Sebastian Gottschall @ 2016-10-18 9:16 UTC (permalink / raw) To: Valo, Kalle; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2016-10-18 9:23 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-10 6:11 Setting per-frame tx rate for frames injected in raw tx mode Raj Joshi 2016-05-10 16:28 ` Ben Greear 2016-05-11 6:41 ` Raj Joshi 2016-05-11 16:13 ` Ben Greear 2016-05-15 2:40 ` Raj Joshi 2016-05-15 15:17 ` Ben Greear 2016-05-15 17:15 ` Ben Greear 2016-05-17 7:14 ` Raj Joshi 2016-05-17 7:36 ` Michal Kazior 2016-05-17 7:43 ` Valo, Kalle 2016-05-17 11:43 ` QCA9984 VHT160 support Sebastian Gottschall 2016-05-17 12:00 ` Michal Kazior [not found] ` <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com> 2016-05-17 12:18 ` Michal Kazior 2016-05-17 12:22 ` Sebastian Gottschall 2016-05-17 12:35 ` Sebastian Gottschall 2016-05-17 13:20 ` Valo, Kalle 2016-09-14 10:37 ` Valo, Kalle 2016-09-14 14:38 ` Sebastian Gottschall 2016-09-14 14:44 ` Valo, Kalle 2016-09-16 7:51 ` [PATCH] " Sebastian Gottschall 2016-09-17 6:21 ` unusual event Sebastian Gottschall 2016-10-10 16:04 ` [PATCH] QCA9984 VHT160 support Valo, Kalle 2016-10-10 16:06 ` Valo, Kalle 2016-10-11 1:30 ` Sebastian Gottschall 2016-10-14 10:06 ` Valo, Kalle 2016-10-14 10:14 ` Valo, Kalle 2016-10-18 8:20 ` Sebastian Gottschall 2016-10-18 9:16 ` Sebastian Gottschall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.