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