Dscape ieee80211: enabling/disabling the radio

Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn]

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

Hi,

While working on the rt2x00 driver, I keep hitting against some problems with scanning.
Basicly the dscape stack handles scanning in 2 ways, through the
passive_scan() handler in the ieee80211_hw structure, and by calling
the config() handler in the ieee80211_hw stucture.

The usage of the first handler, does not give any problems at this time.
The main source of problems during scanning in rt2x00 seems to come
when the config() handler is used.

In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
this is required since several configuration changes in rt2x00 need sleeping and for
USB devices all register access requires sleeping. And the config() handler is often
called from interrupt context so it complains a lot when the workqueue is not used.

This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
When the radio_enable field is set, the radio must be enabled, but enabling
the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
to the workqueue is not something that is desired since the stack can not be notified that the
device is not able to enable the radio.

Moving the enabling of the radio outside the workqueue function and into the config()
handler results in scheduling while atomic issues since the enabling of the radio requires
sleeping for both PCI and USB devices.

Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
If these functions are called from normal context the dscape stack can still enable
and disable the radio whenever it is desired, and it is able to check the return value
to see if the request has actually succeeded.

What I am wondering about afterwards is what exactly should happen when the open()
and stop() handlers are being called? Because those are basicly intented to enable
and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
to check the radio_enabled field, so I don't know what they do besides enabling the radio.

Well this was just some stuff I have been trying to figure out while trying to solve several
rt2x00 bugs... ;)

Regards,

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn]

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

> While working on the rt2x00 driver, I keep hitting against some problems with scanning.
> Basicly the dscape stack handles scanning in 2 ways, through the
> passive_scan() handler in the ieee80211_hw structure, and by calling
> the config() handler in the ieee80211_hw stucture.
> 
> The usage of the first handler, does not give any problems at this time.
> The main source of problems during scanning in rt2x00 seems to come
> when the config() handler is used.
> 
> In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
> this is required since several configuration changes in rt2x00 need sleeping and for
> USB devices all register access requires sleeping. And the config() handler is often
> called from interrupt context so it complains a lot when the workqueue is not used.
> 
> This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
> When the radio_enable field is set, the radio must be enabled, but enabling
> the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
> to the workqueue is not something that is desired since the stack can not be notified that the
> device is not able to enable the radio.
> 
> Moving the enabling of the radio outside the workqueue function and into the config()
> handler results in scheduling while atomic issues since the enabling of the radio requires
> sleeping for both PCI and USB devices.
> 
> Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
> to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
> If these functions are called from normal context the dscape stack can still enable
> and disable the radio whenever it is desired, and it is able to check the return value
> to see if the request has actually succeeded.
> 
> What I am wondering about afterwards is what exactly should happen when the open()
> and stop() handlers are being called? Because those are basicly intented to enable
> and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
> to check the radio_enabled field, so I don't know what they do besides enabling the radio.
> 
> Well this was just some stuff I have been trying to figure out while trying to solve several
> rt2x00 bugs... ;)

A user on the forums Olivier Cornu (added to the CC list) has done some investigation into the
scanning behaviour of the dscape stack.
Basicly the dscape stack is performing active scanning while the device is down,
but during the active scan it is sending packets out, or at least attempting to do so.
Besides the question if active scanning is preferred over passive scanning while interface is down,
active scanning fails because the packets that should be send are being send through the regular
xmit routines of the interface. (IFF_UP is not set for the interface)

This means that besides enabling the radio which should be done in the driver, the stack should either bring
up the interface when doing an active scan, or resort to passive scanning while interface is down.

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Dscape ieee80211: enabling/disabling the radio

[Michael Wu]

On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
> A user on the forums Olivier Cornu (added to the CC list) has done some
> investigation into the scanning behaviour of the dscape stack.
> Basicly the dscape stack is performing active scanning while the device is
> down, but during the active scan it is sending packets out, or at least
> attempting to do so. Besides the question if active scanning is preferred
> over passive scanning while interface is down, active scanning fails
> because the packets that should be send are being send through the regular
> xmit routines of the interface. (IFF_UP is not set for the interface)
>
> This means that besides enabling the radio which should be done in the
> driver, the stack should either bring up the interface when doing an active
> scan, or resort to passive scanning while interface is down.
>
If you can passive scan while the interface is down, I don't think it's really 
down. In adm8211, nothing can be sent or received when the interface is down. 
The radio is always off when the interface is down. Taking the interface up 
just for a scan and then taking it back down doesn't sound too good either. I 
think scans should be prohibited while the interface is down, since leaving 
the interface on isn't gonna do anything bad unless you put in the info to 
associate.

-Michael Wu

