Re: [WIP] mac80211: kill mgmt interface

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]