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. > >
