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