linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <alexander@wetzel-home.de>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE)
Date: Thu, 14 Feb 2019 00:15:33 +0100	[thread overview]
Message-ID: <750c25be-478e-4be4-6118-f272825ea50c@wetzel-home.de> (raw)
In-Reply-To: <87r2ccq78j.fsf@purkki.adurom.net>

> 
>> Extend the shared ath key cache code to support Extended Key ID.
>>
>> The key cache code has to accept unicast keys to use key idx 1 and allow
>> drivers to enable/disable hardware Rx decryption for a key independent
>> from Tx.
>>
>> Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
>> ---
>>
>> I know this is the wrong audience to discuss ath drivers.
> 
> I think this is the right forum. Do note that somewhere in this patch
You are of course right. I mixed that up somehow.

We can of course also discuss the ath patches any time :-)
My initial plan was, to get the nl80211/mac80211 API finalized and then 
get them reviewed together with another planned fix after some more 
polishing.

At this stage they are just a POC and not ready for merge. They work 
with ath9k in AP (vlan) mode and I believe managed mode should either 
work or need some trivial fix only. (There even seems to be a chance 
that managed mode could allow the usage of the NATIVE Extended Key ID 
mode, but so far I could not tested that.)

> (in the cover letter) you mentioned "all ath drivers" but AFAICS this
> patch only changes functionality for ath5k, ath9k and ath9k_htc. All the
> rest like wil6210, ath6kl and ath10k are unaffected.
> 
You are right, I should have used "shared ath key cache code" in the 
Cover Letter, as in the patch itself. This is not (yet) an attempt to 
implement Extended Key ID for anything else than ath9k AP mode. So any 
driver not using ath_key_config() won't be affected at all.

Now I believe it's possible for all Atheros drivers but the ath10k to 
get support. As long as a card can work with SW crypto we only need a 
way to disable Rx HW crypto for a running key without impact for ongoing Tx.
But the initial results when trying my hand at ath10k are strongly 
indicating the best we can hope there is SW encryption only with CT 
firmware... or maybe a firmware update.

While the API itself is perfectly able to handle NATIVE mode the keyid 
is not handled correctly. Installing a second key switches TX to the new 
key and overwrites the keyid in the MPDU mac80211 prepared. (I could not 
even get the card to properly make an RX/TX key to an TX only key, that 
caused clear text packets when changing the key and it looks like that 
SW crypto is only possible - with nonfree CT - when not using HW crypto 
for TX at all. With those limitations I shelved any plans for ath10k.)

One of my next planned steps is now to either get another ath9k card or 
get another driver working in AP mode to test ath9k also in managed 
mode. Of course I also have to get sniffing working properly, all cards 
tried so far have issues and it also looks like I have to update 
wireshark for serious testing. So I guess driver support will still take 
some time and efforts when we got the generic issues sorted out.

I can also try my hand at porting the other Atheros drives, but without 
someone being able to confirm it works I'm not planning that at the moment.

Alexander






  reply	other threads:[~2019-02-14  0:07 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 21:06 [RFC PATCH v3 00/12] Draft for Extended Key ID support Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 01/12] mac80211: Optimize tailroom_needed update checks Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 02/12] nl80211/cfg80211: Extended Key ID support Alexander Wetzel
2019-02-15 10:52   ` Johannes Berg
2019-02-17 19:19     ` Alexander Wetzel
2019-02-22  8:30       ` Johannes Berg
2019-02-22 23:04         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 03/12] mac80211: IEEE 802.11 " Alexander Wetzel
2019-02-15 11:06   ` Johannes Berg
2019-02-19 20:58     ` Alexander Wetzel
2019-02-21 19:47       ` Alexander Wetzel
2019-02-22  8:41         ` Johannes Berg
2019-02-23 21:02           ` Alexander Wetzel
2019-03-01 20:43           ` Alexander Wetzel
2019-02-23 17:26         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 04/12] mac80211: Compatibility " Alexander Wetzel
2019-02-15 11:09   ` Johannes Berg
2019-02-21 20:07     ` Alexander Wetzel
2019-02-22  8:53       ` Johannes Berg
2019-02-23 22:50         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 05/12] mac80211: Mark A-MPDU keyid borders for drivers Alexander Wetzel
2019-02-15 11:50   ` Johannes Berg
2019-02-21 21:20     ` Alexander Wetzel
2019-02-22  8:51       ` Johannes Berg
2019-02-23 21:47         ` Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 06/12] mac80211_hwsim: Ext Key ID support (NATIVE) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 07/12] iwlwifi: Extended " Alexander Wetzel
2019-02-15 11:52   ` Johannes Berg
2019-02-22 20:50     ` Alexander Wetzel
2019-02-22 21:06       ` Johannes Berg
2019-02-24 13:04         ` Alexander Wetzel
2019-04-08 20:10           ` Johannes Berg
2019-04-10 20:46             ` Alexander Wetzel
2019-04-12  9:51               ` Johannes Berg
2019-04-14 16:12                 ` Alexander Wetzel
2019-04-15  8:44                   ` Johannes Berg
2019-04-15 20:09                     ` Alexander Wetzel
2019-04-16  9:31                       ` Johannes Berg
2019-04-16 18:28                         ` Alexander Wetzel
2019-04-16 19:11                           ` Johannes Berg
2019-04-16 21:32                             ` Alexander Wetzel
2019-04-12 11:19               ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 08/12] iwlwifi: dvm - EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:54   ` Johannes Berg
2019-02-22 21:15     ` Alexander Wetzel
2019-02-22 21:20       ` Johannes Berg
2019-02-10 21:06 ` [RFC PATCH v3 09/12] ath: Basic Extended Key ID support (COMPAT+NATIVE) Alexander Wetzel
2019-02-13 11:05   ` Kalle Valo
2019-02-13 23:15     ` Alexander Wetzel [this message]
2019-02-10 21:06 ` [RFC PATCH v3 10/12] ath5k: ath_key_config() API compatibility update Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 11/12] ath9k: Extended Key ID support (COMPAT) Alexander Wetzel
2019-02-10 21:06 ` [RFC PATCH v3 12/12] ath9k: EXT_KEY_ID A-MPDU API update Alexander Wetzel
2019-02-15 11:10 ` [RFC PATCH v3 00/12] Draft for Extended Key ID support Johannes Berg
2019-02-21 20:44   ` Alexander Wetzel

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=750c25be-478e-4be4-6118-f272825ea50c@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --cc=johannes@sipsolutions.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    /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).