On Sat, 2007-06-23 at 10:00 +0100, Andy Green wrote: > Johannes Berg wrote: > > > On the other hand, I do consider userspace MLME needs slightly > > different; it needs to be able to have frames encrypted, needs to see > > frames that have been decrypted even though they would otherwise be > > dropped [and this is very different to what you want], and probably > > more. > > Fair enough, but injection is a separate issue from RX, despite one > usually needs both. That there is no standard way to inject on > mac80211, regardless of the RX situation is a major lack. If injection > is not treated as a separate valid action then it will constantly be > delayed as part of some larger effort, when it is valuable in itself. 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 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. > I don't have anything against it, but for me the packets I am injecting > are normal network traffic and sending them like that seems the most > natural way. For RX down in userspace it is marginally simpler to use > libpcap monitoring and the same handle for injection and rx. Right; I see that your situation wildly differs from the userspace MLME and that in that situation this is the best and easiest thing to do. > I > definitely think having two paths to injection is not necessary, but for > splitting out normally invisible management packets to go down a > separate netlink socket instead of encapsulating them I don't mind > either way. 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
