Hi Alexander,
And that the intend of it is to replace the "old" path.
Correct.
So the best way forward here would be to
1) implement the patch here to work around the problem without
control_port or the theoretical QDISC bypass
2) start implementing control port for the future.
correct?
I don't know what the right answer is, but it seems strange to me that
we developed a 'better way', upstreamed it several years ago, but are
still trying to kludge around adding special flags to what is now
considered a legacy approach. Also disconcerting that not a single
fullmac driver has added support for this 'better way' yet.
CONTROL_PORT was added specifically to take care of the re-keying
races and can be extended with additional attributes over time, as
needed (perhaps for extended key id, etc). Also note that in our
testing CONTROL_PORT is _way_ faster than PAE socket...
Extended Key ID is pretty robust when rekeying and the driver/card only
has to take care to not mix KeyIDs within one A-MPDU. It's no problem
encrypting eapol#4 with the new key. You can even encrypt it at the
initial connect and it will work. Basically all races the "classical"
rekey has to work around go away.
For "normal" rekeys it's working pretty well with ath9k and iwlwifi even
without control_port and just learned some weeks ago that QDISC could
still cause issues...
Okay, if control port doesn't need to handle extended keys then even better.
By the way, thanks for your earlier explanation (upthread).
Regards,
-Denis
