Am 28.08.18 um 10:46 schrieb Johannes Berg:
> On Sat, 2018-08-18 at 22:53 +0200, Alexander Wetzel wrote:
> 
>>> This looks good to me from a userspace perspective.  I will try to
>>> implement support for this in iwd soon to give you a prototype to play
>>> with.
>>
>> Sounds promising, thank you!
>>
>> I'm still unsure if we really need the API changes to fix that issue:
>> "Tagging" the new requirements to current set_key calls would also work.
>> With the downside that there would be no way to detect "broken"
>> drivers... replace_key is basically only there to differentiate between
>> audited/fixed drivers and those not.
>>
>> But since my current impression is, that ptk rekeys are mostly broken
>> independent of mac80211 or even linux a driver flag signaling support
>> for it sounds like a good idea regardless how we want to fix the issue
>> in mac80211. Just wondering if we should name it differently for that
>> and I'm considering renaming it to NL80211_EXT_FEATURE_CAN_REKEY_PTK0 in
>> the next patch.
> 
> And then keep set_key() for both, rather than adding replace_key()?
> Seems reasonable to me, I guess.

Exactly. The complete replace_key patch will be dropped. I've the
patches for that nearly ready, only working on the commit messages and
docu updates. (To code changes were trivial.)

> 
>> As for mac80211 driver status:
>> The only known "really broken" driver at the moment is ath9k. With
>> iwlwifi, - and less thorough tested - ath10k to be ok from a driver
>> point of view. (ath9k needs just a driver flush as minimal fix.)
> 
> iwlwifi is also broken for CCMP-256/GCMP keys, so the situation is
> slightly more complex.

I was suspecting something like that, thanks for confirming.

Alexander

Reply via email to