Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2011-04-05 at 15:04 -0700, Javier Cardona wrote:

> > After thinking about this more, yes, I think I do object. Not only is
> > the design strange with passing frames back and forth, but also it seems
> > like a rather slippery slope, at some point I fear somebody will attempt
> > to "fake" MPM to take advantage of that kernel code even when it's not
> > really fitting.
> 
> The above seem to be concerns with the API itself and not with
> partitioning.  We could make the API specific for mesh peering frames
> in a way that cannot be used for any other purpose other than
> protecting mesh peering frames.

Well, it's a bit of both. I can just see somebody trying to implement a
new protocol and making it look like MPM in order to be able to feed it
back into the kernel, or something like that. More generally, I don't
much like the looping back of things.

> I know of a few mesh use cases where wpa_supplicant is not required,
> such as resource constrained embedded platforms like the ones used in
> sensor networks.  But hey, we'll re-evaluate the wpa_supplicant route
> and see if it is doable.

I think in that case it'd make some sense to make the code in the kernel
configurable? Can't be all that much overhead to have essentially the
same code outside the kernel?

johannes