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

[Javier Cardona <javier@cozybit.com>]

On Tue, Apr 5, 2011 at 1:28 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2011-04-05 at 11:05 -0700, Javier Cardona wrote:
>
>> We would like to preserve the ability to join an open mesh without a
>> daemon, in the same way that a station can associate with an AP
>> without one.
>
> Keep in mind that even the station case on an open or WEP network is
> pretty useless since it will not reconnect if the connection drops, or
> do any sort of roaming.
>
>> With that goal in mind, the alternatives are to
>> duplicate the MPM in userspace or to reuse the in-kernel MPM with only
>> AMPE in userspace.  Considering that AMPE uses MPM frames and state
>> machines, reusing the in-kernel MPM is a significantly lower effort
>> alternative.  Furthermore, while working on AMPE we can also bring the
>> in-kernel MPM up to spec.
>> Of course this requires agreeing on a suitable API between MPM and
>> AMPE.  If you don't like the generic one I proposed we can try to
>> define a mesh-specific alternative.  But first, setting aside the API change
>> proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition?
>
> 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.

> Since practically speaking, wpa_supplicant is already required for
> almost everything, I don't see any real disadvantages to duplicating the
> MPM state machine there, and starting to deprecate the one in the kernel
> over time with new features only available in userspace one, maybe even
> removing it at some point. I realise this is a little more short-term
> effort, but I think the long-term benefit probably outweighs it.

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.

Thanks for the comments,

Javier