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.
