Hi,
On 2026-02-13 09:00, James Prestwood wrote:
Hi Jeff/Baochen,
On 2/12/26 9:56 AM, Jeff Johnson wrote:
On 2/11/2026 6:11 PM, James Prestwood wrote:
On 2/9/26 6:12 PM, Richard Acayan wrote:
When sending DELETE_KEY, the driver times out waiting for a response
that doesn't come. Only wait for a response when sending SET_KEY.
We've run into the exact same thing on the QCA6174 and have been
carrying an identical patch to this for at least a year.
https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-
[email protected]/
Baochen,
Were we ever able to reproduce this?
Do we normally always get a response to DELETE_KEY but in some
instances it
comes very late (or not at all)?
If we remove the wait, is there any concern that a late arriving
DELETE_KEY
response might be processed as a response to a subsequent SET_KEY
command?
For some added color, we only see this oddly with some vendors of APs,
primarily "classic" Cisco Aeronet equipment (not Meraki).
I use Ubiquiti nanoHD APs in my home network and have this issue with
those. The device I am focusing on with this (Lenovo ThinkSmart View)
originally came with Android and uses qcacld-2.0 there. I do see similar
disconnects on group rekeying on Android as well and have reports from
other users that WiFi does not consistently stay connected and on
Android in some cases may even fail to reconnect at all.
With ath10k on near mainline Linux I have yet to see a full loss of
connectivity.
To me this suggests that it's possibly a firmware issue.
I do have ath10k debug traces I can share, if this is helpful.
dmesg output:
qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: qca9379 hw1.0 sdio target
0x05040000 chip_id 0x00000000 sub 0000:0000
qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: kconfig debug 1 debugfs 1
tracing 1 dfs 0 testmode 0
qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: firmware ver
WLAN.NPL.1.6-00163-QCANPLSWPZ-1 api 6 features wowlan,ignore-otp,mfp
crc32 ac81ca26
Regards,
Felix
