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/[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).
Its still a mystery why certain AP vendors are able to trigger this
given its deleting a key locally on the device. The major issue here is
on roams when deleting the key from the prior BSS where we time out,
thereby delaying the roam for 3 seconds. This then causes downstream
effects like the reassociation timeout expiring on the AP which causes a
disassociation. With some customers using Cisco its actually happens
near 100% of the time, killing roaming entirely.
Thanks,
James
/jeff
