On Mon, 2017-08-14 at 13:08 -0700, Igor Mitsyanko wrote: > On 08/14/2017 12:22 PM, Arend van Spriel wrote: > > On 14-08-17 15:49, Emmanuel Grumbach wrote: > > > 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 short tour of the drivers taught me that only Quantenna really > > > look > > > at cfg80211_connect_params::sme which can now be 2. This is why > > > the maintainer of this driver is CCed. > > > > Indeed in brcmfmac the IE is processed to determine whether it is > > required or optional. Probably will change our driver to use the > > explicit mfp values from cfg80211_connect_params::sme. > > Maybe this is a right way to do that, avoiding that compatibility > problem (no new NL* flags)? Except for maybe nl80211 layer should > parse > it instead, not driver. Seems odd to me, since there already is an NL attribute for this and you want the user space to decide on the policy I think. > > 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. > - 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 > >
