The info page currently states:
The attack works for both clients and access points
Updating an access point does not keep clients protected!
However, neither of those statements is strictly true. Access points not implementing 802.11r roaming/FT support (or with it disabled) or client-side features are not affected (they require no patch). This is the majority of residential/home APs, as FT is a feature only used when multiple APs serve the same SSID/network.
Conversely, all access points may implement mitigation for unpatched clients (and, indeed, such mitigation is the only useful thing to be done in an update for APs that do not implement 802.11r). hostapd implements this as the new wpa_disable_eapol_key_retries config option. When that option or equivalent mitigation is enabled, all clients are protected regardless of whether they have been patched or not. Therefore, it would be useful to clarify which vendors are indeed doing this (LEDE is one example, they already have support for this option in the LuCI config file at /etc/default/wireless).
The info page currently states:
However, neither of those statements is strictly true. Access points not implementing 802.11r roaming/FT support (or with it disabled) or client-side features are not affected (they require no patch). This is the majority of residential/home APs, as FT is a feature only used when multiple APs serve the same SSID/network.
Conversely, all access points may implement mitigation for unpatched clients (and, indeed, such mitigation is the only useful thing to be done in an update for APs that do not implement 802.11r). hostapd implements this as the new
wpa_disable_eapol_key_retriesconfig option. When that option or equivalent mitigation is enabled, all clients are protected regardless of whether they have been patched or not. Therefore, it would be useful to clarify which vendors are indeed doing this (LEDE is one example, they already have support for this option in the LuCI config file at/etc/default/wireless).