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

[Javier Cardona <javier@cozybit.com>]

On Tue, Apr 5, 2011 at 12:07 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-04-04 at 19:06 -0700, Javier Cardona wrote:
>> This is useful for implementing frame protection in userspace. The kernel may
>> request a userspace daemon to verify a frame (sent to userspace via
>> cfg80211_rx_mgmt()).  The userspace daemon can then pass back the
>> verified/unprotected frame to the stack for further processing (via a
>> self-addressed frame sent with cfg80211_mlme_mgmt_tx())
>>
>> We are using this for our implementation authenticated peering.  11s defines
>> two versions of mesh peering, the non-secure mesh peering management (MPM) and
>> the Authenticated Mesh Peering Exchange (AMPE).  The latter is based on the
>> exact same state machine as MPM.  It is really convenient to use the in-kernel
>> MPM with a minimal userspace daemon to add the security bits introduced by
>> AMPE.  This way both secured and open mesh networks can use exact same peering
>> code.
>>
>> What do you think... will this fly?
>
> Seems very strange to me. I guess if you're after unification in my mind
> it makes more sense to declare the in-kernel state machine legacy, copy
> it into the userspace tool and use it even for unprotected MPM?


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

Cheers,

Javier