ath10k "failed to install key for vdev 0 peer <mac>: -110"

[James Prestwood]

On 8/15/24 8:58 AM, Kalle Valo wrote:
> James Prestwood <prestwoj at gmail.com> writes:
>
>> On 8/15/24 7:03 AM, Kalle Valo wrote:
>>> James Prestwood <prestwoj at gmail.com> writes:
>>>
>>>> Hi,
>>>>
>>>> So I have no resolution to this (trying to get the AP vendor to chase
>>>> it down), but I'm toying with the idea of trying to work around
>>>> whatever issue the AP is having when this occurs. The only thing I can
>>>> think of is that there is a 3 second delay between the authentication
>>>> and reassociation, and perhaps this is causing some timeout in the AP
>>>> and in turn the deauth.
>>>>
>>>> I'm wondering how long it should take to add/remove a key from the
>>>> firmware? 3 seconds seems very long, and I question if this timeout is
>>>> really necessary or was just chosen arbitrarily? Is this something
>>>> that could be lowered down to e.g. 1 second without negative impacts?
>>>> The code in question is in ath10k_install_key:
>>>>
>>>> ret = ath10k_send_key(arvif, key, cmd, macaddr, flags);
>>>> if (ret)
>>>>       return ret;
>>>>
>>>> time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
>>>> if (time_left == 0)
>>>>       return -ETIMEDOUT;
>>> I can't remember anymore but I'm guessing the 3s delay was chosen
>>> arbitrarily just to be on the safe side and not get unnecessary
>>> timeouts.
>> Thanks, I have reduced this to 1 second and have had it running on a
>> client for ~19 hours. Still am seeing the timeouts, but no more than
>> prior. And even with the timeouts the roams are successful.
>>
>> After doing more looking in the spec I did see that there is
>> dot11ReassociationDeadline which may be coming into play here. Of
>> course these APs aren't advertising any TIE or even support FT
>> resource requests that so its impossible to know for sure, and hostapd
>> AFAICT doesn't enforce any deadlines even if you set it... But in any
>> case the timeout reduction is helping immensely and avoiding a
>> disconnect.
> Yeah, reducing the time out might a good option. 3s feels like overkill,
> especially if 1s timeout passes your tests.
>
> But I do wonder what's the root cause here. Are you saying that SET_KEY
> always works for you?

Yeah its only key removal that fails, we proceed on and adding the new 
key succeeds 100% of the time and in most cases this is fine, except 
these picky APs that don't like the 3 second delay.

Fwiw this seemed to start after going from 5.15 -> 6.2, which is a 
needle in a haystack, I know. Makes me think there is a race somewhere 
(like in the firmware) and the command timing changed just enough 
between 5.15 and 6.2 that it happens more frequently.

Thanks,

James