It appears that not all hardware/firmware implementations support group key deletion correctly, which can lead to connection hangs and deauthentication following GTK rekeying (delete and install).
To avoid this issue, instead of attempting to delete the key using the special WMI_CIPHER_NONE value, we now replace the key with an invalid (random) value. This behavior has been observed with WCN39xx chipsets. Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 Reported-by: "Alexey Klimov" <alexey.kli...@linaro.org> Closes: https://lore.kernel.org/all/dawjq2niky28.1xog35e4a6...@linaro.org Signed-off-by: Loic Poulain <loic.poul...@oss.qualcomm.com> --- v2: use random value instead of predictable zero value for key Add Tested-on tag drivers/net/wireless/ath/ath10k/mac.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 24dd794e31ea..154ac7a70982 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -16,6 +16,7 @@ #include <linux/acpi.h> #include <linux/of.h> #include <linux/bitfield.h> +#include <linux/random.h> #include "hif.h" #include "core.h" @@ -290,8 +291,15 @@ static int ath10k_send_key(struct ath10k_vif *arvif, key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV; if (cmd == DISABLE_KEY) { - arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; - arg.key_data = NULL; + if (flags & WMI_KEY_GROUP) { + /* Not all hardware handles group-key deletion operation + * correctly. Replace the key with a junk value to invalidate it. + */ + get_random_bytes(key->key, key->keylen); + } else { + arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; + arg.key_data = NULL; + } } return ath10k_wmi_vdev_install_key(arvif->ar, &arg); -- 2.34.1
