On Tue, 2017-08-15 at 10:49 +0300, Emmanuel Grumbach wrote:
> On Tue, 2017-08-15 at 10:16 +0300, Kalle Valo wrote:
> > "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?
>
> I hear, I hear. This is not an option, you are right.
>
> >
> > > 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.
>
> My latest point is that it wouldn't help since the useful usage was
> with ap_scan=2 in which wpa_supplicant can't really know what to put
> there. Or... No. It _can_ work. The user would configure pmf=optional
> in the wpa_supplicant configuration, and wpa_supplicant can check if
> that the underlying kernel supports it with the help of the feature
> flag.
> Since the pmf=optional configuration in wpa_supplicant will come from
> the user (that configures the network inside wpa_supplicant),
> wpa_supplicant can do this check.
>
> I'll add this.
>
And then, the cfg80211 driver can add this by itself, so that quantenna
folks don't have to fear getting the new value into their firmware,
although they already reported it'd work for them.
