Fwd: Question on how encryption keys are supposed to be handled.

Ben Greear greearb at candelatech.com
Mon Feb 17 14:45:04 EST 2014

Just in case someone has investigated similar issues....

-------- Original Message --------
Subject: Question on how encryption keys are supposed to be handled.
Date: Mon, 17 Feb 2014 11:44:05 -0800
From: Ben Greear <greearb at candelatech.com>
Organization: Candela Technologies
To: linux-wireless at vger.kernel.org <linux-wireless at vger.kernel.org>,        hostap at lists.shmoo.com <hostap at lists.shmoo.com>

I've been debugging an issue where my ath10k firmware is running out of key
objects to allocate.  This could be a simple issue in the firmware, but first I
wanted to try to figure out how things are supposed to work.

What I see in my firmware is that near time of association it allocates
4 keys.  Two of them are multicast, and one of the multicast is index 0,
the second is index 1.

Then, some time later (probably on rekey), another multicast is added at index 2.

After that, key space is exhausted so I see errors in the kernel logs about adding
broadcast keys failing.

TCP and UDP traffic continues to flow, but I am not testing multicast traffic,
so maybe that would be failing.

So, question is:  Is it expected that the mcast keys keep being added at increasing
key indexes?  If so, what is the maximum index allowed?

Is this something primarily controlled at the supplicant level?


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

HostAP mailing list
HostAP at lists.shmoo.com

More information about the ath10k mailing list