On Thu, 2017-05-18 at 12:29 +0200, Arend Van Spriel wrote: > On 18-5-2017 11:22, Johannes Berg wrote: > > On Thu, 2017-05-18 at 10:18 +0200, Arend Van Spriel wrote: > > > > > > > We should therefore probably set the expectation that wpa_s - > > > > if > > > > it's new enough - always uses the offloaded functionality and > > > > always sets the WANT_1X. Then this is even better with such > > > > drivers, since they can immediately reject the connect() > > > > command if > > > > want_1x isn't set. > > Getting back at this. With "always" you mean for every connect() > regardless whether it is using 1X or PSK? No, I just meant it would never use the non-offloaded functionality for 1X, as long as wpa_s was new enough to support it. The same consideration kinda applies to (non-)offloaded 4-way-HS for PSK though I guess, with some drivers (devices) not able to not offload it. > You mean adding a nl80211 command in which user-space can indicate > what features it supports? Do you want to use the same feature bits > on both sides to easily determine the combined feature set? > ext_feature does not really have much overlapping so not sure if it > adds value. No, I meant that we have NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X today, but then we might need also NL80211_EXT_FEATURE_HOST_4WAY_HANDSHAKE_STA_1X. Come to think of it though, I guess the fact that the NEW_KEY command isn't support would already indicate that. johannes
