[RFC 0/1] wifi: ath10k: improvement on key removal failure

[RFC 0/1] wifi: ath10k: improvement on key removal failure

[James Prestwood]

This is in regard to my earlier question [1]. After some testing with
adding an artificial 3 second delay between auth and assoc frames I
saw that the device would fail to roam 100% of the time. This further
backed up my theory that this firmware failure is causing some
timeout on the AP, and resulting it either ignoring the reassociation
or rejecting it.

Changing kernel behavior to fix a vendor quirk isn't great, but
in this situation since the key removal is non-fatal and it
improves general performance when the firmware does time out I
thought it was an acceptable compromise. I am also pursuing the
vendor to fix this, and allow a greater delay between auth and
assoc.

The reason I'm sending this as an RFC is that I have no idea about
other hardware, firmwares, etc, that use ath10k. I have only tested
on the QCA6174. Maybe different configurations _do_ need 3 seconds
to remove a key? Maybe this timeout needs to be a hw_param?

[1] https://lore.kernel.org/linux-wireless/9eafac85-2262-4f92-a70b-32109f65c05a@gmail.com/T/#t



James Prestwood (1):
  wifi: ath10k: reduce timeout for disabling a key

 drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.34.1

[RFC 1/1] wifi: ath10k: reduce timeout for disabling a key

[James Prestwood]

The QCA6174 experiences random cases of a key failing to be disabled.
The timeout for this currently is 3 seconds. This can happen on
roaming when removing the old key during the transition to the new
BSS. Though the roam will generally succeed (except with
some AP vendors, explained below) it means that it is delayed by 3
seconds until the timeout expires.

Certain AP vendors appear to have issues with this delay and either
ignore the subsequent reassociation, or reject it. This results in
a disconnect.

Since key removal is a non-fatal failure it feels somewhat safe to
reduce this timeout down in order to both reduce the potential
delay and play nice with APs that aren't able to handle the delay
between authentication and association.

Signed-off-by: James Prestwood <prestwoj@gmail.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index ec8d5b29bc72..fd20107abd0f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -301,6 +301,7 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
 	struct ath10k *ar = arvif->ar;
 	int ret;
 	unsigned long time_left;
+	unsigned long timeout = (cmd == DISABLE_KEY) ? 1 : 3;
 
 	lockdep_assert_held(&ar->conf_mutex);
 
@@ -313,7 +314,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
 	if (ret)
 		return ret;
 
-	time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
+	time_left = wait_for_completion_timeout(&ar->install_key_done,
+						timeout * HZ);
 	if (time_left == 0)
 		return -ETIMEDOUT;
 
-- 
2.34.1

Re: [RFC 0/1] wifi: ath10k: improvement on key removal failure

[Felix Kaechele]

I was somewhat hoping that it could fix the issues I'm having with my 
QCA9379 as well, but it seems that's not the case.
Still getting

[ 7660.485652] ath10k_sdio mmc1:0001:1: failed to install key for vdev 0 
peer 76:ac:b9:xx:xx:xx: -110
[ 7660.485679] wlan0: failed to set key (2, ff:ff:ff:ff:ff:ff) to 
hardware (-110)
[ 7660.509935] wlan0: deauthenticating from 76:ac:b9:xx:xx:xx by local 
choice (Reason: 1=UNSPECIFIED)
[ 7661.836653] wlan0: authenticate with b2:8b:a9:xx:xx:xx (local 
address=de:56:bb:xx:xx:xx)
[ 7661.836685] wlan0: send auth to b2:8b:a9:xx:xx:xx (try 1/3)
[ 7661.849449] wlan0: authenticated
[ 7661.853884] wlan0: associate with b2:8b:a9:xx:xx:xx (try 1/3)
[ 7661.902242] wlan0: RX AssocResp from b2:8b:a9:xx:xx:xx (capab=0x1111 
status=0 aid=2)
[ 7661.913192] wlan0: associated
[ 7662.187718] wlan0: Limiting TX power to 24 (24 - 0) dBm as advertised 
by b2:8b:a9:xx:xx:xx

once every hour.

That's unfortunate.

Regards,
Felix

Re: [RFC 0/1] wifi: ath10k: improvement on key removal failure

[James Prestwood]

Hi Felix,

On 8/16/24 5:53 PM, Felix Kaechele wrote:
> I was somewhat hoping that it could fix the issues I'm having with my 
> QCA9379 as well, but it seems that's not the case.
> Still getting
>
> [ 7660.485652] ath10k_sdio mmc1:0001:1: failed to install key for vdev 
> 0 peer 76:ac:b9:xx:xx:xx: -110
> [ 7660.485679] wlan0: failed to set key (2, ff:ff:ff:ff:ff:ff) to 
> hardware (-110)
> [ 7660.509935] wlan0: deauthenticating from 76:ac:b9:xx:xx:xx by local 
> choice (Reason: 1=UNSPECIFIED)
> [ 7661.836653] wlan0: authenticate with b2:8b:a9:xx:xx:xx (local 
> address=de:56:bb:xx:xx:xx)
> [ 7661.836685] wlan0: send auth to b2:8b:a9:xx:xx:xx (try 1/3)
> [ 7661.849449] wlan0: authenticated
> [ 7661.853884] wlan0: associate with b2:8b:a9:xx:xx:xx (try 1/3)
> [ 7661.902242] wlan0: RX AssocResp from b2:8b:a9:xx:xx:xx 
> (capab=0x1111 status=0 aid=2)
> [ 7661.913192] wlan0: associated
> [ 7662.187718] wlan0: Limiting TX power to 24 (24 - 0) dBm as 
> advertised by b2:8b:a9:xx:xx:xx
>
> once every hour.
>
> That's unfortunate.
In your case it looks like a failure on a group re-key, which makes 
sense that you would see a disconnect. Definitely unfortunate.
>
> Regards,
> Felix