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