IBSS support in ath10k - our test results and questions

IBSS support in ath10k - our test results and questions

[Simon Wunderlich]

Hi ath10k devs,

since there has been quite a bit of progress on IBSS in ath10k, we've been 
trying to integrate it into our OpenWRT based firmware and test it. Since there 
seems to be many people interested, I'd like to share our status and also ask 
for comments and support on current issues:

 * Our test was based on Ben Greears firmware v 13, OpenWRT rev 44654 and 
various patches (see details below at [1])
 * We can set up IBSS networks without problems, at least without IBSS/RSN 
encryption
 * AP+IBSS simultaneously works somewhat, but with quirks
 * We see low throughput when communicating via IBSS between 2x ath10k or 1x 
ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150 MBit/s, 
with VHT even more.
 * We tracked down the reason to be aggregation not working - ath10k never 
sends ADDBA, and also does not respond to ADDBAs sent by ath9k
 * Aggregation works just fine in AP mode in ath10k

Therefore, I'd like to know if anyone has experience with Bens firmware and 
IBSS mode and can point us to existing issues/fixes, or recommend versions to 
test which are supposed to work. We had to add various VHT patches by hand, so 
we wonder if anyone had success with that yet, but even the HT performance is 
far from satisfactory.

Note that we also tried firmware 999.999.0.636 firmware and got better 
performance (70-90 MBit/s), but since it does not properly support AP it's not 
an option for us.

There are also a few other issues (IBSS/RSN not working - ath10k firmware does 
not seem to support software encryption properly ; IBSS+AP has spurious AP 
issues with a lot of packetloss), but that would be a topic for another time. 
Maybe we are just missing the right versions here ... :)

Thanks!!
    Simon



