Hi,
I know this has been discussed a bunch of times and also at the London
summit but I'm still not convinced.
In London, we've talked a lot about separating actions from settings.
I've thought about this again and again but haven't really made sense of
it yet.
To me, separating actions from settings is basically this procedure:
(1) give the kernel a bunch of parameters
(2) give it some other parameter
(3) change some parameters again
(4) tell it to use the "current parameters" to do X
(where X may be "associate", "authenticate", ...)
[with possibly added "(3') wtf did I set there? let me query the kernel
for it"]
That's also how the current wext interface works as well as how the
currently unimplemented nl80211 interface is defined.
However, I don't see why we shouldn't go to a model where we give the
kernel all information it needs to do an operation when we want it to do
it, like the procedure
(1) tell the kernel to do X
- using parameter A=B
- using parameter C=D
- ...
(2) tell the kernel to do Y
The parameters here would be an SSID, BSSID, channel, key, ... We'd
completely get rid of the ->configure call in cfg80211 if we did this.
This would also be a lot more in line with primitives outlined in the
IEEE 802.11 specification, like MLME-ASSOCIATE.request et al. In fact,
it seems that the interface could be modelled pretty much after the MLME
SAP interface outlined in clause 10.3.
Obviously, we wouldn't need to actually have all of them. For example,
MLME-START.request for BSSes wouldn't be implemented within mac80211 but
rather in hostapd. I don't know how ipw2200 master mode works though,
maybe we would in fact need to have the MLME-START.request in nl80211
for some devices. For a whole range of hardware MLME-JOIN also makes no
sense, but for bcm43xx for example it almost would [1].
To fully do this we'd have to get rid of the intrinsic "mode" of a
device, the mode would be decided based on what you want to do with the
device: start an IBSS or a BSS, join an existing (I)BSS etc. I actually
like that.
Of course this is not sufficient; since we still want to move to a
userspace MLME a lot of lower level primitives need to be added since we
then need to have a MAC/MLME communication interface as well, similar
for hostapd.
It still seems to me that this would make a lot of sense and get us some
more implicit documentation by referring to the 802.11 spec. Where's the
problem with this?
johannes
[1] The action taken on MLME-JOIN.request would be to set the BSSID for
the firmware. However, the firmware doesn't generate MLME-JOIN.confirm
so you'd have to set the TSF to 0 and then check if the firmware changed
it to be able to generate MLME-JOIN.confirm. It's entirely possible :)
On Fri, 2007-03-16 at 16:39 +0100, Jiri Benc wrote:
> I think I was one of people who differentiated "config" and "action"
> calls. The problem with wext is that we don't know when association
> should take place. (When setting a parameter? Which one?)
Yeah, I agree.
> We need to
> have a well defined place at which association occurs. I don't care how
> this is achieved as long as it's fulfilled. One solution is to have a
> separate (that doesn't mean it cannot be bundled with other commands)
> "associate" request. There are surely other solutions.
Well what I'm thinking now is that we should have an "associate" request
and all the stuff that previously was "config" requests is just data
items appended to that associate request.
johannes
On Thu, 2007-03-08 at 20:09 +0100, Johannes Berg wrote:
> On Wed, 2007-03-07 at 16:49 -0800, Jouni Malinen wrote:
>
> > And where would
> > (5) change some parameters within this association without triggering
> > new authentication/association
> > fit in?
>
> For that case it's just a new configure command I suppose.
>
> > > However, I don't see why we shouldn't go to a model where we give the
> > > kernel all information it needs to do an operation when we want it to do
> > > it, like the procedure
> > > (1) tell the kernel to do X
> > > - using parameter A=B
> > > - using parameter C=D
> > > - ...
> > > (2) tell the kernel to do Y
> >
> > Would this be all parameters as in _no_ other parameters could be set
> > before or after the command? As an example, how would one set
> > fragmentation threshold and then change that value after having
> > associated?
>
> Actually, things like the fragmentation threshold or say rx sensitivity
> (where it can be set) don't really influence the association so for
> those I'd think they are out of scope for the MLME SAP primitives.
>
> > MLME SAP primitives may be okay for many cases, but we cannot limit
> > ourselves to just the parameters defined there. Number of parameters do
> > not go through MLME SAP interface and some of the options may require
> > getting used to (e.g., power management options would use their own
> > primitive, not MLME-ASSOCIATE, etc.).
>
> Right.
>
> > MLME SAP interface is between MLME and SME, but when we have some parts
> > of MLME in user space and some in kernel, things can get bit confusing
> > since the interface between MLME and SME is not the same as interface
> > between kernel and user space.
>
> True.
>
> I think what I should have said when I wrote this email is that I
> dislike having this "transaction layer" in the kernel where you set a
> bunch of settings and then "commit" them by saying "please associate now
> with whatever settings I told you to use".
So when wpa_supplicant or whatever has to do rekeying, or if I want to
change some parameter but not completely re-associate, how does that
work?
> What I'd like to see instead is that you give the MLME (whether it's in
> the kernel or in userspace[1]) all the parameters it needs to do one
> action when telling it to do that action.
I'd basically expected that this was the model we'd be using anyway. A
user tool wouldn't have to:
set ssid
set key
set authmode
associate
but instead bundle all those up into one message to netlink with the
"associate" command or something. I wasn't expecting each setting to be
broken down into a separate message and then have a final "commit"
command like with WEXT right now. That sucks and makes command ordering
ambiguous.
I'd much rather conceptually have the following (in python-esque), which
is what I thought it would be more like...
err = associate(ssid="foo", key=0x435223, auth="shared")
<rekey>
err = set(key=0x235326563)
Dan
> I'm not saying that we should limit ourselves to the parameters outlined
> in the MLME SAP interface nor that we should really follow it closely.
>
> johannes
>
> [1] since we said we'd want the userspace mlme to be controlled by
> nl80211 through the kernel
On Tue, Mar 06, 2007 at 11:20:49PM +0100, Johannes Berg wrote:
> To me, separating actions from settings is basically this procedure:
> (1) give the kernel a bunch of parameters
> (2) give it some other parameter
> (3) change some parameters again
> (4) tell it to use the "current parameters" to do X
> (where X may be "associate", "authenticate", ...)
And where would
(5) change some parameters within this association without triggering
new authentication/association
fit in?
> However, I don't see why we shouldn't go to a model where we give the
> kernel all information it needs to do an operation when we want it to do
> it, like the procedure
> (1) tell the kernel to do X
> - using parameter A=B
> - using parameter C=D
> - ...
> (2) tell the kernel to do Y
Would this be all parameters as in _no_ other parameters could be set
before or after the command? As an example, how would one set
fragmentation threshold and then change that value after having
associated?
> This would also be a lot more in line with primitives outlined in the
> IEEE 802.11 specification, like MLME-ASSOCIATE.request et al. In fact,
> it seems that the interface could be modelled pretty much after the MLME
> SAP interface outlined in clause 10.3.
MLME SAP primitives may be okay for many cases, but we cannot limit
ourselves to just the parameters defined there. Number of parameters do
not go through MLME SAP interface and some of the options may require
getting used to (e.g., power management options would use their own
primitive, not MLME-ASSOCIATE, etc.).
> Obviously, we wouldn't need to actually have all of them. For example,
> MLME-START.request for BSSes wouldn't be implemented within mac80211 but
> rather in hostapd. I don't know how ipw2200 master mode works though,
> maybe we would in fact need to have the MLME-START.request in nl80211
> for some devices. For a whole range of hardware MLME-JOIN also makes no
> sense, but for bcm43xx for example it almost would [1].
MLME SAP interface is between MLME and SME, but when we have some parts
of MLME in user space and some in kernel, things can get bit confusing
since the interface between MLME and SME is not the same as interface
between kernel and user space.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2007-03-07 at 16:49 -0800, Jouni Malinen wrote:
> And where would
> (5) change some parameters within this association without triggering
> new authentication/association
> fit in?
For that case it's just a new configure command I suppose.
> > However, I don't see why we shouldn't go to a model where we give the
> > kernel all information it needs to do an operation when we want it to do
> > it, like the procedure
> > (1) tell the kernel to do X
> > - using parameter A=B
> > - using parameter C=D
> > - ...
> > (2) tell the kernel to do Y
>
> Would this be all parameters as in _no_ other parameters could be set
> before or after the command? As an example, how would one set
> fragmentation threshold and then change that value after having
> associated?
Actually, things like the fragmentation threshold or say rx sensitivity
(where it can be set) don't really influence the association so for
those I'd think they are out of scope for the MLME SAP primitives.
> MLME SAP primitives may be okay for many cases, but we cannot limit
> ourselves to just the parameters defined there. Number of parameters do
> not go through MLME SAP interface and some of the options may require
> getting used to (e.g., power management options would use their own
> primitive, not MLME-ASSOCIATE, etc.).
Right.
> MLME SAP interface is between MLME and SME, but when we have some parts
> of MLME in user space and some in kernel, things can get bit confusing
> since the interface between MLME and SME is not the same as interface
> between kernel and user space.
True.
I think what I should have said when I wrote this email is that I
dislike having this "transaction layer" in the kernel where you set a
bunch of settings and then "commit" them by saying "please associate now
with whatever settings I told you to use".
What I'd like to see instead is that you give the MLME (whether it's in
the kernel or in userspace[1]) all the parameters it needs to do one
action when telling it to do that action.
I'm not saying that we should limit ourselves to the parameters outlined
in the MLME SAP interface nor that we should really follow it closely.
johannes
[1] since we said we'd want the userspace mlme to be controlled by
nl80211 through the kernel
On Thu, 2007-03-08 at 14:36 -0500, Dan Williams wrote:
> So when wpa_supplicant or whatever has to do rekeying, or if I want to
> change some parameter but not completely re-associate, how does that
> work?
I suppose it'll be a different command. But SetKeys() is already an MLME
primitive in the specs :)
> > What I'd like to see instead is that you give the MLME (whether it's in
> > the kernel or in userspace[1]) all the parameters it needs to do one
> > action when telling it to do that action.
>
> I'd basically expected that this was the model we'd be using anyway. A
> user tool wouldn't have to:
>
> set ssid
> set key
> set authmode
> associate
>
> but instead bundle all those up into one message to netlink with the
> "associate" command or something.
Right. However, as far as I understood some people at the wireless
summit, they'd prefer having one command that bundles all the settings
and then another one that applies them. Maybe it's just a
misunderstanding on my part and this whole thread is pointless?
> I'd much rather conceptually have the following (in python-esque), which
> is what I thought it would be more like...
>
> err = associate(ssid="foo", key=0x435223, auth="shared")
> <rekey>
> err = set(key=0x235326563)
Yup, makes sense to me.
johannes
On Thu, 08 Mar 2007 20:36:46 +0100, Johannes Berg wrote:
> On Thu, 2007-03-08 at 14:36 -0500, Dan Williams wrote:
> > I'd basically expected that this was the model we'd be using anyway. A
> > user tool wouldn't have to:
> >
> > set ssid
> > set key
> > set authmode
> > associate
> >
> > but instead bundle all those up into one message to netlink with the
> > "associate" command or something.
>
> Right. However, as far as I understood some people at the wireless
> summit, they'd prefer having one command that bundles all the settings
> and then another one that applies them. Maybe it's just a
> misunderstanding on my part and this whole thread is pointless?
I think I was one of people who differentiated "config" and "action"
calls. The problem with wext is that we don't know when association
should take place. (When setting a parameter? Which one?) We need to
have a well defined place at which association occurs. I don't care how
this is achieved as long as it's fulfilled. One solution is to have a
separate (that doesn't mean it cannot be bundled with other commands)
"associate" request. There are surely other solutions.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs