[PATCH v2] ath10k: fix PMG by using AES-CMAC/IGTK software crypto

Ben Greear greearb at candelatech.com
Wed Mar 11 09:00:26 PDT 2015

On 03/11/2015 02:17 AM, Bartosz Markowski wrote:
> On 10 March 2015 at 17:02, Ben Greear <greearb at candelatech.com> wrote:
>> On 03/10/2015 06:32 AM, Bartosz Markowski wrote:
>>> While testing with older supplicant, .drv_set_key() was failing due to
>>> higher than ath10k firmware could handle key_index (WMI_MAX_KEY_INDEX == 3).
>>> --
>>> wpa_driver_nl80211_set_key: ifindex=15 alg=4 addr=0x7f02b129fbe3 key_idx=4 set_tx=0 seq_len=6 key_len=16
>>>     broadcast key
>>> nl80211: set_key failed; err=-22 Invalid argument)
>>> wlan0: WPA: Failed to configure IGTK to the driver
>>> wlan0: RSN: Failed to configure IGTK
>>> --
>>> In order to fix this case (PMF: AES-CMAC/IGTK) force the AES_CMAC cipher to
>>> be handled by software.
>> How did you get firmware to allow the host to do the encryption?
> :
>> Every time I've tried such a thing I end up with either nothing or garbage on
>> the air.
>> Or this this particular type of encryption treated differently by the
>> firmware?
> I would suspect so, but it's just my gut feeling. I did not check this
> on a firmware level, as the PMF (AES_CMAC) encryption was done this
> way from the very beggining in ath10k.
> This patch only address the key_idx exceeded case, where
> ath10k_set_key() was returning -ENOSPC, so we could inform mac80211
> explicitly (by returning '1') it shall do the encryption in software.

One of my very early patches when trying to use ath10k was to ask
the firmware for one extra key slot.  Maybe I hit the same problem
you did.  I'll have to try reverting my patch and try yours instead
some day.


> -Bartosz

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

More information about the ath10k mailing list