[1] Our components and software versions:
 * the devices were ath9k 2x2 (HT40), ath10k 2x2 (VHT80)
 * Ben Greears firmware 13 (all variants)
 * OpenWrt 44654
 * all ath10k patches between f3660a25c4ff15c10c197930b5e039311a25b477
   (master-2014-11-04) and v3.19
 * patches from git://dmz2.candelatech.com/linux-3.19.dev.y starting with
   3.19 and ending at lf-5.3.1 (patches for NFS, PCI, igb, ARM, hwmon,
   configs, ath9k, neigh, cifs, aesni, hwsim and vlan were dropped)
 * some patches to work around build errors in Ben Greears patches
 * a revert of "ath10k: Request OTP to return debug code." because it didn't
   work with his firmware on the target platform
 * patch "cfg80211: add extensible feature flag attribute"
 * patch "cfg80211: add VHT support for IBSS"
 * patch "mac80211: IBSS fix scan request"
 * Revert "mac80211: notify NSS changed when IBSS and HT"
   (required to update to the latest available patch)
 * "mac80211: notify NSS changed when IBSS and HT"
   (from http://mid.gmane.org/1418806852-558-1-git-send-email-janusz.dziedzic@tieto.com )

Most likely not relevant because it is just for the VHT support in IBSS
and the problem was already there before adding these patches

 * "mac80211: ibss refactor ieee80211_rx_bss_info"
 * "mac80211: tdls: disentangle HT supported conditions"
 * "mac80211: TDLS: support VHT between peers"
 * "mac80211: add VHT support for IBSS"
 * a patch to synchronize include/uapi/linux/nl80211.h with the version
   shipped by iw from OpenWrt 44654
 * a patch in ath10k to enable NL80211_EXT_FEATURE_VHT_IBSS
 * a patch to disable SMPS STATIC to get multiple chains HT MCS rates
   when communicating with ath9k
 * a patch to set a VHT channel when using "ibss join"
 * some patches to test things like encryption, trace wmi, ...
 * some patches to automatically install the CT community firmware using
   OpenWrt

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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

On 03/19/2015 10:06 AM, Simon Wunderlich wrote:
> Hi ath10k devs,
> 
> since there has been quite a bit of progress on IBSS in ath10k, we've been 
> trying to integrate it into our OpenWRT based firmware and test it. Since there 
> seems to be many people interested, I'd like to share our status and also ask 
> for comments and support on current issues:
> 
>  * Our test was based on Ben Greears firmware v 13, OpenWRT rev 44654 and 
> various patches (see details below at [1])
>  * We can set up IBSS networks without problems, at least without IBSS/RSN 
> encryption
>  * AP+IBSS simultaneously works somewhat, but with quirks
>  * We see low throughput when communicating via IBSS between 2x ath10k or 1x 
> ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150 MBit/s, 
> with VHT even more.

Do you see this problem with only an IBSS interface?  In other words, is my
firmware worse at this than stock 999.x firmware in same configuration?

Thanks for all the details...  Sounds like you have done more testing on this
than I have for sure.

In case you have a public kernel tree available somewhere with all your patches,
that might help speed up someone's attempt to reproduce this?

Thanks,
Ben


>  * We tracked down the reason to be aggregation not working - ath10k never 
> sends ADDBA, and also does not respond to ADDBAs sent by ath9k
>  * Aggregation works just fine in AP mode in ath10k
> 
> Therefore, I'd like to know if anyone has experience with Bens firmware and 
> IBSS mode and can point us to existing issues/fixes, or recommend versions to 
> test which are supposed to work. We had to add various VHT patches by hand, so 
> we wonder if anyone had success with that yet, but even the HT performance is 
> far from satisfactory.
> 
> Note that we also tried firmware 999.999.0.636 firmware and got better 
> performance (70-90 MBit/s), but since it does not properly support AP it's not 
> an option for us.
> 
> There are also a few other issues (IBSS/RSN not working - ath10k firmware does 
> not seem to support software encryption properly ; IBSS+AP has spurious AP 
> issues with a lot of packetloss), but that would be a topic for another time. 
> Maybe we are just missing the right versions here ... :)
> 
> Thanks!!
>     Simon
> 
> 
> 
> [1] Our components and software versions:
>  * the devices were ath9k 2x2 (HT40), ath10k 2x2 (VHT80)
>  * Ben Greears firmware 13 (all variants)
>  * OpenWrt 44654
>  * all ath10k patches between f3660a25c4ff15c10c197930b5e039311a25b477
>    (master-2014-11-04) and v3.19
>  * patches from git://dmz2.candelatech.com/linux-3.19.dev.y starting with
>    3.19 and ending at lf-5.3.1 (patches for NFS, PCI, igb, ARM, hwmon,
>    configs, ath9k, neigh, cifs, aesni, hwsim and vlan were dropped)
>  * some patches to work around build errors in Ben Greears patches
>  * a revert of "ath10k: Request OTP to return debug code." because it didn't
>    work with his firmware on the target platform
>  * patch "cfg80211: add extensible feature flag attribute"
>  * patch "cfg80211: add VHT support for IBSS"
>  * patch "mac80211: IBSS fix scan request"
>  * Revert "mac80211: notify NSS changed when IBSS and HT"
>    (required to update to the latest available patch)
>  * "mac80211: notify NSS changed when IBSS and HT"
>    (from http://mid.gmane.org/1418806852-558-1-git-send-email-janusz.dziedzic@tieto.com )
> 
> Most likely not relevant because it is just for the VHT support in IBSS
> and the problem was already there before adding these patches
> 
>  * "mac80211: ibss refactor ieee80211_rx_bss_info"
>  * "mac80211: tdls: disentangle HT supported conditions"
>  * "mac80211: TDLS: support VHT between peers"
>  * "mac80211: add VHT support for IBSS"
>  * a patch to synchronize include/uapi/linux/nl80211.h with the version
>    shipped by iw from OpenWrt 44654
>  * a patch in ath10k to enable NL80211_EXT_FEATURE_VHT_IBSS
>  * a patch to disable SMPS STATIC to get multiple chains HT MCS rates
>    when communicating with ath9k
>  * a patch to set a VHT channel when using "ibss join"
>  * some patches to test things like encryption, trace wmi, ...
>  * some patches to automatically install the CT community firmware using
>    OpenWrt
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


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


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

Re: IBSS support in ath10k - our test results and questions

[Janusz Dziedzic]

On 19 March 2015 at 22:40, Ben Greear <greearb@candelatech.com> wrote:
> On 03/19/2015 10:06 AM, Simon Wunderlich wrote:
>> Hi ath10k devs,
>>
>> since there has been quite a bit of progress on IBSS in ath10k, we've been
>> trying to integrate it into our OpenWRT based firmware and test it. Since there
>> seems to be many people interested, I'd like to share our status and also ask
>> for comments and support on current issues:
>>
>>  * Our test was based on Ben Greears firmware v 13, OpenWRT rev 44654 and
>> various patches (see details below at [1])
>>  * We can set up IBSS networks without problems, at least without IBSS/RSN
>> encryption
>>  * AP+IBSS simultaneously works somewhat, but with quirks
>>  * We see low throughput when communicating via IBSS between 2x ath10k or 1x
>> ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150 MBit/s,
>> with VHT even more.
>
> Do you see this problem with only an IBSS interface?  In other words, is my
> firmware worse at this than stock 999.x firmware in same configuration?
>

This is results I get today morning.
This is for ath9k - HT40

janusz@dell6430:~/work/tools/test$ stdbuf -o 0 ./ibss.py t2-ath9k
t3-ath9k 5745 |grep "TC RESULT"
TC RESULT - t2-ath9k >> t3-ath9k pkt loss: 0%
TC RESULT - t2-ath9k >> t3-ath9k pkt loss: 0%
TC RESULT - parallel ping
TC RESULT - pkt_loss t2-ath9k 0%
TC RESULT - pkt_loss t3-ath9k 0%
TC RESULT - (udp) t3-ath9k >>>> t2-ath9k speed: 245 Mbits/sec
TC RESULT - (tcp) t3-ath9k >>>> t2-ath9k speed: 149 Mbits/sec
TC RESULT - (udp) t2-ath9k >>>> t3-ath9k speed: 246 Mbits/sec
TC RESULT - (tcp) t2-ath9k >>>> t3-ath9k speed: 151 Mbits/sec
TC RESULT - --------dual---------------------------------
TC RESULT - (tcp) - t2-ath9k >>> t3-ath9k: 70.8 Mbits/sec
TC RESULT - (tcp) - t3-ath9k >>> t2-ath9k: 88.3 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (tcp) - t2-ath9k >>> t3-ath9k: 21.0 Mbits/sec
TC RESULT - (udp) - t3-ath9k >>> t2-ath9k: 185 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (udp) - t2-ath9k >>> t3-ath9k: 183 Mbits/sec
TC RESULT - (tcp) - t3-ath9k >>> t2-ath9k: 21.9 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (udp) - t2-ath9k >>> t3-ath9k: 116 Mbits/sec
TC RESULT - (udp) - t3-ath9k >>> t2-ath9k: 122 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT -  ./ibss.py t2-ath9k t3-ath9k 5745 - PASS

And ath10k - VHT80 - firmware 636

janusz@dell6430:~/work/tools/test$ stdbuf -o 0 ./ibss.py t2-ath10k
t3-ath10k 5745 |grep "TC RESULT"
TC RESULT - t2-ath10k >> t3-ath10k pkt loss: 0%
TC RESULT - t2-ath10k >> t3-ath10k pkt loss: 0%
TC RESULT - parallel ping
TC RESULT - pkt_loss t2-ath10k 0%
TC RESULT - pkt_loss t3-ath10k 0%
TC RESULT - (udp) t3-ath10k >>>> t2-ath10k speed: 409 Mbits/sec
TC RESULT - (tcp) t3-ath10k >>>> t2-ath10k speed: 248 Mbits/sec
TC RESULT - (udp) t2-ath10k >>>> t3-ath10k speed: 506 Mbits/sec
TC RESULT - (tcp) t2-ath10k >>>> t3-ath10k speed: 349 Mbits/sec
TC RESULT - --------dual---------------------------------
TC RESULT - (tcp) - t2-ath10k >>> t3-ath10k: 144 Mbits/sec
TC RESULT - (tcp) - t3-ath10k >>> t2-ath10k: 98.8 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (tcp) - t2-ath10k >>> t3-ath10k: 28.2 Mbits/sec
TC RESULT - (udp) - t3-ath10k >>> t2-ath10k: 371 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (udp) - t2-ath10k >>> t3-ath10k: 307 Mbits/sec
TC RESULT - (tcp) - t3-ath10k >>> t2-ath10k: 18.2 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT - --------dual---------------------------------
TC RESULT - (udp) - t2-ath10k >>> t3-ath10k: 221 Mbits/sec
TC RESULT - (udp) - t3-ath10k >>> t2-ath10k: 216 Mbits/sec
TC RESULT - ---------------------------------------------
TC RESULT -  ./ibss.py t2-ath10k t3-ath10k 5745 - PASS

Regarding IBSS/RSN and 636 firmware, this works sometimes (ath10k
patch required here).
But in case this don't work firmware don't send EAPOL frames - I think
this is main problem ...

BR
Janusz

> Thanks for all the details...  Sounds like you have done more testing on this
> than I have for sure.
>
> In case you have a public kernel tree available somewhere with all your patches,
> that might help speed up someone's attempt to reproduce this?
>
> Thanks,
> Ben
>
>
>>  * We tracked down the reason to be aggregation not working - ath10k never
>> sends ADDBA, and also does not respond to ADDBAs sent by ath9k
>>  * Aggregation works just fine in AP mode in ath10k
>>
>> Therefore, I'd like to know if anyone has experience with Bens firmware and
>> IBSS mode and can point us to existing issues/fixes, or recommend versions to
>> test which are supposed to work. We had to add various VHT patches by hand, so
>> we wonder if anyone had success with that yet, but even the HT performance is
>> far from satisfactory.
>>
>> Note that we also tried firmware 999.999.0.636 firmware and got better
>> performance (70-90 MBit/s), but since it does not properly support AP it's not
>> an option for us.
>>
>> There are also a few other issues (IBSS/RSN not working - ath10k firmware does
>> not seem to support software encryption properly ; IBSS+AP has spurious AP
>> issues with a lot of packetloss), but that would be a topic for another time.
>> Maybe we are just missing the right versions here ... :)
>>
>> Thanks!!
>>     Simon
>>
>>
>>
>> [1] Our components and software versions:
>>  * the devices were ath9k 2x2 (HT40), ath10k 2x2 (VHT80)
>>  * Ben Greears firmware 13 (all variants)
>>  * OpenWrt 44654
>>  * all ath10k patches between f3660a25c4ff15c10c197930b5e039311a25b477
>>    (master-2014-11-04) and v3.19
>>  * patches from git://dmz2.candelatech.com/linux-3.19.dev.y starting with
>>    3.19 and ending at lf-5.3.1 (patches for NFS, PCI, igb, ARM, hwmon,
>>    configs, ath9k, neigh, cifs, aesni, hwsim and vlan were dropped)
>>  * some patches to work around build errors in Ben Greears patches
>>  * a revert of "ath10k: Request OTP to return debug code." because it didn't
>>    work with his firmware on the target platform
>>  * patch "cfg80211: add extensible feature flag attribute"
>>  * patch "cfg80211: add VHT support for IBSS"
>>  * patch "mac80211: IBSS fix scan request"
>>  * Revert "mac80211: notify NSS changed when IBSS and HT"
>>    (required to update to the latest available patch)
>>  * "mac80211: notify NSS changed when IBSS and HT"
>>    (from http://mid.gmane.org/1418806852-558-1-git-send-email-janusz.dziedzic@tieto.com )
>>
>> Most likely not relevant because it is just for the VHT support in IBSS
>> and the problem was already there before adding these patches
>>
>>  * "mac80211: ibss refactor ieee80211_rx_bss_info"
>>  * "mac80211: tdls: disentangle HT supported conditions"
>>  * "mac80211: TDLS: support VHT between peers"
>>  * "mac80211: add VHT support for IBSS"
>>  * a patch to synchronize include/uapi/linux/nl80211.h with the version
>>    shipped by iw from OpenWrt 44654
>>  * a patch in ath10k to enable NL80211_EXT_FEATURE_VHT_IBSS
>>  * a patch to disable SMPS STATIC to get multiple chains HT MCS rates
>>    when communicating with ath9k
>>  * a patch to set a VHT channel when using "ibss join"
>>  * some patches to test things like encryption, trace wmi, ...
>>  * some patches to automatically install the CT community firmware using
>>    OpenWrt
>>
>> _______________________________________________
>> 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

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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

On 03/19/2015 11:44 PM, Janusz Dziedzic wrote:
> On 19 March 2015 at 22:40, Ben Greear <greearb@candelatech.com> wrote:
>> On 03/19/2015 10:06 AM, Simon Wunderlich wrote:
>>> Hi ath10k devs,
>>>
>>> since there has been quite a bit of progress on IBSS in ath10k, we've been
>>> trying to integrate it into our OpenWRT based firmware and test it. Since there
>>> seems to be many people interested, I'd like to share our status and also ask
>>> for comments and support on current issues:
>>>
>>>   * Our test was based on Ben Greears firmware v 13, OpenWRT rev 44654 and
>>> various patches (see details below at [1])
>>>   * We can set up IBSS networks without problems, at least without IBSS/RSN
>>> encryption
>>>   * AP+IBSS simultaneously works somewhat, but with quirks
>>>   * We see low throughput when communicating via IBSS between 2x ath10k or 1x
>>> ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150 MBit/s,
>>> with VHT even more.
>>
>> Do you see this problem with only an IBSS interface?  In other words, is my
>> firmware worse at this than stock 999.x firmware in same configuration?
>>
>
> This is results I get today morning.
> This is for ath9k - HT40
>
> janusz@dell6430:~/work/tools/test$ stdbuf -o 0 ./ibss.py t2-ath9k
> t3-ath9k 5745 |grep "TC RESULT"
> TC RESULT - t2-ath9k >> t3-ath9k pkt loss: 0%
> TC RESULT - t2-ath9k >> t3-ath9k pkt loss: 0%
> TC RESULT - parallel ping
> TC RESULT - pkt_loss t2-ath9k 0%
> TC RESULT - pkt_loss t3-ath9k 0%
> TC RESULT - (udp) t3-ath9k >>>> t2-ath9k speed: 245 Mbits/sec
> TC RESULT - (tcp) t3-ath9k >>>> t2-ath9k speed: 149 Mbits/sec
> TC RESULT - (udp) t2-ath9k >>>> t3-ath9k speed: 246 Mbits/sec
> TC RESULT - (tcp) t2-ath9k >>>> t3-ath9k speed: 151 Mbits/sec
> TC RESULT - --------dual---------------------------------
> TC RESULT - (tcp) - t2-ath9k >>> t3-ath9k: 70.8 Mbits/sec
> TC RESULT - (tcp) - t3-ath9k >>> t2-ath9k: 88.3 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (tcp) - t2-ath9k >>> t3-ath9k: 21.0 Mbits/sec
> TC RESULT - (udp) - t3-ath9k >>> t2-ath9k: 185 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (udp) - t2-ath9k >>> t3-ath9k: 183 Mbits/sec
> TC RESULT - (tcp) - t3-ath9k >>> t2-ath9k: 21.9 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (udp) - t2-ath9k >>> t3-ath9k: 116 Mbits/sec
> TC RESULT - (udp) - t3-ath9k >>> t2-ath9k: 122 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT -  ./ibss.py t2-ath9k t3-ath9k 5745 - PASS
>
> And ath10k - VHT80 - firmware 636
>
> janusz@dell6430:~/work/tools/test$ stdbuf -o 0 ./ibss.py t2-ath10k
> t3-ath10k 5745 |grep "TC RESULT"
> TC RESULT - t2-ath10k >> t3-ath10k pkt loss: 0%
> TC RESULT - t2-ath10k >> t3-ath10k pkt loss: 0%
> TC RESULT - parallel ping
> TC RESULT - pkt_loss t2-ath10k 0%
> TC RESULT - pkt_loss t3-ath10k 0%
> TC RESULT - (udp) t3-ath10k >>>> t2-ath10k speed: 409 Mbits/sec
> TC RESULT - (tcp) t3-ath10k >>>> t2-ath10k speed: 248 Mbits/sec
> TC RESULT - (udp) t2-ath10k >>>> t3-ath10k speed: 506 Mbits/sec
> TC RESULT - (tcp) t2-ath10k >>>> t3-ath10k speed: 349 Mbits/sec
> TC RESULT - --------dual---------------------------------
> TC RESULT - (tcp) - t2-ath10k >>> t3-ath10k: 144 Mbits/sec
> TC RESULT - (tcp) - t3-ath10k >>> t2-ath10k: 98.8 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (tcp) - t2-ath10k >>> t3-ath10k: 28.2 Mbits/sec
> TC RESULT - (udp) - t3-ath10k >>> t2-ath10k: 371 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (udp) - t2-ath10k >>> t3-ath10k: 307 Mbits/sec
> TC RESULT - (tcp) - t3-ath10k >>> t2-ath10k: 18.2 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT - --------dual---------------------------------
> TC RESULT - (udp) - t2-ath10k >>> t3-ath10k: 221 Mbits/sec
> TC RESULT - (udp) - t3-ath10k >>> t2-ath10k: 216 Mbits/sec
> TC RESULT - ---------------------------------------------
> TC RESULT -  ./ibss.py t2-ath10k t3-ath10k 5745 - PASS
>
> Regarding IBSS/RSN and 636 firmware, this works sometimes (ath10k
> patch required here).
> But in case this don't work firmware don't send EAPOL frames - I think
> this is main problem ...

What ath10k patch is required for IBSS/RSN to (sometimes) work?

I have something that at least resembles the 636 source..so maybe
I can find the bits that is needed and port it to my 10.1.467 firmware.

I'm still interested if Simon or someone can run similar test with my firmware
and stock firmware in same config.  The reason is I want to know if my firmware
just has issues with IBSS throughput, or if the problem only happens when an AP
vdev is added as well.  That should help me understand better where the problem lies.

Thanks,
Ben

>
> BR
> Janusz
>
>> Thanks for all the details...  Sounds like you have done more testing on this
>> than I have for sure.
>>
>> In case you have a public kernel tree available somewhere with all your patches,
>> that might help speed up someone's attempt to reproduce this?
>>
>> Thanks,
>> Ben
>>
>>
>>>   * We tracked down the reason to be aggregation not working - ath10k never
>>> sends ADDBA, and also does not respond to ADDBAs sent by ath9k
>>>   * Aggregation works just fine in AP mode in ath10k
>>>
>>> Therefore, I'd like to know if anyone has experience with Bens firmware and
>>> IBSS mode and can point us to existing issues/fixes, or recommend versions to
>>> test which are supposed to work. We had to add various VHT patches by hand, so
>>> we wonder if anyone had success with that yet, but even the HT performance is
>>> far from satisfactory.
>>>
>>> Note that we also tried firmware 999.999.0.636 firmware and got better
>>> performance (70-90 MBit/s), but since it does not properly support AP it's not
>>> an option for us.
>>>
>>> There are also a few other issues (IBSS/RSN not working - ath10k firmware does
>>> not seem to support software encryption properly ; IBSS+AP has spurious AP
>>> issues with a lot of packetloss), but that would be a topic for another time.
>>> Maybe we are just missing the right versions here ... :)
>>>
>>> Thanks!!
>>>      Simon
>>>
>>>
>>>
>>> [1] Our components and software versions:
>>>   * the devices were ath9k 2x2 (HT40), ath10k 2x2 (VHT80)
>>>   * Ben Greears firmware 13 (all variants)
>>>   * OpenWrt 44654
>>>   * all ath10k patches between f3660a25c4ff15c10c197930b5e039311a25b477
>>>     (master-2014-11-04) and v3.19
>>>   * patches from git://dmz2.candelatech.com/linux-3.19.dev.y starting with
>>>     3.19 and ending at lf-5.3.1 (patches for NFS, PCI, igb, ARM, hwmon,
>>>     configs, ath9k, neigh, cifs, aesni, hwsim and vlan were dropped)
>>>   * some patches to work around build errors in Ben Greears patches
>>>   * a revert of "ath10k: Request OTP to return debug code." because it didn't
>>>     work with his firmware on the target platform
>>>   * patch "cfg80211: add extensible feature flag attribute"
>>>   * patch "cfg80211: add VHT support for IBSS"
>>>   * patch "mac80211: IBSS fix scan request"
>>>   * Revert "mac80211: notify NSS changed when IBSS and HT"
>>>     (required to update to the latest available patch)
>>>   * "mac80211: notify NSS changed when IBSS and HT"
>>>     (from http://mid.gmane.org/1418806852-558-1-git-send-email-janusz.dziedzic@tieto.com )
>>>
>>> Most likely not relevant because it is just for the VHT support in IBSS
>>> and the problem was already there before adding these patches
>>>
>>>   * "mac80211: ibss refactor ieee80211_rx_bss_info"
>>>   * "mac80211: tdls: disentangle HT supported conditions"
>>>   * "mac80211: TDLS: support VHT between peers"
>>>   * "mac80211: add VHT support for IBSS"
>>>   * a patch to synchronize include/uapi/linux/nl80211.h with the version
>>>     shipped by iw from OpenWrt 44654
>>>   * a patch in ath10k to enable NL80211_EXT_FEATURE_VHT_IBSS
>>>   * a patch to disable SMPS STATIC to get multiple chains HT MCS rates
>>>     when communicating with ath9k
>>>   * a patch to set a VHT channel when using "ibss join"
>>>   * some patches to test things like encryption, trace wmi, ...
>>>   * some patches to automatically install the CT community firmware using
>>>     OpenWrt
>>>
>>> _______________________________________________
>>> 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
>

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

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

Re: Re: IBSS support in ath10k - our test results and questions

[Simon Wunderlich]

On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
> On 03/19/2015 10:06 AM, Simon Wunderlich wrote:
> > [...]
> >  * We see low throughput when communicating via IBSS between 2x ath10k or
> >  1x
> > 
> > ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150
> > MBit/s, with VHT even more.
> 
> Do you see this problem with only an IBSS interface?  In other words, is my
> firmware worse at this than stock 999.x firmware in same configuration?

Yes, we used your firmware with only one IBSS interface. And yes, in our tests 
your firmware performed worse - with stock 999.x firmware we saw 70-90 Mbit/s, 
which was also not great, but way better. Also in that case we saw that 
aggregation was enabled.

The AP+IBSS concurrently was another test.

As also mentioned originally, 999.x firmware is not an option for us since we 
will eventually need AP and IBSS at the same time.

> 
> Thanks for all the details...  Sounds like you have done more testing on
> this than I have for sure.

We want to integrate IBSS mode into products, so we have to test thoroughly. 
:)

