On Wed, 8 Aug 2007, Arnaud Degroote wrote:
>> At a quick glance, this appears to keep the interface in the running
>> state when the transmitter is off. RUNNING vs not is the only way I can
>> think of for userland to detect whether the transmitter is on or not,
>> i.e. this patch will improve the reporting as far as I can see in dmesg
>> (yes, I _could_ parse that for transmitter state), but will make it
>> _more_ difficult to prompt the user to switch it on. Perhaps an ioctl or
>> sysctl to retrieve the transmitter state?
>
> I can remove the IFF_RUNNING and IFF_OACTIVE in the on->off transition, it
> is not a problem. I'm not really sure it will be help userland (and user)
> that he must switch the transmitter on.

Greg's input on the intended meaning of IFF_RUNNING is useful - the fact 
that at the moment it can be used to approximate to transmitter on/off is 
a side-effect and should not be relied on.

> Currently, on an off->on transition, on my configuration, dhclient is
> automaticly restarted and I can use my network.
>
> I can add a sysctl to retrieve the transmitter state but I'm not sure it
> really solves the issue. I think that with the message and the man page, it
> is quite clear that he must turn the switch on.

You forget that some people want to build embedded or end-user products 
based on NetBSD :-)

For my needs:
At early boot time, we determine active interfaces as quickly as possible. 
At this point we need to prompt the user to switch on radio if they 
intend to use wifi. Associating with an AP takes some time, there's no 
point in going through this if they don't want to use it (or cannot 
because the transmitter is off). We need to associate with an AP before 
running dhclient for reliability.
dhclient is run on interfaces and settings from network required for rest 
of boot are retrieved.

I think a sysctl would be neatest solution then we can explicitly retrieve 
transmitter status rather than relying in lucky side-effects.

> You can find an updated patch on
> http://zulzul.free.fr/wpi/test/wpi_rfkill.diff.

I'll try it when I am back in the office tomorrow.

-- 
Stephen