Johannes Berg wrote: > Don't get me wrong, I fully support your patches. I can see usefulness > in what you're doing there, I even based my recent patch-frenzy on top > of your patches ;) But I'm not fully convinced that this will be the Thanks for the faith Johannes :-) > best path for the userspace MLME (in whatever form); I do however think > that it is the best option for wireless analysis/hacking/... tools or > something like your penumbra. > >> But Jiri's encapsulation method is an improvement if it can be >> implemented okay for unassociated interfaces and so on. > > Not convinced; it solves only a minor part of the problem, the hard > things aren't solved (like that we need to see the decrypted frames that > would normally be dropped by the kernel). Hence, I don't see any value > in it by itself without solving the harder parts as well (or better even > first), when solving that may end up using netlink for frames anyway. The thing that it buys is allowing injection in a standardized format on interfaces in any mode. Currently the fact that a TX packet comes on a Monitor Mode interface is used to infer the format of it, that it will have a radiotap header. That's not too ugly, but allowing injection/radiotap format packets to be accepted on any interface in any mode (eg, Master) and to use an ethhdr to determine the structure of the packet is a bit more general and clean, since that is the job of the ethhdr everywhere. > I think what we need to accept is that the long-touted concept of a > "userspace MLME" isn't really that, while it's dead simple to do > *everything* in userspace by using a monitor interface with injection > and then a tun interface that isn't really what we want. We want to push > parts of the complexity to userspace while still having it > kernel-assisted for various reasons like performance. It'll be interesting to see what the genuine primitives are for the MLME after you are finished ejecting the ioctl type cruft. I don't have much idea of what is truly needed as it stands. -Andy - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