If you also want to focus on IBSS, we would be happy to collaborate and test.

> 
> In case you have a public kernel tree available somewhere with all your
> patches, that might help speed up someone's attempt to reproduce this?

We currently don't have it. I'll ask if we can publish it. Our work was based 
on a backports release on the mac80211 package in OpenWRT, though, so don't 
expect a kernel tree. :)

Thanks, 
    Simon


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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

On 03/20/2015 07:26 AM, Simon Wunderlich wrote:
> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>> On 03/19/2015 10:06 AM, Simon Wunderlich wrote:
>>> [...]
>>>  * We see low throughput when communicating via IBSS between 2x ath10k or
>>>  1x
>>>
>>> ath9k + 1x ath10k (~30 MiBit/s). With HT we would have expected ~150
>>> MBit/s, with VHT even more.
>>
>> Do you see this problem with only an IBSS interface?  In other words, is my
>> firmware worse at this than stock 999.x firmware in same configuration?
> 
> Yes, we used your firmware with only one IBSS interface. And yes, in our tests 
> your firmware performed worse - with stock 999.x firmware we saw 70-90 Mbit/s, 
> which was also not great, but way better. Also in that case we saw that 
> aggregation was enabled.
> 
> The AP+IBSS concurrently was another test.
> 
> As also mentioned originally, 999.x firmware is not an option for us since we 
> will eventually need AP and IBSS at the same time.
> 
>>
>> Thanks for all the details...  Sounds like you have done more testing on
>> this than I have for sure.
> 
> We want to integrate IBSS mode into products, so we have to test thoroughly. 
> :)
> 
> If you also want to focus on IBSS, we would be happy to collaborate and test.

