All of lore.kernel.org
 help / color / mirror / Atom feed
From: Remi Pommarel <repk@triplefau.lt>
To: Steffen Moser <lists@steffen-moser.de>
Cc: linux-wireless@vger.kernel.org, ath11k@lists.infradead.org
Subject: Re: Potential Broadcast Issues After GTK Key Exchange on ath11k with IPQ8072A (QCN5024/QCN5054)
Date: Thu, 19 Dec 2024 16:35:24 +0100	[thread overview]
Message-ID: <Z2Q9POuV-6MIdzRf@pilgrim> (raw)
In-Reply-To: <c6366409-9928-4dd7-bf7b-ba7fcf20eabf@steffen-moser.de>

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.

-- 
Remi

[0]: https://git.codelinaro.org/clo/qsdk/oss/system/feeds/wlan-open/-/blob/win.wlan_host_opensource.3.0.r24/patches/ath11k/350-ath11k-Revert-clear-the-keys-properly-when-DISABLE_K.patch
[1]: commit 436a4e886598 ("ath11k: clear the keys properly via DISABLE_KEY")

> 
> I've come across a related bug report on GitHub that describes a similar
> issue:
> https://github.com/openwrt/openwrt/issues/9555#issuecomment-2433857175
> 
> Unfortunately, the GitHub discussion drifted towards various other possible
> bugs.
> 
> In the meantime, I have a done a lot of additional debugging, but I am
> coming to a dead end due to limited knowledge of the ath11k driver and
> firmware internals. Interestingly, the AP can get back from "weird state" to
> "normal state" after another GTK rekey event. I've seen this behavior only
> in the 5 GHz band, yet (using non-DFS-channels).
> 
> My questions to the Linux wireless experts and developers in this community:
> 
>  · Is such a behavior known with ath11k on IPQ8072A or on the mentioned WiFi
> chips (QCN5024/QCN5054)?
> 
>  · Could this be a driver or firmware issue that specifically arises after a
> GTK or even GMK exchange?
> 
>  · What can I do to debug it further? I've switched on debugging in
> "hostapd" in order to see the keying events. Are there more lower-level logs
> I can get from the WiFi chip and match to the latency and key exchange
> observations?
> 
>  · Are there any additional information I can/should deliver to give the
> devs more insight about this issue?
> 
> When exchanging the DynaLink DL-WRX36 AP by a Netgear R7800 AP (CPU: QCA
> IPQ8065), its predecessor, the problem is gone without touching any of the
> clients.
> 
> Thank you in advance for any insights or experiences regarding this issue.
> 
> Best regards,
> Steffen
> 
> [1] https://dd-wrt.com/
> 
> 
> -- 
> ✂-----------------------------------------------------------------------
> Dipl.-Inf. Steffen Moser                  Tel (Office): +49.731.50.32407
> School of Advanced Professional Studies       Ulm University, Room: 1013
> https://wissenschaftliche-weiterbildung.org/    Oberberghof 7, 89081 Ulm
> https://saps.uni-ulm.de/                                         Germany
> 


  reply	other threads:[~2024-12-19 15:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-19 15:02 Potential Broadcast Issues After GTK Key Exchange on ath11k with IPQ8072A (QCN5024/QCN5054) Steffen Moser
2024-12-19 15:35 ` Remi Pommarel [this message]
2024-12-20 16:52   ` Sebastian Gottschall
2024-12-28 10:13   ` Steffen Moser
2025-01-07 14:45     ` Nicolas Escande
2025-01-09 13:25       ` Kalle Valo
2025-01-09 16:30         ` Nicolas Escande
2025-01-17 19:17         ` Nicolas Escande
2025-01-19  0:55           ` Steffen Moser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z2Q9POuV-6MIdzRf@pilgrim \
    --to=repk@triplefau.lt \
    --cc=ath11k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lists@steffen-moser.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.