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