I am doing some work-for-hire in this area, so it's important for me to
make my firmware work as well as possible with IBSS.  For those not purchasing
support, helping to test my firmware changes and providing driver/kernel/whatever
open-source patches and help will be payment enough for me.

I'll go look to see if I can find any block-ack related code I might have missed
when porting the IBSS support forward from the 999.x firmware.

Thanks,
Ben

>>
>> In case you have a public kernel tree available somewhere with all your
>> patches, that might help speed up someone's attempt to reproduce this?
> 
> We currently don't have it. I'll ask if we can publish it. Our work was based 
> on a backports release on the mac80211 package in OpenWRT, though, so don't 
> expect a kernel tree. :)
> 
> Thanks, 
>     Simon
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


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


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

Re: IBSS support in ath10k - our test results and questions

[Sven Eckelmann]

On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
> In case you have a public kernel tree available somewhere with all your
> patches, that might help speed up someone's attempt to reproduce this?

I have uploaded the patchset of our test setup at

 git://dev.cloudtrax.com/ath10k-ibss-test.git
 https://dev.cloudtrax.com/git/ath10k-ibss-test.git

As Simon already said, it is not a kernel tree but patches on top of compat-
wireless from OpenWrt r44654. If you want to import something into an actual 
tree then please create patches and replace the CPTCFG_* strings with 
CONFIG_*.

