All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: James Prestwood <prestwoj@gmail.com>
Cc: linux-wireless@vger.kernel.org,  ath10k@lists.infradead.org
Subject: Re: ath10k "failed to install key for vdev 0 peer <mac>: -110"
Date: Thu, 15 Aug 2024 17:03:08 +0300	[thread overview]
Message-ID: <87r0apyjc3.fsf@kernel.org> (raw)
In-Reply-To: <9eafac85-2262-4f92-a70b-32109f65c05a@gmail.com> (James Prestwood's message of "Mon, 12 Aug 2024 10:33:30 -0700")

James Prestwood <prestwoj@gmail.com> writes:

> Hi,
>
> So I have no resolution to this (trying to get the AP vendor to chase
> it down), but I'm toying with the idea of trying to work around
> whatever issue the AP is having when this occurs. The only thing I can
> think of is that there is a 3 second delay between the authentication
> and reassociation, and perhaps this is causing some timeout in the AP
> and in turn the deauth.
>
> I'm wondering how long it should take to add/remove a key from the
> firmware? 3 seconds seems very long, and I question if this timeout is
> really necessary or was just chosen arbitrarily? Is this something
> that could be lowered down to e.g. 1 second without negative impacts?
> The code in question is in ath10k_install_key:
>
> ret = ath10k_send_key(arvif, key, cmd, macaddr, flags);
> if (ret)
>     return ret;
>
> time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
> if (time_left == 0)
>     return -ETIMEDOUT;

I can't remember anymore but I'm guessing the 3s delay was chosen
arbitrarily just to be on the safe side and not get unnecessary
timeouts.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches


  reply	other threads:[~2024-08-15 14:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12 13:11 ath10k "failed to install key for vdev 0 peer <mac>: -110" James Prestwood
2024-07-14 21:15 ` Felix Kaechele
2024-07-15 11:54 ` James Prestwood
2024-08-12 17:33   ` James Prestwood
2024-08-15 14:03     ` Kalle Valo [this message]
2024-08-15 15:47       ` James Prestwood
2024-08-15 15:58         ` Kalle Valo
2024-08-15 16:38           ` James Prestwood
2024-08-16 10:19 ` Baochen Qiang
2024-08-16 12:04   ` James Prestwood
2024-09-04 18:03     ` Jeff Johnson
2024-09-05  1:46       ` Baochen Qiang
2024-11-25 13:32         ` James Prestwood
2024-11-26  2:56           ` Baochen Qiang
2024-12-06  2:47         ` Baochen Qiang
2024-12-06 12:27           ` James Prestwood
2024-12-09  6:48             ` Baochen Qiang
2024-12-09 12:37               ` James Prestwood
2025-11-14 21:52                 ` James Prestwood

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=87r0apyjc3.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=prestwoj@gmail.com \
    /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.