Re: Dscape ieee80211: enabling/disabling the radio

[Olivier]

2006/5/10, Michael Wu <flamingice@sourmilk.net>:
> On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
> > A user on the forums Olivier Cornu (added to the CC list) has done some
> > investigation into the scanning behaviour of the dscape stack.
> > Basicly the dscape stack is performing active scanning while the device is
> > down, but during the active scan it is sending packets out, or at least
> > attempting to do so. Besides the question if active scanning is preferred
> > over passive scanning while interface is down, active scanning fails
> > because the packets that should be send are being send through the regular
> > xmit routines of the interface. (IFF_UP is not set for the interface)
> >
> > This means that besides enabling the radio which should be done in the
> > driver, the stack should either bring up the interface when doing an active
> > scan, or resort to passive scanning while interface is down.
> >
> If you can passive scan while the interface is down, I don't think it's really
> down. In adm8211, nothing can be sent or received when the interface is down.
> The radio is always off when the interface is down. Taking the interface up
> just for a scan and then taking it back down doesn't sound too good either. I
> think scans should be prohibited while the interface is down, since leaving
> the interface on isn't gonna do anything bad unless you put in the info to
> associate.
>
> -Michael Wu
>

What do you mean exactly by "device is down, but not really down"?
I thought a network device was called "down" when the IFF_UP flag of
its net_device struct was set to 0 (thus not appearing in ifconfig,
among other things). Is there any other alternative understanding of
it being "down" i'm not aware of?

I confirm scanning actively with the device down is possible using
another NIC/driver. Thus I guess it's normal behaviour.
I still have to figure out how to do it using the dscape 802.11 stack
(if it's actually possible)...

Olivier Cornu

Re: Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn]

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

On Wednesday 10 May 2006 00:36, Michael Wu wrote:
> On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote:
> > A user on the forums Olivier Cornu (added to the CC list) has done some
> > investigation into the scanning behaviour of the dscape stack.
> > Basicly the dscape stack is performing active scanning while the device is
> > down, but during the active scan it is sending packets out, or at least
> > attempting to do so. Besides the question if active scanning is preferred
> > over passive scanning while interface is down, active scanning fails
> > because the packets that should be send are being send through the regular
> > xmit routines of the interface. (IFF_UP is not set for the interface)
> >
> > This means that besides enabling the radio which should be done in the
> > driver, the stack should either bring up the interface when doing an active
> > scan, or resort to passive scanning while interface is down.
> >
> If you can passive scan while the interface is down, I don't think it's really 
> down. In adm8211, nothing can be sent or received when the interface is down. 
> The radio is always off when the interface is down. Taking the interface up 
> just for a scan and then taking it back down doesn't sound too good either. I 
> think scans should be prohibited while the interface is down, since leaving 
> the interface on isn't gonna do anything bad unless you put in the info to 
> associate.

True, I agree here. But when rt2x00 was using the ipw stack a much
requested feature from users was to be able to perform scanning while
interface was down. (The requests did not specify if it they wanted passive or active scanning)
But the reason for these requests was that some user space applications and/or
distribution network scripts relied on the fact that the driver was capable of scanning
while the interface was down, so the interface would only be brought up at boot time,
when there was no desired AP in the scan result.
I don't know which distributions or user space application these were, but due to the amount
of these requests it had been considered an important feature.

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Dscape ieee80211: enabling/disabling the radio

[Jiri Benc]

On Wed, 10 May 2006 15:37:11 +0200, Ivo van Doorn wrote:
> True, I agree here. But when rt2x00 was using the ipw stack a much
> requested feature from users was to be able to perform scanning while
> interface was down. (The requests did not specify if it they wanted passive or active scanning)
> But the reason for these requests was that some user space applications and/or
> distribution network scripts relied on the fact that the driver was capable of scanning
> while the interface was down, so the interface would only be brought up at boot time,
> when there was no desired AP in the scan result.

Such applications and scripts are broken. Let your users fill bug
reports to their distribution bugzillas.

> I don't know which distributions or user space application these were, but due to the amount
> of these requests it had been considered an important feature.

I wouldn't consider breaking the way the whole Linux networking works as
a feature.

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Dscape ieee80211: enabling/disabling the radio

[Jiri Benc]

On Wed, 10 May 2006 00:01:16 +0200, Ivo van Doorn wrote:
> Basicly the dscape stack is performing active scanning while the device is down,
> but during the active scan it is sending packets out, or at least attempting to do so.
> Besides the question if active scanning is preferred over passive scanning while interface is down,
> active scanning fails because the packets that should be send are being send through the regular
> xmit routines of the interface. (IFF_UP is not set for the interface)

