Hi Johannes,
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?
But I'm not, and I don't think the argument for DHCP is anywhere as
strong. DHCP is typically handled outside of the wifi management daemon
(though it can be done inside) and is usually something that is very
much separate from WiFi details regardless of where it lives.
Just because preauth is a wifi related protocol doesn't mean we should
treat it in a wifi control path.
But it seems like the benefits outweigh the drawbacks? At least we have
been super happy with how control port works for us. If you take the
pre-auth path away, I'm really not sure there's any point in (at least
for us) keeping support for the control port 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.
I'm not subscribed there. A synopsis of the discussion (or
linux-wireless CC) would have been nice.
Regards,
-Denis
