"Grumbach, Emmanuel" <emmanuel.grumbach@xxxxxxxxx> writes:
> On Mon, 2017-08-14 at 20:14 +0300, Kalle Valo wrote:
>> Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx> writes:
>>
>> > User space can now allow the kernel to associate to an AP
>> > that requires MFP or that doesn't have MFP enabled in the
>> > same NL80211_CMD_CONNECT command.
>> > The driver / firmware will decide whether to use it or not.
>> >
>> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
[...]
>> > --- a/net/wireless/nl80211.c
>> > +++ b/net/wireless/nl80211.c
>> > @@ -9115,6 +9115,7 @@ static int nl80211_connect(struct sk_buff
>> > *skb, struct genl_info *info)
>> > if (info->attrs[NL80211_ATTR_USE_MFP]) {
>> > connect.mfp = nla_get_u32(info-
>> > >attrs[NL80211_ATTR_USE_MFP]);
>> > if (connect.mfp != NL80211_MFP_REQUIRED &&
>> > + connect.mfp != NL80211_MFP_OPTIONAL &&
>> > connect.mfp != NL80211_MFP_NO)
>> > return -EINVAL;
>> > } else {
>>
>> I guess I'm missing something, but how is backwards compatibility
>> supposed to work from user space point of view? If user space uses
>> NL80211_MFP_OPTIONAL with an old kernel, the kernel will reject the
>> command with -EINVAL and user space will try again without
>> NL80211_MFP_OPTIONAL?
>
> No you are not. I simply forgot that point. I guess that this would be
> the behavior, yes...
I don't think that's very robust. How would user space (wpasupplicant)
know if the the EINVAL is because NL80211_MFP_OPTIONAL is not supported
by the kernel or because of some other error?
> This is relevant for ap_scan=2 wpa_s configuration only which makes it
> not really common, but still, you are right. Not sure how easy it will
> be to write this logic in the supplicant though... Unless we add an
> nl80211 feature bit but I feel it'd be a bit of a waste.
I don't feel that adding a feature bit is waste, I rather use a feature
flag than making ugly hacks to user space. But of course this is up to
Jouni and Johannes.
--
Kalle Valo
