From: Alexander Wetzel <alexander@wetzel-home.de>
To: Denis Kenzior <denkenz@gmail.com>,
Arend Van Spriel <arend.vanspriel@broadcom.com>,
Kalle Valo <kvalo@codeaurora.org>,
Maya Erez <merez@codeaurora.org>
Cc: Ahmad Masri <amasri@codeaurora.org>,
linux-wireless@vger.kernel.org, wil6210@qti.qualcomm.com
Subject: Re: [PATCH 04/11] wil6210: fix PTK re-key race
Date: Fri, 13 Sep 2019 22:48:13 +0200 [thread overview]
Message-ID: <46f1141c-929c-9686-017d-fe4305d9c922@wetzel-home.de> (raw)
In-Reply-To: <13f699ef-16c2-3ba7-79a0-0934f5e39368@gmail.com>
Am 13.09.19 um 16:33 schrieb Denis Kenzior:
> Hi Arend, Alexander,
>
>> Basically, we now have two bypass methods dealing with the
>> same/similar issue:
>>
>> 1) bypass the QDISC.
>> 2) bypass network stack entirely with CONTROL_PORT.
>
> It also raises the question in my mind as to why we have two ways of
> doing the same thing? From the discussion so far it also sounds like
> each requires somewhat different / special handling in the driver.
> Wouldn't it make sense to deprecate one and encourage drivers to
> implement the other?
>
My understanding is, that any control port frame must bypass any queues
and just send out the frame directly, correct? Any packets send via it
is directly jumping to the very front and is immediately send out.
And that the intend of it is to replace the "old" path.
So the best way forward here would be to
1) implement the patch here to work around the problem without
control_port or the theoretical QDISC bypass
2) start implementing control port for the future.
correct?
> CONTROL_PORT was added specifically to take care of the re-keying races
> and can be extended with additional attributes over time, as needed
> (perhaps for extended key id, etc). Also note that in our testing
> CONTROL_PORT is _way_ faster than PAE socket...
>
Extended Key ID is pretty robust when rekeying and the driver/card only
has to take care to not mix KeyIDs within one A-MPDU. It's no problem
encrypting eapol#4 with the new key. You can even encrypt it at the
initial connect and it will work. Basically all races the "classical"
rekey has to work around go away.
For "normal" rekeys it's working pretty well with ath9k and iwlwifi even
without control_port and just learned some weeks ago that QDISC could
still cause issues...
Alexander
next prev parent reply other threads:[~2019-09-13 22:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-08 8:32 [PATCH 00/11] wil6210 patches Maya Erez
2019-09-08 8:32 ` [PATCH 01/11] wil6210: add wil_netif_rx() helper function Maya Erez
2019-09-12 15:08 ` Kalle Valo
2019-09-08 8:32 ` [PATCH 02/11] wil6210: add support for pci linkdown recovery Maya Erez
2019-09-12 15:22 ` Kalle Valo
2019-09-08 8:32 ` [PATCH 03/11] wil6210: add debugfs to show PMC ring content Maya Erez
2019-09-08 8:32 ` [PATCH 04/11] wil6210: fix PTK re-key race Maya Erez
2019-09-10 13:23 ` Kalle Valo
2019-09-11 7:50 ` Arend Van Spriel
2019-09-11 18:32 ` Alexander Wetzel
2019-09-12 17:39 ` Denis Kenzior
2019-09-12 21:04 ` Alexander Wetzel
2019-09-13 8:04 ` Arend Van Spriel
2019-09-13 14:33 ` Denis Kenzior
2019-09-13 20:48 ` Alexander Wetzel [this message]
2019-09-17 15:32 ` Denis Kenzior
2019-09-13 18:43 ` Alexander Wetzel
2019-09-08 8:32 ` [PATCH 05/11] wil6210: make sure DR bit is read before rest of the status message Maya Erez
2019-09-08 8:32 ` [PATCH 06/11] wil6210: verify cid value is valid Maya Erez
2019-09-08 8:32 ` [PATCH 07/11] wil6210: properly initialize discovery_expired_work Maya Erez
2019-09-08 8:32 ` [PATCH 08/11] wil6210: report boottime_ns in scan results Maya Erez
2019-09-08 8:32 ` [PATCH 09/11] wil6210: use writel_relaxed in wil_debugfs_iomem_x32_set Maya Erez
2019-09-08 8:32 ` [PATCH 10/11] wil6210: fix RX short frame check Maya Erez
2019-09-08 8:32 ` [PATCH 11/11] wil6210: ignore reset errors for FW during probe Maya Erez
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=46f1141c-929c-9686-017d-fe4305d9c922@wetzel-home.de \
--to=alexander@wetzel-home.de \
--cc=amasri@codeaurora.org \
--cc=arend.vanspriel@broadcom.com \
--cc=denkenz@gmail.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=merez@codeaurora.org \
--cc=wil6210@qti.qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).