Am 06.01.20 um 10:09 schrieb Jouni Malinen:
On Sat, Jan 04, 2020 at 11:10:04PM +0100, Alexander Wetzel wrote:
Add the new attribute "key_flag" which will in the following patches
replace the boolean "set_tx" with something also able to handle
"Extended Key ID for Individually Addressed Frames" from
IEEE 802.11-2016.
...
Is this dependent on the CAN_REPLACE_PTK0 changes? If yes, I guess I'll
leave this waiting for my comments on those to be addressed. If not, it
would be good to split this patch set into two or more parts since it is
not exactly convenient to get this many patches reviewed in a single set
unless all the changes are trivial or at least straightforward. Maybe it
would be better to split this into three
(NL80211_EXT_FEATURE_CAN_REPLACE_PTK0, set_key() extensions/cleanup, and
Extended Key ID) and get them in one by one set instead of resending all
16 patches if anything needs to change.
I was original hoping to get Extended Key ID merged till PTK0 rekey
became ready, so we would not have to discuss the interactions.
But then the PTK0 rekey modifications needed very little extra effort
and were ready much faster than assumed.
There are some interactions but nothing major. Nevertheless both PTK0
rekeying and Extended Key ID patches would a bit different without the
other and for Extended Key ID the v8 version of the series is actual
showing what.
The only hard dependency is the new key_flag API for extended Key ID.
Which as a standalone would look like overkill without the new special
Extended Key ID cases and just be a small fix to set_tx usage.
PTK0 rekeying is setting up a new callback for the eapol SM to find out
from the WPA SM if it can (re-)install a PTK or should abandon the eapol
reauthentication immediately. With Extended Key ID only the WPA SM can
answer that question. So the PTK0 rekey patches are handling that what
seems to be a subotimal way but is later needed.
I can post that as three different series assuming the previous patches
have been also applied. This should cut down the resend. (But not V9,
which had changes in all areas.)
In fact you can already abort the series after the PTK0 patches (I did
verify that is a valid break point) and while not tested much the same
should be true for the key_flag API changes.
Is that ok or would you like to have the PTK0 rekey patch as it would be
without Extended Key ID on the radar and via versa? and would you then
prefer to postpone the additional key_flags only used with Extended key
ID to the Extended Key ID series?
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