Here a small explanation of the branches:

 * openwrt_44654: initial import of the source + patches of mac80211
   (compat-wireless) package from OpenWrt r44654
 * ath3.19: patches of ath10k which were between the compat-wireless version
   and Linux 3.19
 * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
   some patches which weren't related to the wireless stuff)
 * master: the patches which were used for the IBSS test with Ben Greear's
   firmware. Most came from Janusz Dziedzic. The rest are just a few small
   changes to fix builds, workarounds to fix loading of the firmware and some
   required patches for Janusz Dziedzic's IBSS stuff.
 * fw-999.999-ibss patch to allow loading of the original firmware with most
   of Ben Greear's patches. Was used to verify that the original 999.x
   firmware worked fine with block ack sessions + aggregation

The only patches not included here are some test patches which weren't part of 
the actual "performance" tests. This includes patches used for debugging and 
tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
to some firmware "features" regarding encryption which resulted in non-
decryptable packets).

I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
this yet because I've done the port of the OpenWrt patches on friday evening 
and hadn't time to test it with ath10k. But this problem doesn't require VHT 
features and thus should be visible with the plain HT setup and no VHT 
enabled.

Kind regards,
	Sven

PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
under the impression that you had problems with it. Beside the stuff I already 
wrote in an earlier mail, the only thing which came to my mind was the 
wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
config which works (with the OpenWrt build system of course) can be found at

 https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852

