ath10k "failed to install key for vdev 0 peer <mac>: -110"
James Prestwood
prestwoj at gmail.com
Thu Aug 15 08:47:35 PDT 2024
Hi Kalle,
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.
Thanks,
James
More information about the ath10k
mailing list