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

[James Prestwood <prestwoj@gmail.com>]

Hi Kalle,

On 8/15/24 7:03 AM, Kalle Valo wrote:
> James Prestwood <prestwoj@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.

Thanks,

James