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

[Javier Cardona <javier@cozybit.com>]

On Wed, Apr 6, 2011 at 7:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> 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?

We are analyzing how hard it would be to do MPM in userspace while
keeping (default) path selection in the kernel.  In this approach
userspace would not only authenticate but also establish peer links
and (in-kernel) stations would represent only established peer links.
It's probably not that hard after all, but definitely some overhead
compared to leaving it as it is :)

Javier