On 25-4-2017 20:36, Johannes Berg wrote: > On Tue, 2017-04-25 at 20:34 +0200, Arend Van Spriel wrote: > >>>> + (cr->port_state != CONTROL_PORT_STATE_UNAUTHORIZED >>>> && >>>> + nla_put_flag(msg, NL80211_ATTR_PORT_AUTHORIZED)) || >>>> (cr->req_ie && >>>> >>> >>> This doesn't really make sense - why does unspecified equal >>> authorized? >> >> I was considering default behavior here for drivers that do not >> provide this information, ie. drivers not supporting 4-way handshake >> offload. So wpa_supplicant just looks for the PORT_AUTHORIZED >> attribute and deals with it without need for checking 4-way handshake >> offload is supported. > > There are two such cases - the driver is old and doesn't provide it, > but of course once you see the attribute you know that's not the case. > And the case that the driver doesn't support 4-way-HS. > > Can you really distinguish these though if you *don't* see the > attribute? > > But anyway, if it's like mac80211 not providing the data at all, then > it would say authorized, which seems wrong since that's clearly not the > case for mac80211? > > Or maybe I'm just confused. You might, but not about this ;-) The other approach I had in mind is to only pass the flag for drivers with 4-way-hs support. In that case wpa_supp also has to check that to determine whether the flag should be taken into account. Assuming the driver supporting 4-way-hs can provide the port state info. Otherwise, a new ext_feature flag would be needed. Regards, Arend
