Re: [PATCH] Revert "ath11k: clear the keys properly via DISABLE_KEY"

["Nicolas Escande" <nico.escande@gmail.com>]

On Sat Jan 18, 2025 at 11:29 AM CET, Vasanthakumar Thiagarajan wrote:
> Hi Nicolas,
>
> On 1/18/2025 12:44 AM, Nicolas Escande wrote:
> > This reverts commit 436a4e88659842a7cf634d7cc088c8f2cc94ebf5.
> > 
> > This as been reported by multiple people [0] that with this commit,
> > broadcast packets were not being delivered after GTK exchange.
> > Qualcomm seems to have a similar patch [1] confirming the issue.
> > 
>
> This will re-open https://www.spinics.net/lists/hostap/msg08921.html
> reported by Sven. The recommended ath firmware ABI during GTK re-keying
> is SET_KEY instead of current DEL_KEY followed by SET_KEY. We are looking
> at other options like some marking by mac80211 for the driver to be able
> to identify if the received DEL_KEY is for re-keying. Also I'm curious
> if roaming between secure and non-secure mode is a critical use case.
> If not, we can probably go ahead with this revert as temporary WAR,
> @Sven?
>
> Vasanth

Yes, indeed it will make the original problem appear once again.

But from my standpoint, switching from encrypted to unencrypted traffic with a
config reload (without an interface restart) is not so frequent of a usecase.

On the otherhand, GTK rekeying is much more frequent. Like once per day with
hostapd's default parameters. And from our tests it fails around 1/4 of the time
with ath11k. So for every 4 days of operations of an AP running the unreverted
code, you won't have broadcast working for one of them...

I would really like a proper fix from QCA, but in the meantime it seems best to
revert it IMHO.