On Mon, 2017-08-14 at 13:36 -0700, Igor Mitsyanko wrote:
> On 08/14/2017 01:13 PM, Grumbach, Emmanuel wrote:
> > > It is kind of not clear right now for drivers where to get
> > > information from:
> > > - NL attributes passed from userspace and forwarded to a driver
> >
> > Since those exist, it seems to make more sense to me to use those
> > rather than any in-driver decided policy. Usually, deciding upon
> > policies from lower levels is frowned upon I'd say.
>
> I agree, what I mean is that drivers should know where to take this
> information from, if there are multiple sources.
>
> An example are HT/VHT capabilities for start_ap command: they can be
> parsed directly by drivers by looking at beacon's IEs in
> "cfg80211_ap_settings". At the same time those are also parsed by
> nl80211 which fills cfg80211_ap_settings::ht_cap,
> cfg80211_ap_settings::vht_cap.
> Why HT/VHT caps are not passed directly from usespace as one of NL
> attributes? I guess because there is not much point in it since
> userspace passes entire IE set anyway, which can be used by lower
> levels.
I understand your point about the information being conveyed to the
kernel through multiple pipes. But note that for HT/VHT in AP mode, the
decision maker is the user space. User space can get it from a the user
himself (hostapd.conf) or from internal knowledge (OBSS parameters in
AP mode that are handled internally in hostapd), but it essentially
doesn't matter. The kernel does nothing else but implementing the
policy decided by the user space.
When you start thinking about firmwares with more logic, the picture is
different. When Jouni added MFP support in the kernel in 2009 he wrote:
Since we are currently using nl80211 for MFP only with drivers that
use user space SME, only MFP disabled and required values are
used. However, the NL80211_ATTR_USE_MFP attribute is an enum that can
be extended with MFP optional in the future, if that is needed with
some drivers (e.g., if the RSN IE is generated by the driver).
(See commit dc6382ced07d6bad61d0b591fb12ab5da7ca632c).
Here is the thing: until now, MFP was supported only for drivers that
use user space SME, meaning drivers that let the user space decide
about pretty much everything: it sends the Assoc Request which means
that it knows _everything_ about the AP it connects to. When you don't
use user space SME (meaning you use NL80211_CMD_CONNECT and not
NL80211_CMD_{AUTHENTICATE,ASSOCIATE}), the user space may not know much
about the AP including not its RSN caps. Essentially, the user space is
sending a supplicant's network block to the kernel and asks the kernel
to connect to that thing. The user space may not even know that this
network is in the vicinity (which is what ap_scan=2 in the wpa_s means
IIUC).
So what I am trying to do here to shift the power of the decision from
the user space to the kernel in certain cases, or at least to allow the
user space to tell the kernel how to behave in several scenarios since
the user space doesn't have all the information in hand.
NL80211_MFP_NO is clear: you can't associate to an AP that has MFPC=1
MFPR=1
NL80211_MFP_REQUIRED is clear: you can't associate to an AP that has
MFPC=0 MFPR=0
This is possible when the user space knows how the RSN IE of the AP
looks like. If it doesn't, then it'd mean that the user space has no
way to say: I want to use MFP if required by the AP, but don't care all
that much if the AP doesn't support it, and this is exactly what the
NL80211_MFP_OPTIONAL comes to add.
I wrote this to explain that I can't use the IEs for this since I am
adding NL80211_MFP_OPTIONAL precisely because the user space doesn't
have the IEs.
Regarding the backward compatibility, this is a real problem. I am not
even sure that adding a feature flag will help since in case wpa_s
doesn't know the IEs of the AP, it can't really know what MFP
parameters to send (REQ or NO assuming wpa_s detected that the kernel
wouldn't support OPTIONAL). Note that all this is really relevant only
for ap_scan=2 configuration in wpa_s which is not really supported well
in nl80211 driver right now (at least based on the comments in the
wpa_s code). Asking why I am adding this in nl80211 kernel side if the
only user would be wpa_s with nl80211 and ap_scan=2 (which is
reportedly not really working) is a fair question :)
I am basically working in the context of a firmware that does the scan
before connect internally.
>
>
> >
> > > - IEs passed from userspace, parsed by nl80211 and forwarded to a
> > > driver
> > > - IEs that are passed from userspace and parsed by drivers
> > > directly
> > >
> > > >
> > > > Thanks,
> > > > Arend
> > >
> > >
>