When all interfaces are down, the card must be completely disabled. No
transmitting, no receiving. Currently, there is a (minor) bug in IBSS
code in d80211 stack which tries to perform scanning even when the
interface is down. It's not so important because generated probe
requests are never delivered to the driver if the card is disabled (i.e.
no interfaces are up).

> This means that besides enabling the radio which should be done in the driver, the stack should either bring
> up the interface when doing an active scan, or resort to passive scanning while interface is down.

The stack should not perform any scanning when the interface is not up.

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn]

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

On Wednesday 10 May 2006 12:52, Jiri Benc wrote:
> On Wed, 10 May 2006 00:01:16 +0200, Ivo van Doorn wrote:
> > Basicly the dscape stack is performing active scanning while the device is down,
> > but during the active scan it is sending packets out, or at least attempting to do so.
> > Besides the question if active scanning is preferred over passive scanning while interface is down,
> > active scanning fails because the packets that should be send are being send through the regular
> > xmit routines of the interface. (IFF_UP is not set for the interface)
> 
> When all interfaces are down, the card must be completely disabled. No
> transmitting, no receiving. Currently, there is a (minor) bug in IBSS
> code in d80211 stack which tries to perform scanning even when the
> interface is down. It's not so important because generated probe
> requests are never delivered to the driver if the card is disabled (i.e.
> no interfaces are up).
> 
> > This means that besides enabling the radio which should be done in the driver, the stack should either bring
> > up the interface when doing an active scan, or resort to passive scanning while interface is down.
> 
> The stack should not perform any scanning when the interface is not up.

Ok thanks. Along with the previous mail about the add_interface and remove_interface this
clears up some misunderstanding about the scanning behaviour. ;)

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Dscape ieee80211: enabling/disabling the radio

[Jiri Benc]

On Sat, 6 May 2006 14:00:58 +0200, Ivo van Doorn wrote:
> In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
> this is required since several configuration changes in rt2x00 need sleeping and for
> USB devices all register access requires sleeping. And the config() handler is often
> called from interrupt context so it complains a lot when the workqueue is not used.
> 
> This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
> When the radio_enable field is set, the radio must be enabled, but enabling
> the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
> to the workqueue is not something that is desired since the stack can not be notified that the
> device is not able to enable the radio.

This is probably more general problem. I can imagine a card that will
need to sleep to switch channels and can fail. This doesn't matter now
(as we cannot handle failure in switching channels) but it should be
solved in some way.

Currently, only switching channels is made in interrupt context. You can
depend on this for now.

> Moving the enabling of the radio outside the workqueue function and into the config()
> handler results in scheduling while atomic issues since the enabling of the radio requires
> sleeping for both PCI and USB devices.

Or am I wrong? I see no place when radio_enabled is changed in interrupt context.

> Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
> to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
> If these functions are called from normal context the dscape stack can still enable
> and disable the radio whenever it is desired, and it is able to check the return value
> to see if the request has actually succeeded.

I don't think this is the best idea. In such case we would need to move
almost all the stuff from ieee80211_conf to separate functions. This is
something we don't want.

> What I am wondering about afterwards is what exactly should happen when the open()
> and stop() handlers are being called? Because those are basicly intented to enable
> and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
> to check the radio_enabled field, so I don't know what they do besides enabling the radio.

open and stop callbacks are obsolete. They were replaced by
add_interface and remove_interface callbacks and will be removed after
drivers are converted to use the new callbacks.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Dscape ieee80211: enabling/disabling the radio

[Ivo van Doorn]

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

On Wednesday 10 May 2006 12:42, Jiri Benc wrote:
> On Sat, 6 May 2006 14:00:58 +0200, Ivo van Doorn wrote:
> > In rt2x00 the config() handler schedules all configuration changes by using a workqueue,
> > this is required since several configuration changes in rt2x00 need sleeping and for
> > USB devices all register access requires sleeping. And the config() handler is often
> > called from interrupt context so it complains a lot when the workqueue is not used.
> > 
> > This seemed fine, untill the radio_enabled field was introduced to the configuration structure.
> > When the radio_enable field is set, the radio must be enabled, but enabling
> > the radio is something that can (at least in rt2x00) fail. So scheduling the enabling of the radio
> > to the workqueue is not something that is desired since the stack can not be notified that the
> > device is not able to enable the radio.
> 
> This is probably more general problem. I can imagine a card that will
> need to sleep to switch channels and can fail. This doesn't matter now
> (as we cannot handle failure in switching channels) but it should be
> solved in some way.
> 
> Currently, only switching channels is made in interrupt context. You can
> depend on this for now.
> 
> > Moving the enabling of the radio outside the workqueue function and into the config()
> > handler results in scheduling while atomic issues since the enabling of the radio requires
> > sleeping for both PCI and USB devices.
> 
> Or am I wrong? I see no place when radio_enabled is changed in interrupt context.

