Setting channel when interface is down inconsistency

Setting channel when interface is down inconsistency

[Jon Smirl]

bcm43xx and rx2x00 let me set the channel before the interface is up.
zd1211 requires the interface to be up before setting the channel.

Is there a guideline for how this is supposed to work?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Setting channel when interface is down inconsistency

[Dan Williams]

On Mon, 2007-07-09 at 10:59 -0400, Jon Smirl wrote:
> bcm43xx and rx2x00 let me set the channel before the interface is up.
> zd1211 requires the interface to be up before setting the channel.
> 
> Is there a guideline for how this is supposed to work?

In the ideal case, the driver should allow you to set any _attribute_
when the device is down, but if you try to do an _action_ that requires
that the interface be up (for example, associating), it should return an
error of some kind.

So setting things like encryption key, channel, ssid, bssid, etc should
all work when the device is down, but actually issuing the 'iwconfig
wlan0 ssid "foobar"' can be expected to fail because in WEXT that is
supposed to trigger an association.

Splitting up this stuff and having an explicit association request in
nl80211/cfg80211 should make this a lot clearer.  Most drivers don't do
this consistently right now because they often assume that they can
write the new values to card registers and such instead of putting them
into a shadow state structure internally in the driver.

Dan

Re: Setting channel when interface is down inconsistency

[Johannes Berg]

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

On Mon, 2007-07-09 at 14:31 -0400, Dan Williams wrote:
> On Mon, 2007-07-09 at 10:59 -0400, Jon Smirl wrote:
> > bcm43xx and rx2x00 let me set the channel before the interface is up.
> > zd1211 requires the interface to be up before setting the channel.
> > 
> > Is there a guideline for how this is supposed to work?
> 
> In the ideal case, the driver should allow you to set any _attribute_
> when the device is down, but if you try to do an _action_ that requires
> that the interface be up (for example, associating), it should return an
> error of some kind.
> 
> So setting things like encryption key, channel, ssid, bssid, etc should
> all work when the device is down, but actually issuing the 'iwconfig
> wlan0 ssid "foobar"' can be expected to fail because in WEXT that is
> supposed to trigger an association.
> 
> Splitting up this stuff and having an explicit association request in
> nl80211/cfg80211 should make this a lot clearer.

In fact, the way it's planned now is that you can't even give it an
ssid/bssid etc. without also triggering an association, but contrary to
wext you do pass all parameters at once and when needed.

Hence, this will not actually solve the problem per se, we could make it
a requirement either way to document it (though in fact it'd be simple
to return -ENOTCONN for every configuration request when the device is
down) but setting the channel for example isn't actually any different
than with wext. Therefore, I think we still need a guideline. Do you
think setting everything when the device is down makes sense? Then we'll
have to document that drivers must accept these requests and honour them
when the device is turned on. Which is actually another thing we need to
make absolutely sure, when the netdev is down the device should be
turned off.

johannes

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

Re: Setting channel when interface is down inconsistency

[Dan Williams]

On Wed, 2007-07-11 at 00:50 +0200, Johannes Berg wrote:
> On Mon, 2007-07-09 at 14:31 -0400, Dan Williams wrote:
> > On Mon, 2007-07-09 at 10:59 -0400, Jon Smirl wrote:
> > > bcm43xx and rx2x00 let me set the channel before the interface is up.
> > > zd1211 requires the interface to be up before setting the channel.
> > > 
> > > Is there a guideline for how this is supposed to work?
> > 
> > In the ideal case, the driver should allow you to set any _attribute_
> > when the device is down, but if you try to do an _action_ that requires
> > that the interface be up (for example, associating), it should return an
> > error of some kind.
> > 
> > So setting things like encryption key, channel, ssid, bssid, etc should
> > all work when the device is down, but actually issuing the 'iwconfig
> > wlan0 ssid "foobar"' can be expected to fail because in WEXT that is
> > supposed to trigger an association.
> > 
> > Splitting up this stuff and having an explicit association request in
> > nl80211/cfg80211 should make this a lot clearer.
> 
> In fact, the way it's planned now is that you can't even give it an
> ssid/bssid etc. without also triggering an association, but contrary to
> wext you do pass all parameters at once and when needed.
> 
> Hence, this will not actually solve the problem per se, we could make it
> a requirement either way to document it (though in fact it'd be simple
> to return -ENOTCONN for every configuration request when the device is
> down) but setting the channel for example isn't actually any different
> than with wext. Therefore, I think we still need a guideline. Do you
> think setting everything when the device is down makes sense? Then we'll

The more I think about it the more I think you're right; because with
WEXT there was really no ordering guarantee.  With the new stuff as long
as there's an ordering guarantee, I think it'll be fine.

But, of course, we need to make sure that we are consistent and that if
we really don't allow configuration when the device is down, that all
drivers return error when they are down.

Dan

> have to document that drivers must accept these requests and honour them
> when the device is turned on. Which is actually another thing we need to
> make absolutely sure, when the netdev is down the device should be
> turned off.
> 
> johannes

Re: Setting channel when interface is down inconsistency

[Johannes Berg]

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

On Wed, 2007-07-11 at 17:18 -0400, Dan Williams wrote:

> But, of course, we need to make sure that we are consistent and that if
> we really don't allow configuration when the device is down, that all
> drivers return error when they are down.

If we want to go the way of not allowing configuration when the device
is down we can easily check and return an error in cfg80211; if we do
want to allow configuration when it is down we have to make sure all
drivers support that.

johannes

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