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

[Kalle Valo]

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?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches