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.
