Im getting the following prints every hour, i suppose its related to 802.11r being enabled without? 802.11w.
Rekeying PTK for STA 5c:f8:a1:XX:XX:XX but driver can't safely do that.
I found this old bug-report https://svn.dd-wrt.com/ticket/6655 which points to https://github.com/openwrt/mt76/issues/278 which mentions that its not a driver related problem. I can confirm that its happening on ath10k-ct / ath9k and im not sure what the cause is.
Its not only one client its all devices in the wireless network.
Any pointers are appreciated.
This seems to be because the wifi drivers are not supporting the
NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 flag https://github.com/torvalds/linux/blob/master/net/mac80211/key.c#L281
Which itself seems to be a security feature flag for getting the key out of memory, i dont quite understand how this was critical enough to warrant a warning for every rekey, but that seems to be the case right now.
Maybe the driver developers (ath10k/ct, ath9k, etc.) can implement this flag, if possible to get rid of the warning and the security issue.
(small explanation on the issue: https://firstname.lastname@example.org/msg60429.html)
Summary: this warning is completely harmless from an user pov. (besides the theoretical security risk)
The linux-wireless mailing list would be a good place to report your findings and make the suggestion.
You are next to sure using WPA-EAP (WPA Enterprise) which is by default re-authenticating every hour.
If not you must have set
wpa_pair_rekey=3600 or the connected stations must have such a setting, both not very likely. It has nothing to do with 802.11[w,r]. The warning can only be triggered wen installing a PTK for a station (MAC) which already has a PTK active.
eap_reauth_period=0 is probably the proper work around for now when you are not sure all devices (AP and all connecting STA's) are able to rekey the PTK correctly.
Ath10k is one of the few known drivers which seem to be fine and only has to set
NL80211_EXT_FEATURE_CAN_REPLACE_PTK0. ath9k can set it when using a mac80211 from kernel 4.20 or higher (but you have that or would not get the warning). ath9k - and probably all other ath drivers < 10) are totally broken with older versions of mac80211 when you rekey the PTK. (That's one of the other drivers well understood).
Broken translates here to have more or less random 1h long connection freezes and forgetting to encrypt some packets. Chances are that most cards using mac80211 do have at least some issues with the older mac80211 implementation when using HW encryption. (ath10k is doing the dangerous things only on the chip and are therefore bypassing the dangerous areas. As a bonus they seem to do it right, too!)
NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 is a security warning but unrelated to the key data. Mac80211 just detected something which looks dangerous but can't really refuse do do it.
We actually considered to refuse the key update instead only printing a warning. But since it was always broken - and not only for mac80211 cards - that seemed a bit too drastic.
But adding the flag to the drivers and silencing the warning is not meaning your rekeys are working or safe to use.
So the conclusion that this is always harmless from a user POV is wrong!
Chances are other rekey bugs on either end are mitigating the problem by causing an reconnect in most cases, though. But when you e.g. use buggy ath9k on the router - like me - and any mac80211 card on linux (even bugfree) your wlan will freeze every 1h for 1h or till you reconnect manually.
My suggestion would be to change the default for
eap_reauth_period to zero in openwrt and/or back port the latest PTK0 rekey patch available here: PTK0 rekey patch set and enable that feature.
Lastly the correct bug to link the
NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 to would be this Old Openwrt Bug and this Kernel bug report. For a full report what is wrong in mac80211 with kernels < 4.20 see 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear text leak")
Hope that is shining some light on the issue.
Thanks for the corrections Alexander, the 802.11w/r relation was an early assumption which was incorrect but i didnt state so in the update.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.