Re: Potential Broadcast Issues After GTK Key Exchange on ath11k with IPQ8072A (QCN5024/QCN5054)

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

On Sat Dec 28, 2024 at 11:13 AM CET, Steffen Moser wrote:
> Dear Remi,
>
> thank you very much for the pointer to the patch. Sebastian integrated 
> it into DD-WRT. Now the DynaLink DL-WRX36 runs absolutely smoothly, the 
> WLAN links are stable, the packet loss is gone. No weird states anymore, 
> independent from the group key exchange interval:
>
> https://data.saps.uni-ulm.de/index.php/s/NLNpWqjc8iGsaEM
>
> So your idea was a direct hit! Thank you very, very much. Several months 
> of debugging have come to an end...

So this is at least the second time this commit breaks a setup.
 
@ath11k why isn't this pushed to mainline ?
This seems to be a clear regression, so even if there is no need to rush things
in the long run this still needs to to reverted mainline right ?

>
> Thank you very much and all the best for 2025!
>
> Kind regards,
> Steffen
>
> On 19.12.24 4:35 PM, Remi Pommarel wrote:
> > Hi Steffen.
> > 
> > On Thu, Dec 19, 2024 at 04:02:30PM +0100, Steffen Moser wrote:
> >> Hello everyone,
> >> 
> >> I've encountered a possible issue in a DD-WRT [1] setup where broadcast
> >> packets stop being delivered after a GTK (Group Temporal Key) exchange. This
> >> issue occurs on a system with the following hardware:
> >> 
> >>     Access Point Hardware: DynaLink DL-WRX36
> >>     Router Software: DD-WRT v3.0-r58819 std (12/13/24)
> >>     CPU: Qualcomm IPQ8072A
> >>     WiFi Chips: Qualcomm QCN5024 and Qualcomm QCN5054
> >>     WiFi Driver: ath11k
> >>     Firmware: WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
> >>     NSS FW version: NSS.FW.12.5-210-HK.R
> >>     Kernel: Linux WL-AP-EG 6.6.64-rt29 #1791 SMP Thu Dec 12 16:41:51 +07
> >> 2024 aarch64 DD-WRT
> >> 
> >> The behavior is such that after a GTK exchange, the AP can get into a "weird
> >> state". When being there, broadcast frames like ARP or mDNS are no longer
> >> reliably delivered to connected clients while unicasts come still through.
> >> In this "weird state", the channel quality (active time vs. busy time) goes
> >> down and latencies to the still reachable WIFI clients rise.
> > 
> > This looks a lot like an issue we hit a while back. There is this patch
> > [0] from Qualcomm's wlan-open repository. It is a revert of [1]. Using
> > that the issue was never reproduced. Maybe this can help.
> > 
> > Also adding ath11k list.
> > 
> > Regards.
> >