+ 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
