On Mon, 2020-02-24 at 12:26 -0600, Denis Kenzior wrote: > > These are two entirely different things, preauth is simply real data as > > far as the local system is concerned. It's not related to controlled > > port operation at all, which this nl80211 API is about. > > I can understand this argument, but from what I remember, one of the > goals of the control port API was to make this legacy 'special data > packet' processing unnecessary for userspace. In other words userspace > wouldn't need to establish raw sockets. Hence my question, what is the > actual concern here? That's a question of how you define "special data packet processing"... You're defining it purely in terms of the mechanics of how you handle them, but that's not really the point. Preauth frames are _not_ special. They're entirely regular data packets as far as wifi is concerned. What _is_ special is EAPOL packets, because you may need to control their encryption, know if they were ACKed, etc. > > FWIW, you may have seen Markus's patch to remove preauth from the RX as > > well, this won't work as is, but I'm still a bit on the fence as to > > whether I'll force you into the right model or not (i.e. clear the > > existing capability bit in mac80211, and introduce a new one that > > doesn't report preauth over nl80211). For RX, however, the difference > > isn't really that much of a big deal, so maybe just make it optional. > > We're actually quite happy with the current model. So I'd like to keep > things as they are. I concede that on RX, there isn't actually really a _problem_, although it's really strange to transport what really is just data frames (from a wifi POV) over a control path ... Depending on how much complexity it adds in the kernel (I've not tried to fix that today) I guess we can keep this. I'd _prefer_ not to, but I guess I cannot convince you that the preauth model is wrong, and - mostly as a sign of how much you've worn me down - I'll probably just keep it. johannes
