Re: [RFC] cfg80211: add control port state to struct cfg80211_connect_resp_params

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

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