The wpa_supplicant (runtime) config would be look like this:

ap_scan=2
network={
        scan_ssid=0
        ssid="mesh"
        key_mgmt=WPA-PSK
        mode=1
        fixed_freq=1
        frequency=5180
        mode=1
        psk="9f0a965af38f2d0a13b66d8b46ab962c"
        proto=RSN
        bssid=02:CA:FE:CA:CA:40
        # openwrt specific patch for htmode, mcast_rate
        htmode=HT40+
        mcast_rate=18
}

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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
the defconfig for supplicant, so I didn't know to add it.

I am going to try RSN again shortly.

Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
work correctly when using IBSS between two of my ath10k systems on channel 36.
No significant changes to my firmware from what I last uploaded to the beta
directory...

Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
but a sniff shows the rate reported as 450Mbps for at least many of the data
frames (I guess I am still missing patches to enable VHT IBSS currently).

My tree is here.  It is basically a forward ported and cleaned up version
of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
this point:

git clone git://dmz2.candelatech.com/linux-4.0.dev.y

Thanks,
Ben


On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>> In case you have a public kernel tree available somewhere with all your
>> patches, that might help speed up someone's attempt to reproduce this?
> 
> I have uploaded the patchset of our test setup at
> 
>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
> 
> As Simon already said, it is not a kernel tree but patches on top of compat-
> wireless from OpenWrt r44654. If you want to import something into an actual 
> tree then please create patches and replace the CPTCFG_* strings with 
> CONFIG_*.
> 
> Here a small explanation of the branches:
> 
>  * openwrt_44654: initial import of the source + patches of mac80211
>    (compat-wireless) package from OpenWrt r44654
>  * ath3.19: patches of ath10k which were between the compat-wireless version
>    and Linux 3.19
>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>    some patches which weren't related to the wireless stuff)
>  * master: the patches which were used for the IBSS test with Ben Greear's
>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>    changes to fix builds, workarounds to fix loading of the firmware and some
>    required patches for Janusz Dziedzic's IBSS stuff.
>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>    of Ben Greear's patches. Was used to verify that the original 999.x
>    firmware worked fine with block ack sessions + aggregation
> 
> The only patches not included here are some test patches which weren't part of 
> the actual "performance" tests. This includes patches used for debugging and 
> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
> to some firmware "features" regarding encryption which resulted in non-
> decryptable packets).
> 
> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
> this yet because I've done the port of the OpenWrt patches on friday evening 
> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
> features and thus should be visible with the plain HT setup and no VHT 
> enabled.
> 
> Kind regards,
> 	Sven
> 
> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
> under the impression that you had problems with it. Beside the stuff I already 
> wrote in an earlier mail, the only thing which came to my mind was the 
> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
> config which works (with the OpenWrt build system of course) can be found at
> 
>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
> 
> The wpa_supplicant (runtime) config would be look like this:
> 
> ap_scan=2
> network={
>         scan_ssid=0
>         ssid="mesh"
>         key_mgmt=WPA-PSK
>         mode=1
>         fixed_freq=1
>         frequency=5180
>         mode=1
>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>         proto=RSN
>         bssid=02:CA:FE:CA:CA:40
>         # openwrt specific patch for htmode, mcast_rate
>         htmode=HT40+
>         mcast_rate=18
> }
> 


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


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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

So, IBSS RSN with ath9k works great on my systems now.

I'm trying ath10k, and what I see is that it appears the supplicant
is trying to send the 1/4 message, and it never hits the air.

