CT ath10k firmware now supports IBSS + RSN
greearb at candelatech.com
Wed Apr 15 14:51:45 PDT 2015
I have uploaded a new firmware.
It fixes IBSS blockack (firmware was mis-configuring the BSSID, so
blockacks were sent to wrong BSS address and were not processed when
I also disabled AMSDU for IBSS stations, which significantly improves
performance in my ath10k <-> ath10k IBSS test. I do not know why this
There is still a bug: I cannot get ath10k <-> ath10k to do IBSS + RSN.
I can get ath9k <-> ath10k IBSS + RSN to work,
and open IBSS ath10k <-> ath10k works.
I am taking a break on IBSS + RSN for a while.
On 04/14/2015 08:01 AM, Ben Greear wrote:
> On 04/13/2015 10:34 PM, Michal Kazior wrote:
>> On 14 April 2015 at 02:10, Ben Greear <greearb at candelatech.com> wrote:
>>> On 04/13/2015 10:41 AM, Ben Greear wrote:
>>>> Looks like I have some more work to do. For any moderately large frames,
>>>> I am now dropping the last 16 bytes. Looks like the skb_put_padto logic
>>>> was working around a more serious issue...
>>> A better-tested version of kernel and firmware is uploaded now.
>>> Looks like I needed to add a hack to firmware to bump pkt-size by
>>> 16 for IBSS + RSN encrypted frames. Not sure exactly why, but seems
>>> to work in light testing.
>>> I removed the skb-padto hack from the kernel, and kernel is rebased on
>>> top of official 4.0 now.
>> Hmm.. Maybe this is related to MMIC. Maybe frame fragment length must
>> be different from frame length (ath10k_htt_tx(),
>> htt_data_tx_desc_frag)? Perhaps a similar hack as with RAW txmode
>> needs to be applied..?
>> : https://firstname.lastname@example.org/msg00241.html
> This IBSS+RSN hack could be done in the kernel, but if my firmware is the only thing that
> needs it, then it is more convenient for me to hack firmware than have it
> incompatible with upstream drivers.
> If you do find similar problems with other firmware, then certainly a driver
> patch is welcome, and I will back out my firmware hack accordingly.
> And, it would be nice if someone put some version if your raw-tx patch upstream.
> I can also adjust length for raw pkts in firmware too, but again, in many cases
> it is better to be similarly broken to existing firmware than to be technically
> correct but break compatibility with the driver. If I ever get a 'ct-firmware'
> feature flag upstream, then we could of course do the changes to take advantage
> of my firmwares differences as needed.
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k