Re: [PATCH 1/2] Revert "mac80211: support NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211_MAC_ADDRS"

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2020-02-24 at 12:57 -0600, Denis Kenzior wrote:
> 
> Why isn't it the point?  These are the only data packets userspace 
> management daemon(s) actually care about and has to setup raw sockets + 
> bpf filters for every interface it manages.  The current control port 
> makes all of that unnecessary.

Sure.

> So from a holistic point of view, taking kernel + userspace into 
> account, what is wrong with letting control port transport preauth 
> frames if that saves a bunch of resources (and possibly wakeups if the 
> bpf is setup badly) on the system?

If you paint it that way, it doesn't seem like there's anything wrong
with it, does it?

But not sure that's the right color - you could apply that precise same
argument to, say, transporting DHCP packets over the same path? I think
you'd agree that doesn't make it right?

Just because preauth is a wifi related protocol doesn't mean we should
treat it in a wifi control path.

> Also, the question is what changed your mind?  I asked you specifically 
> if preauth should be included in the control port API and you thought it 
> was a good idea at the time?

I don't really remember that, but perhaps? Mostly I guess the discussion
on the hostap list now, I suppose.

johannes