Firmware has some special handling for this sort of thing..so I'll
go poke around...  If anyone has any suggestions, please let me know.

Thanks,
Ben


On 04/06/2015 10:55 AM, Ben Greear wrote:
> I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
> the defconfig for supplicant, so I didn't know to add it.
> 
> I am going to try RSN again shortly.
> 
> Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
> work correctly when using IBSS between two of my ath10k systems on channel 36.
> No significant changes to my firmware from what I last uploaded to the beta
> directory...
> 
> Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
> but a sniff shows the rate reported as 450Mbps for at least many of the data
> frames (I guess I am still missing patches to enable VHT IBSS currently).
> 
> My tree is here.  It is basically a forward ported and cleaned up version
> of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
> and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
> this point:
> 
> git clone git://dmz2.candelatech.com/linux-4.0.dev.y
> 
> Thanks,
> Ben
> 
> 
> On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
>> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>>> In case you have a public kernel tree available somewhere with all your
>>> patches, that might help speed up someone's attempt to reproduce this?
>>
>> I have uploaded the patchset of our test setup at
>>
>>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
>>
>> As Simon already said, it is not a kernel tree but patches on top of compat-
>> wireless from OpenWrt r44654. If you want to import something into an actual 
>> tree then please create patches and replace the CPTCFG_* strings with 
>> CONFIG_*.
>>
>> Here a small explanation of the branches:
>>
>>  * openwrt_44654: initial import of the source + patches of mac80211
>>    (compat-wireless) package from OpenWrt r44654
>>  * ath3.19: patches of ath10k which were between the compat-wireless version
>>    and Linux 3.19
>>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>>    some patches which weren't related to the wireless stuff)
>>  * master: the patches which were used for the IBSS test with Ben Greear's
>>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>>    changes to fix builds, workarounds to fix loading of the firmware and some
>>    required patches for Janusz Dziedzic's IBSS stuff.
>>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>>    of Ben Greear's patches. Was used to verify that the original 999.x
>>    firmware worked fine with block ack sessions + aggregation
>>
>> The only patches not included here are some test patches which weren't part of 
>> the actual "performance" tests. This includes patches used for debugging and 
>> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
>> to some firmware "features" regarding encryption which resulted in non-
>> decryptable packets).
>>
>> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
>> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
>> this yet because I've done the port of the OpenWrt patches on friday evening 
>> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
>> features and thus should be visible with the plain HT setup and no VHT 
>> enabled.
>>
>> Kind regards,
>> 	Sven
>>
>> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
>> under the impression that you had problems with it. Beside the stuff I already 
>> wrote in an earlier mail, the only thing which came to my mind was the 
>> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
>> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
>> config which works (with the OpenWrt build system of course) can be found at
>>
>>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
>>
>> The wpa_supplicant (runtime) config would be look like this:
>>
>> ap_scan=2
>> network={
>>         scan_ssid=0
>>         ssid="mesh"
>>         key_mgmt=WPA-PSK
>>         mode=1
>>         fixed_freq=1
>>         frequency=5180
>>         mode=1
>>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>>         proto=RSN
>>         bssid=02:CA:FE:CA:CA:40
>>         # openwrt specific patch for htmode, mcast_rate
>>         htmode=HT40+
>>         mcast_rate=18
>> }
>>
> 
> 


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


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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

On 03/19/2015 11:44 PM, Janusz Dziedzic wrote:
> On 19 March 2015 at 22:40, Ben Greear <greearb@candelatech.com> wrote:

> Regarding IBSS/RSN and 636 firmware, this works sometimes (ath10k
> patch required here).
> But in case this don't work firmware don't send EAPOL frames - I think
> this is main problem ...

I've been trying to figure out IBSS + RSN in my firmware.

It seems in my FW I was never (or at least rarely) sending the EAPOL
frames.  I found a way around this, but now I see 1/4 go out fine,
but 2/4 reports MIC errors.  I don't think my work-around is to blame,
but it could be.  Also not sure why my work-around is required (or at least
why STA/AP mode works w/out the hack.)

A big part of my problem is that I don't actually know how IBSS + RSN
is supposed to work.

If someone has time to clue me in on that, I might make faster progress
(or progress at all) on supporting IBSS + RSN on ath10k.

In particular, I am curious when what type of key is supposed to
be set at which stages...and for instance, what is supposed to happen
between the 1/4 message and the 2/4 message (are keys supposed to be set?)

Thanks,
Ben


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


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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

So, I've made some progress.

After fixing PSK (I had it misconfigured all of yesterday!), and with full restart of supplicant,
I can get the 4-way to complete, and I see PTK and GTK set in driver and firmware.
I do not know if the keys are set correctly, but the logs seem plausible.

After that, I see plain-text ARPs hit the air (the should be encrypted),
and the last 21 bytes of the packet appear to be random garbage.

I am guessing driver and/or firmware and/or hardware is not properly
encrypting the frames.

Off to do some more spelunking in the firmware.

Thanks,
Ben