I think the problem is what the dscape exactly expects the driver to do when
add_interface() is called by the stack. When that call has finished, does the stack
expects the radio to be enabled, or should it instruct the driver to enable the radio later
on through a field in the config structure.

What currently happens in rt2x00 (Which might not be doing what the stack expects)
is that when add_interface() is called the radio remains off untill open() is called or
radio_enabled has been set in the config structure.
What happens is that the first call of config() (which is being made before open()) comes
from the scan handler requesting a channel change, which is in interrupt context, but
when the channel is changed, the radio is also supposed to be enabled which results
in the problems of radio enabling requirement to be scheduled.

But this might be resolved by demanding that the driver is keeping track of the number
of interfaces added, and enabling the radio when at least 1 interface has been added
and only disable the radio when all interfaces have been removed. And completely
remove the open() and stop() handlers since they would only confuse matters.

> > Instead of using a config field radio_enabled, wouldn't it be better to add 2 handlers
> > to the ieee80211_hw structure, something like enable_radio() and disable_radio()?
> > If these functions are called from normal context the dscape stack can still enable
> > and disable the radio whenever it is desired, and it is able to check the return value
> > to see if the request has actually succeeded.
> 
> I don't think this is the best idea. In such case we would need to move
> almost all the stuff from ieee80211_conf to separate functions. This is
> something we don't want.

True, but I actually meant that these 2 functions would replace the open() and stop() functions.
Which is not required if the above suggestion of the number of added interfaces counter
is applied to the drivers.

> > What I am wondering about afterwards is what exactly should happen when the open()
> > and stop() handlers are being called? Because those are basicly intented to enable
> > and stop the radio as well. I checked bcm43xx to see what they do, and they don't seem
> > to check the radio_enabled field, so I don't know what they do besides enabling the radio.
> 
> open and stop callbacks are obsolete. They were replaced by
> add_interface and remove_interface callbacks and will be removed after
> drivers are converted to use the new callbacks.

Ah ok, I'll fix rt2x00 then to do the correct behaviour and no longer rely on open() and stop()
for the radio, and add the counter for the number of interfaces that are up so the radio
will behave in the correct fashion. :)

Thanks.

Ivo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Dscape ieee80211: enabling/disabling the radio

[Jiri Benc]

On Wed, 10 May 2006 15:53:48 +0200, Ivo van Doorn wrote:
> I think the problem is what the dscape exactly expects the driver to do when
> add_interface() is called by the stack. When that call has finished, does the stack
> expects the radio to be enabled, or should it instruct the driver to enable the radio later
> on through a field in the config structure.

At least for now, enabled if this is the first interface going up. Of
course, if a second (or so) interface is added, you shouldn't reenable
radio if it was disabled by previous config() call.

> But this might be resolved by demanding that the driver is keeping track of the number
> of interfaces added, and enabling the radio when at least 1 interface has been added
> and only disable the radio when all interfaces have been removed. And completely
> remove the open() and stop() handlers since they would only confuse matters.

Yes, this is the way it is supposed to work.

> Ah ok, I'll fix rt2x00 then to do the correct behaviour and no longer rely on open() and stop()
> for the radio, and add the counter for the number of interfaces that are up so the radio
> will behave in the correct fashion. :)

Please see http://www.spinics.net/lists/netdev/msg03975.html (and
following thread probably as well) for a description how to implement
this correctly.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Dscape ieee80211: enabling/disabling the radio

[Jouni Malinen]

On Wed, May 10, 2006 at 03:53:48PM +0200, Ivo van Doorn wrote:

> I think the problem is what the dscape exactly expects the driver to do when
> add_interface() is called by the stack. When that call has finished, does the stack
> expects the radio to be enabled, or should it instruct the driver to enable the radio later
> on through a field in the config structure.

I think the current expectation is for the interface to be set into
enabled state at this point.

> What currently happens in rt2x00 (Which might not be doing what the stack expects)
> is that when add_interface() is called the radio remains off untill open() is called or
> radio_enabled has been set in the config structure.

We used radio_enabled (or well, the previously used name adm_status) as
a "soft disable", i.e., the radio hardware was mostly enabled, but no TX
or RX happened. This could, e.g., mean masking out interrupts and/or
disabling receive part of the radio.

This has been used to provide a mechanism for disabling the radio
without having to set the interface down, i.e., without causing IP
addresses to be dropped or bridging status changed.

-- 
Jouni Malinen                                            PGP id EFC895FA