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>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
Date: Sat, 23 Feb 2019 18:26:09 +0100	[thread overview]
Message-ID: <f3c2a4ad-0019-60c7-be09-d52a8b137efa@wetzel-home.de> (raw)
In-Reply-To: <171d2db4-7639-4738-2a6d-c899f0247aee@wetzel-home.de>


>>>
>>>> +    sta = sta_info_get_bss(sdata, mac_addr);
>>>> +
>>>> +    if (!sta)
>>>> +        return -EINVAL;
>>>> +
>>>> +    if (sta->ptk_idx == key_idx)
>>>> +        return 0;
>>>> +
>>>> +    mutex_lock(&local->key_mtx);
>>>> +    key = key_mtx_dereference(local, sta->ptk[key_idx]);
>>>> +
>>>> +    if (key && key->flags & KEY_FLAG_RX_ONLY)
>>>
>>> do you even need the flag? Isn't it equivalent to checking
>>>     sta->ptk_idx != key->idx
>>> or so?
>>>
>>> Less data to maintain would be better.
>>
>> I have to look at that again. It will change some assumptions for sure 
>> but still could work out with some slight differences. I'll have to 
>> look deeper into that since I remember two moments where I was sure 
>> needing the flag. That may well be outdated, but at a first glance it 
>> would at least open the door to first install two key in legacy mode 
>> and then switch between them. (Which should be no problem, of course)
>> I'll follow up on that separately, but that may take some time. When 
>> it works you'll get a new RFC.

I gave that a closer look today and tried to get rid of 
KEY_FLAG_RX_ONLY. It looks like it could work, but only with a 
(pointless looking) trade off:

The problem is the initial key install. Normal and Extended Key Installs 
both call ieee80211_add_key() and the function has to "mark" either the 
key or the sta to be using Extended Key ID so we later know if we have 
to activate Tx for the key or not.

Without that ptk_idx will still be set to INVALID_PTK_KEYIDX in either 
case and therefore useless. ieee80211_key_replace() will then have no 
way to figure out if it must set ptk_idx and activate the key for TX or 
not.

Both checking a key Flag (for RX only) or a station flag (for Extended 
Key ID being used) would solve the problem but I do not see an good way 
to do it without one or the other.

Now we could of course use some other existing variable like setting 
ptk_idx to INVALID_PTK_KEYIDX+1 in ieee80211_add_key(). But it still 
would be some kind of flag, only stored where nobody would expect it...

Storing the information with the key simplifies the delay tailroom 
handling a bit but I think I can get that operational with a station 
flag for Extended Key ID also. But for me that trade off looks pointless..

I can of course go ahead if you see some benefit or other way ahead...
But I would pull the plug on the plan to get rid of RX_Only Key flag 
with that.

Alexander

  parent reply	other threads:[~2019-02-23 17:26 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 [this message]
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
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=f3c2a4ad-0019-60c7-be09-d52a8b137efa@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --cc=johannes@sipsolutions.net \
    --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).