userspace MLME

userspace MLME

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

Here's a repost of my thoughts I just posted deep in that other thread.
If you read it, please reply here, otherwise it's good that I'm
reposting, right? :) Sorry for sending it twice, but some more thoughts
might follow so I'd rather split it off from the other thread

IMHO, in order to get the userspace MLME idea to take off, somebody
really needs to

 1) repost/integrate the injection patches
 2) implement a nl80211 API for the userspace MLME
 3) fix the userspace MLME implementation stuff in mac80211 to work with
    the injection patches and the new nl80211 API
 4) publish an adapted userspace MLME that uses this (or patches to wpa
    supplicant)
 5) write some documentation
 6) put that userspace MLME into git, publish the tree on kernel.org and
    maintain it
 7) decree that wpa supplicant is on-topic for linux-wireless


Some of these have sub-points:
 2a) in mac80211, rip out all the userspace MLME stuff and analyse what
     is required
 2b) add the commands to nl80211 (make sure that only one userspace MLME
     can drive a single interface)
 2c) add the commands to cfg80211
 2d) re-implement the commands in mac80211 based on cfg80211
 2e) since we want to be able to configure the userspace MLME through
     the kernel, implement nl80211 command forwarding to the userspace
     MLME [1]

[1] Actually, I'd think that *all* commands should be forwarded to the
userspace MLME except for commands *from* the userspace MLME. That way,
the userspace MLME can act as a filter for commands which should make a
whole bunch of things easier.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: userspace MLME

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Fri, 2007-06-08 at 11:35 +0200, Johannes Berg wrote:

>  1) repost/integrate the injection patches

1b) do that filtering work we talked about
1c) implement the variety of monitor modes and that promisc bit
    passing through to drivers

> [1] Actually, I'd think that *all* commands should be forwarded to the
> userspace MLME except for commands *from* the userspace MLME. That way,
> the userspace MLME can act as a filter for commands which should make a
> whole bunch of things easier.

Ok so I just talked about this with Thomas Graf and Herbert Xu and
Herbert suggested that we solves the "single userspace MLME" only issue
in userspace. Then, we create a new multicast group for "userspace MLME"
that it signs up for. Then, we can use netlink_has_listeners to decide
whether there's a userspace MLME or not (we could even add a new command
"is userspace MLME present" based on that)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]