Re: [WIP] mac80211: kill mgmt interface

[Andy Green <andy@warmcat.com>]

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.

But Jiri's encapsulation method is an improvement if it can be
implemented okay for unassociated interfaces and so on.

> I haven't seen a good proposal to unify this. To me, Jiri's proposal of
> packing what is essentially out-of-band data into some sort of special
> frames is no use, and your proposal to use monitor mode interfaces is
> perfect for the first use case, but still leaves us with more
> out-of-band data that the userspace MLME needs and hence doesn't gain us
> much.

Understood, it doesn't affect injection though.  Also the kernel packet
filter stuff can easily filter on the ethertype part of the encapsulated
packets.

> Who started this anti-nl80211 thing anyway? I still don't see what's so
> wrong with sending frames down a PF_NETLINK socket rather than a
> PF_PACKET socket.

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.  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.

-Andy