As I was discussing with johill earlier we should probably lay down
the overal layout of what our communication path will look like down
the road between userspace, userspace MLME, cfg8021, nl80211 and
drivers both FullMAC and SoftMAC, This conversation spawned over
implementing the next console userspace configuration utility, iw.
This is necessary so we don't write userspace utilities we later have
to replace or simply start with bad design from the beginning. I think
it will also help set our pace on what items we need to prioritize in
the short term for kernel releases and also on the long run.
What really puzzles me right now is the communication path between
userspace and the userspace MLME, and even if this communication
should exist. I've edited some draft stuff about this and
communication paths. I'd like to ask those of you working on this to
please help fix and update it.
For now I've stashed here:
http://linuxwireless.org/en/developers/todo_list#userspacemlme
Other items which we should consider:
* Should umlme be optional or is this desired mandatory down the road?
* How long should we wait to swich to a umlme?
Luis
On Fri, 2007-09-28 at 20:25 -0400, Luis R. Rodriguez wrote:
> What really puzzles me right now is the communication path between
> userspace and the userspace MLME, and even if this communication
> should exist. I've edited some draft stuff about this and
> communication paths. I'd like to ask those of you working on this to
> please help fix and update it.
>
> For now I've stashed here:
>
> http://linuxwireless.org/en/developers/todo_list#userspacemlme
Ok I looked at this and wasn't really happy with your terminology and
the diagrams, fixed that up. As for userspace tools (nm, iw) -> umlme
communication I've included three alternatives. I personally very much
favour alternative one, will detail that in a separate mail.
> Other items which we should consider:
>
> * Should umlme be optional or is this desired mandatory down the road?
It'll be mandatory for anything that we don't currently do in the
kernel, which will probably include
* 802.11r (fast roaming)
* 802.11s (mesh networking) (not entirely sure what management stuff
this includes)
* 802.11w (encrypted management)
* DLS features of 802.11e
* ... more I'm not thinking of right now
> * How long should we wait to swich to a umlme?
Not at all as soon as we can?
johannes
Ok, here are my thoughts on why alternative one is best. To recap, these
are the alternatives I see when configuring the userspace MLME (copied
from the wiki as I just wrote it there):
Userspace MLME configuration (alternative 1)
nl80211 nl80211
{ nm | iw } -------------> { cfg80211 } -------------> { umlme }
Userspace MLME configuration (alternative 2)
nl80211
{ nm | iw } -------------> { umlme }
Userspace MLME configuration (alternative 3)
socket (*)
{ nm | iw } -------------> { umlme }
Currently, we have alternative three being used by nm and wpa_cli to
configure wpa_supplicant via the control socket.
As I said before, I favour alternative one, for the following reasons:
1) it is transparent
Alternative one means that the userspace tools do not need to know
whether a userspace MLME is used or not. It is completely transparent,
the regular command line tools can be used, tools that need to scan with
certain parameters can just request a scan via the regular mechanism and
expect results.
2) it helps us define the interfaces
With more processing power becoming available in smaller form factors
and more MLME features required by new networked appliances like
cameras, washing machines etc., I expect that full-mac chipsets will
start to become more common again. Especially mesh-networking like used
in the XO may be a push for this. However, it is not clear that
everybody will have drivers for such hardware. Defining the full
interface to the MLME in terms of nl80211 even when most of the MLME is
implemented in userspace allows us to experiment with the full MLME
interface even though we don't always have full-MAC chipsets or drivers
available to experiment with.
3) it is UMLME-agnostic
The current control socket implemented in wpa_supplicant was designed
specifically for wpa_supplicant and much more for the actual WPA
features than all the MLME features. I don't want to say that it is
ill-defined or badly documented, neither seems to be the case, but I do
think that it being defined for wpa_supplicant could be a stumbling
block when you want to implement it within another UMLME.
4) it can support wext
Since we go through the kernel, we can introduce a thunking layer that
makes wext->nl80211 conversions for the userspace MLME and the other way
around for the results. This requires some work and also requires making
wext not take the RTNL so a userspace MLME can't block the RTNL, but is
certainly possible and makes the userspace MLME even transparent to
legacy tools.
Arguments two and three really speak for both alternatives one and two,
while one and four are unique to alternative one.
johannes
On Fri, 2007-09-28 at 20:25 -0400, Luis R. Rodriguez wrote:
> As I was discussing with johill earlier we should probably lay down
> the overal layout of what our communication path will look like down
> the road between userspace, userspace MLME, cfg8021, nl80211 and
> drivers both FullMAC and SoftMAC, This conversation spawned over
> implementing the next console userspace configuration utility, iw.
Oh yeah that reminds me. If you're looking for a way to create or delete
virtual interfaces now that the sysfs interface is gone, try
http://git.sipsolutions.net/iw.git/
And send me patches, best Cc the list too :)
johannes
On Sat, Sep 29, 2007 at 01:49:41PM +0200, Johannes Berg wrote:
> On Fri, 2007-09-28 at 20:25 -0400, Luis R. Rodriguez wrote:
> > * Should umlme be optional or is this desired mandatory down the road?
>
> It'll be mandatory for anything that we don't currently do in the
> kernel, which will probably include
> * 802.11r (fast roaming)
> * 802.11s (mesh networking) (not entirely sure what management stuff
> this includes)
> * 802.11w (encrypted management)
> * DLS features of 802.11e
> * ... more I'm not thinking of right now
Can you elaborate some on why you think umlme is required for these
(or other) functions? It isn't obvious to me that all of these MLME
functions are so complex as to require userland implementations.
Forgive my skepticisim, but in the past umlme has been used as a
religious hammer. I don't want to keep apparently working/workable
code out of the kernel just because someone thinks currently
non-existant umlme code would be a better solution.
Lacking a mature umlme implementation in-hand, I'm not prepared
to accept a preemptive veto on kmlme extensions without seeing the
code first.
John
--
John W. Linville
[email protected]
On Sat, 2007-09-29 at 12:17 -0400, John W. Linville wrote:
> Can you elaborate some on why you think umlme is required for these
> (or other) functions? It isn't obvious to me that all of these MLME
> functions are so complex as to require userland implementations.
> > * 802.11r (fast roaming)
Already has a (partial?) implementation in wpa_supplicant.
> > * 802.11s (mesh networking) (not entirely sure what management stuff
> > this includes)
Not sure really.
> > * 802.11w (encrypted management)
All the key handling is in wpa_supplicant so we will not be able to
support it in the kernel w/o wpa_supplicant and I don't see a good way
to do it in the kernel either (not too familiar with the spec though),
and wpa_supplicant already has a (partial?) implementation.
> > * DLS features of 802.11e
We've had this in the kernel and I'm not generally against it but it's
somewhat strange to have something in the kernel and not be able to use
it. We will of course need some support in the kernel for actually
sending and receiving direct-link data frames.
johannes
On Sat, 2007-09-29 at 14:27 +0200, Johannes Berg wrote:
> 1) it is transparent
> 2) it helps us define the interfaces
> 3) it is UMLME-agnostic
> 4) it can support wext
5) There is no discovery issue
It is always clear which userspace MLME to talk to since it has to
register with the kernel anyway and it can be looked up by the network
interface. With alternatives two and three, userspace must somehow be
able to implement discovery to find the right netlink address/socket/...
to talk to for a certain network interface.
johannes
On Sun, Sep 30, 2007 at 10:43:35AM +0200, Johannes Berg wrote:
> > > * 802.11r (fast roaming)
>
> Already has a (partial?) implementation in wpa_supplicant.
The current implementation is more or less complete for all the required
functionality. I just updated it for the latest draft (D8.0) that was
released last week. This includes code for adding new IEs to
authentication and association frames and also sending/receiving of
action frames.
> > > * 802.11w (encrypted management)
>
> All the key handling is in wpa_supplicant so we will not be able to
> support it in the kernel w/o wpa_supplicant and I don't see a good way
> to do it in the kernel either (not too familiar with the spec though),
> and wpa_supplicant already has a (partial?) implementation.
wpa_supplicant has implementation for negotiating the keys and
configuring them to the driver. It does not implement
encryption/decryption of the management frames, though, and I do not
have plans on doing that in user space either. 802.11w actually uses the
same PTK than data frames for unicast management frames, so the kernel
side (or firmware/hardware) CCMP should be used for this. As far as
broadcast/multicast management frames are concerned, they will need a
new encryption (or well, actually it is not encryption, just integrity
protection) algorithm in the kernel. The key (IGTK) comes from user
space in the same way as GTK for data frames.
In general, 802.11w has quite minimal requirements for the MLME parts
and the key negotiation (part of 4-way handshake) is completely separate
functionality from the encryption/decryption/integrity protection of
management frames.
--
Jouni Malinen PGP id EFC895FA
On Sat, 2007-09-29 at 14:27 +0200, Johannes Berg wrote:
> Ok, here are my thoughts on why alternative one is best. To recap, these
> are the alternatives I see when configuring the userspace MLME (copied
> from the wiki as I just wrote it there):
>
> Userspace MLME configuration (alternative 1)
> nl80211 nl80211
> { nm | iw } -------------> { cfg80211 } -------------> { umlme }
>
> Userspace MLME configuration (alternative 2)
> nl80211
> { nm | iw } -------------> { umlme }
>
> Userspace MLME configuration (alternative 3)
> socket (*)
> { nm | iw } -------------> { umlme }
>
>
> Currently, we have alternative three being used by nm and wpa_cli to
> configure wpa_supplicant via the control socket.
Note that NM 0.7 drives wpa_supplicant over D-Bus. It doesn't use the
wpa_supplicant control socket any more. It was ugly.
> As I said before, I favour alternative one, for the following reasons:
>
> 1) it is transparent
>
> Alternative one means that the userspace tools do not need to know
> whether a userspace MLME is used or not. It is completely transparent,
> the regular command line tools can be used, tools that need to scan with
> certain parameters can just request a scan via the regular mechanism and
> expect results.
>
> 2) it helps us define the interfaces
>
> With more processing power becoming available in smaller form factors
> and more MLME features required by new networked appliances like
> cameras, washing machines etc., I expect that full-mac chipsets will
> start to become more common again. Especially mesh-networking like used
> in the XO may be a push for this. However, it is not clear that
> everybody will have drivers for such hardware. Defining the full
> interface to the MLME in terms of nl80211 even when most of the MLME is
> implemented in userspace allows us to experiment with the full MLME
> interface even though we don't always have full-MAC chipsets or drivers
> available to experiment with.
>
> 3) it is UMLME-agnostic
>
> The current control socket implemented in wpa_supplicant was designed
> specifically for wpa_supplicant and much more for the actual WPA
> features than all the MLME features. I don't want to say that it is
> ill-defined or badly documented, neither seems to be the case, but I do
> think that it being defined for wpa_supplicant could be a stumbling
> block when you want to implement it within another UMLME.
>
> 4) it can support wext
>
> Since we go through the kernel, we can introduce a thunking layer that
> makes wext->nl80211 conversions for the userspace MLME and the other way
> around for the results. This requires some work and also requires making
> wext not take the RTNL so a userspace MLME can't block the RTNL, but is
> certainly possible and makes the userspace MLME even transparent to
> legacy tools.
>
>
> Arguments two and three really speak for both alternatives one and two,
> while one and four are unique to alternative one.
For NM, as long as wpa_supplicant gets ported to use nl80211 (maybe add
another driver_nl80211.c instead of driver_wext.c) then NM should work
fine. I've punted almost all of the direct driver interface code to
wpa_supplicant; NM doesn't touch wireless devices much anymore at all.
Since wpa_supplicant has to get ported to nl80211 _anyway_,
independently of NetworkManager, I figured it would reduce overall work
to make the changes in one place.
Dan
On Tue, 2007-10-02 at 19:50 -0700, Jouni Malinen wrote:
> > > > * 802.11r (fast roaming)
>
> The current implementation is more or less complete for all the required
> functionality. I just updated it for the latest draft (D8.0) that was
> released last week. This includes code for adding new IEs to
> authentication and association frames and also sending/receiving of
> action frames.
Good to know. The latter are passed with SIOCSIWGENIE I assume.
> > > > * 802.11w (encrypted management)
> wpa_supplicant has implementation for negotiating the keys and
> configuring them to the driver. It does not implement
> encryption/decryption of the management frames, though, and I do not
> have plans on doing that in user space either.
Right, that makes sense.
> 802.11w actually uses the
> same PTK than data frames for unicast management frames, so the kernel
> side (or firmware/hardware) CCMP should be used for this.
Yeah we'll probably need a new hw flag for this since I expect there to
be some hardware that will not like hw-crypto for management frames.
OTOH, it could probably better be a key flag or something, not sure
about the details right now. But it should be trivial to solve.
> As far as
> broadcast/multicast management frames are concerned, they will need a
> new encryption (or well, actually it is not encryption, just integrity
> protection) algorithm in the kernel. The key (IGTK) comes from user
> space in the same way as GTK for data frames.
Right, so we need a new cipher added to nl80211's checking code and make
mac80211 handle that new cipher. It needs to be implemented too, but
right now I definitely won't have time for that and the 802.11w draft I
have may well be outdated too.
In any case, it doesn't look like a hard problem to solve once we have
the algorithm spec.
johannes