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? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
