From: Johannes Berg <johannes@sipsolutions.net>
To: Alexander Wetzel <alexander@wetzel-home.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/2] mac80211: Add support for Extended Key ID
Date: Wed, 05 Dec 2018 15:58:32 +0100 [thread overview]
Message-ID: <24665c3e0e7e970eb8cd63dad57e2b0b3097cfcc.camel@sipsolutions.net> (raw)
In-Reply-To: <20181111110235.14213-3-alexander@wetzel-home.de>
> + * @IEEE80211_KEY_FLAG_RX_ONLY: Set by mac80211 to indicate that the key
> + * must not be used for TX (yet).
I'm not sure that's relevant, since you have one key pointer for TX?
> + * @IEEE80211_KEY_FLAG_SET_TX: Set by mac80211 to indicate that a previously
> + * installed key with IEEE80211_KEY_FLAG_RX_ONLY should take over TX also.
That also doesn't seem relevant ...
Oh, all of this is for HW offloads?
I _think_ I would prefer to have new key ops instead. Now you'd have
SET_KEY / <empty flags>
SET_KEY / RX_ONLY
SET_KEY / SET_TX
but I think maybe
SET_KEY
SET_KEY_RX_ONLY
KEY_ENABLE_TX
would make more sense?
> + if (pairwise && params->flag == NL80211_KEY_SET_TX) {
> + mutex_lock(&local->sta_mtx);
> + sta = sta_info_get_bss(sdata, mac_addr);
> +
> + if (!sta ||
> + !(key = rcu_dereference(sta->ptk[key_idx])) ||
indentation here is off by one
> + !(key->conf.flags | IEEE80211_KEY_FLAG_RX_ONLY)) {
that makes no sense, should be & I guess
> - /* PTK only using key ID 0 needs special handling on rekey */
> - if (new_key && sta && ptk0rekey) {
> + /* PTK rekey without Extended Key ID needs special handling */
> + if (new_key && pairwise && sta &&
> + !test_sta_flag(sta, WLAN_STA_EXT_KEY_ID)) {
> local = old_key->local;
> sdata = old_key->sdata;
This seems wrong, even if you have ext key ID support and everything,
but you do 0 -> 0 rekeying, then you still need all the special handling
(in fact also then if you go 1->1!). So it seems you'd instead want to
see if you're going from a TX key to a TX key with the same key ID, and
then you don't need this flag at all.
> +++ b/net/mac80211/sta_info.c
> @@ -350,6 +350,7 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
> sta->sta.max_rx_aggregation_subframes =
> local->hw.max_rx_aggregation_subframes;
>
> + sta->ptk_idx = NUM_DEFAULT_KEYS - 1;
That makes no sense? Why should it be 3? That's invalid anyway?
johannes
next prev parent reply other threads:[~2018-12-05 14:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-11 11:02 [RFC PATCH v2 0/2] Extended Key ID support for linux Alexander Wetzel
2018-11-11 11:02 ` [RFC PATCH v2 1/2] nl80211/cfg80211: Add support for Extended Key ID Alexander Wetzel
2018-12-05 14:51 ` Johannes Berg
2018-12-05 20:54 ` Alexander Wetzel
2018-12-06 7:25 ` Johannes Berg
2018-12-06 16:21 ` Alexander Wetzel
2018-11-11 11:02 ` [RFC PATCH v2 2/2] mac80211: " Alexander Wetzel
2018-12-05 14:58 ` Johannes Berg [this message]
2018-12-05 21:58 ` Alexander Wetzel
2018-12-06 7:32 ` Johannes Berg
2018-12-06 16:27 ` Alexander Wetzel
2018-12-05 14:42 ` [RFC PATCH v2 0/2] Extended Key ID support for linux Johannes Berg
2018-12-05 19:06 ` Alexander Wetzel
2018-12-07 10:01 ` Jouni Malinen
2018-12-08 13:58 ` 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=24665c3e0e7e970eb8cd63dad57e2b0b3097cfcc.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alexander@wetzel-home.de \
--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 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.