On 04/06/2015 01:04 PM, Ben Greear wrote:
> So, IBSS RSN with ath9k works great on my systems now.
> 
> I'm trying ath10k, and what I see is that it appears the supplicant
> is trying to send the 1/4 message, and it never hits the air.
> 
> Firmware has some special handling for this sort of thing..so I'll
> go poke around...  If anyone has any suggestions, please let me know.
> 
> Thanks,
> Ben
> 
> 
> On 04/06/2015 10:55 AM, Ben Greear wrote:
>> I was missing the CONFIG_IBSS_RSN...it does not seem to be documented in
>> the defconfig for supplicant, so I didn't know to add it.
>>
>> I am going to try RSN again shortly.
>>
>> Also, I tried using my latest 4.0 kernel tree and I am seeing block-acks apparently
>> work correctly when using IBSS between two of my ath10k systems on channel 36.
>> No significant changes to my firmware from what I last uploaded to the beta
>> directory...
>>
>> Throughput is still a miserable 13Mbps or so when sending UDP/ipv5 between them,
>> but a sniff shows the rate reported as 450Mbps for at least many of the data
>> frames (I guess I am still missing patches to enable VHT IBSS currently).
>>
>> My tree is here.  It is basically a forward ported and cleaned up version
>> of my 3.19 tree, with a few additional patches.  I plan to skip 3.19
>> and focus on 4.0 for our own purposes, so my 3.19 tree is basically EOL at
>> this point:
>>
>> git clone git://dmz2.candelatech.com/linux-4.0.dev.y
>>
>> Thanks,
>> Ben
>>
>>
>> On 03/23/2015 04:24 AM, Sven Eckelmann wrote:
>>> On Thursday 19 March 2015 14:40:42 Ben Greear wrote:
>>>> In case you have a public kernel tree available somewhere with all your
>>>> patches, that might help speed up someone's attempt to reproduce this?
>>>
>>> I have uploaded the patchset of our test setup at
>>>
>>>  git://dev.cloudtrax.com/ath10k-ibss-test.git
>>>  https://dev.cloudtrax.com/git/ath10k-ibss-test.git
>>>
>>> As Simon already said, it is not a kernel tree but patches on top of compat-
>>> wireless from OpenWrt r44654. If you want to import something into an actual 
>>> tree then please create patches and replace the CPTCFG_* strings with 
>>> CONFIG_*.
>>>
>>> Here a small explanation of the branches:
>>>
>>>  * openwrt_44654: initial import of the source + patches of mac80211
>>>    (compat-wireless) package from OpenWrt r44654
>>>  * ath3.19: patches of ath10k which were between the compat-wireless version
>>>    and Linux 3.19
>>>  * candelatech-lf-lf-5.3.1 patches taken from Candelatech's 3.19 tree (minus
>>>    some patches which weren't related to the wireless stuff)
>>>  * master: the patches which were used for the IBSS test with Ben Greear's
>>>    firmware. Most came from Janusz Dziedzic. The rest are just a few small
>>>    changes to fix builds, workarounds to fix loading of the firmware and some
>>>    required patches for Janusz Dziedzic's IBSS stuff.
>>>  * fw-999.999-ibss patch to allow loading of the original firmware with most
>>>    of Ben Greear's patches. Was used to verify that the original 999.x
>>>    firmware worked fine with block ack sessions + aggregation
>>>
>>> The only patches not included here are some test patches which weren't part of 
>>> the actual "performance" tests. This includes patches used for debugging and 
>>> tests to check the IBSS RSN stuff over ath10k (which failed - most likely due 
>>> to some firmware "features" regarding encryption which resulted in non-
>>> decryptable packets).
>>>
>>> I think you can use wpa_supplicant 2.4 for VHT. I personally used a patched 
>>> version of iw which hardcoded the ibss join VHT parameters. I haven't tested 
>>> this yet because I've done the port of the OpenWrt patches on friday evening 
>>> and hadn't time to test it with ath10k. But this problem doesn't require VHT 
>>> features and thus should be visible with the plain HT setup and no VHT 
>>> enabled.
>>>
>>> Kind regards,
>>> 	Sven
>>>
>>> PS: Not sure if you have finished the test with ath9k IBSS RSN + HT. I was 
>>> under the impression that you had problems with it. Beside the stuff I already 
>>> wrote in an earlier mail, the only thing which came to my mind was the 
>>> wpa_supplicant build setup. IBSS RSN doesn't work with a standard build and 
>>> you have to enable CONFIG_IBSS_RSN in the wpa_supplicant config. An example 
>>> config which works (with the OpenWrt build system of course) can be found at
>>>
>>>  https://dev.openwrt.org/browser/trunk/package/network/services/hostapd/files/wpa_supplicant-full.config?rev=38852
>>>
>>> The wpa_supplicant (runtime) config would be look like this:
>>>
>>> ap_scan=2
>>> network={
>>>         scan_ssid=0
>>>         ssid="mesh"
>>>         key_mgmt=WPA-PSK
>>>         mode=1
>>>         fixed_freq=1
>>>         frequency=5180
>>>         mode=1
>>>         psk="9f0a965af38f2d0a13b66d8b46ab962c"
>>>         proto=RSN
>>>         bssid=02:CA:FE:CA:CA:40
>>>         # openwrt specific patch for htmode, mcast_rate
>>>         htmode=HT40+
>>>         mcast_rate=18
>>> }
>>>
>>
>>
> 
> 


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


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

Re: IBSS support in ath10k - our test results and questions

[Ben Greear]

I am still getting closer..found place in my 10.1 firmware that was setting
the mcast peer's key-index when it shouldn't, and now I can generate
udp broadcast frames on ath10k and ath9k receives them fine
(and they are encrypted on the air).

But, ARP request and response packets are being transmitted wrong by the ath10k.  Looks like
they are truncated and/or scrambled a bit..but they do decrypt on the
ath9k peer (just as mal-formed packet).

I found a bit of stuff that adjusts TID for ARP in the firmware,
but could not find any other special handling.

Anyone know if there is other special handling somewhere that might
account for this?

Thanks,
Ben


On 04/08/2015 11:38 AM, Ben Greear wrote:
> So, I've made some progress.
> 
> After fixing PSK (I had it misconfigured all of yesterday!), and with full restart of supplicant,
> I can get the 4-way to complete, and I see PTK and GTK set in driver and firmware.
> I do not know if the keys are set correctly, but the logs seem plausible.
> 
> After that, I see plain-text ARPs hit the air (the should be encrypted),
> and the last 21 bytes of the packet appear to be random garbage.
> 
> I am guessing driver and/or firmware and/or hardware is not properly
> encrypting the frames.
> 
> Off to do some more spelunking in the firmware.
> 
> 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