linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <alexander@wetzel-home.de>
To: Johannes Berg <johannes@sipsolutions.net>, Luca Coelho <luca@coelho.fi>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm
Date: Mon, 19 Aug 2019 17:52:52 +0200	[thread overview]
Message-ID: <ae321cd5-6ef4-87c5-98ec-dbac37e83c6d@wetzel-home.de> (raw)
In-Reply-To: <d3c6d084728e4203832688b63e884d25b0f74fcf.camel@sipsolutions.net>

Am 19.08.19 um 11:43 schrieb Johannes Berg:
> On Sat, 2019-08-17 at 10:31 +0200, Alexander Wetzel wrote:
>>> All iwlwifi cards are able to handle multiple keyids per STA and are
>>> therefore fully compatible with the Extended Key ID implementation
>>> provided by mac80211.
>>
>> I just tried Extended Key ID with a AX200 card and it really looks like
>> it's incompatible:-(
> 
> Hmm.
> 
>> The card is starting to use the PTK key immediately after installation,
>> encrypting EAPOL #3 with the new (still Rx only!) key.
> 
> Right. This wasn't considered, I guess.
> 
>> Digging around in the driver code it looks like we do not even pass the
>> key information any longer to the card: iwl_mvm_set_tx_params() is
>> bypassing iwl_mvm_set_tx_cmd_crypto() completely when we use the "new tx
>> API". So all cards setting "use_tfh" to true are now incompatible.
>>
>> Therefore it looks like that all cards starting with the 22000 series
>> can't be used with Extended Key ID any longer.
>>
>> Is there a way to hand over the key information within the new API or is
>> the way forward to block Extended Key ID when the "new tx API" is being
>> used?
> 
> Not right now, but I think it could be fixed.

That would be great!

We may also get away by adding only means to pass the keyid of the MPDU 
(zero or one) to the HW. That could be done quite simple, I think:

We could add two new flags, e.g. IWL_TX_FLAGS_ENCRYPT_ID_0 and 
IWL_TX_FLAGS_ENCRYPT_ID_1 to avoid the need to change the structures 
iwl_tx_cmd_gen2 and iwl_tx_cmd_gen3.
When the firmware would check and use the key referenced by the STA + 
flag-id prior to the "last installed" key that should be sufficient.
By still using the last installed key without any of the new flags set 
we also would remain backward compatible.

If you have any experimental firmware to test I'm happy to do so:-)
Till then I'm back using older iwlwifi cards.

> 
>> The card is fine with using keyid 1 for unicast keys. But it looks like
>> it assumes that a new key install also tells it to use the new key
>> immediately... Still digging around but pretty sure that's happening now.
> 
> Right.
> 
> For now I guess we have to disable it with the new TX API (which is
> really what it depends on), we can try to fix the firmware later.

Ok. I'll update the iwlwifi Extended key ID support patch accordingly.

Alexander

  reply	other threads:[~2019-08-19 20:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-29 19:50 [PATCH 1/4] mac80211_hwsim: Extended Key ID API update Alexander Wetzel
2019-06-29 19:50 ` [PATCH 2/4] mac80211: Simplify Extended Key ID API Alexander Wetzel
2019-06-29 19:50 ` [PATCH 3/4] mac80211: AMPDU handling for rekeys with Extended Key ID Alexander Wetzel
2019-06-29 19:50 ` [PATCH 4/4] iwlwifi: Enable Extended Key ID for mvm and dvm Alexander Wetzel
2019-07-05  8:51   ` Luca Coelho
2019-08-17  8:31   ` Alexander Wetzel
2019-08-19  9:43     ` Johannes Berg
2019-08-19 15:52       ` Alexander Wetzel [this message]
2019-08-19 20:23         ` Johannes Berg
2019-08-19 21:15           ` Alexander Wetzel
2019-08-20  7:13             ` Johannes Berg

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=ae321cd5-6ef4-87c5-98ec-dbac37e83c6d@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luca@coelho.fi \
    /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).