wireless.sh should use device/rf_kill instead of power/state

well... there's a more simple way to find it, and wireless.sh can easily be changed to chech the presence of rf_kill and if it doesn't find it goes back to the older power/state!
see my attachment

this is my new /etc/acpi/wireless.sh which is now aware of ipw2200 which must be shut down using rf_kill instead of power/state

I'm writing again because the correct script can be found here

https://launchpad.net/malone/43061

I think this should apply to any wireless adapter that supports rf_kill.

Yes. Is there a plan to fix this in edgy?

Anyway I think that ubuntu lacks of a wireless framework... there are only some small and not linked utilities that are not available through a gui...

So this bug might be closed since the way to deactivate wlan is changed in linux-2.6.20 and the old method is not supported as told by Ben in another bug report.

While Feisty might support another method, Edgy continues to be supported for 18 months and Dapper (LTS!) for 60 months. If this bug affects those platforms, we shouldn't rely on kernel features unavailable to those platforms when considering whether to close the bug.

The questions are

  "Will the Dapper ACPI scripts be updated to use rf_kill?"

and

  "Will the Edgy ACPI scripts be updated to use rf_kill?"

If the answers are No and No, then the ACPI support team should Reject this, perhaps with an explanation. If either answer is Yes, then this should remain open until Fix Released.

First of all we need to know if every wireless card is supporting the
rf_kill method to switch the radio off... I only have tried ipw2100
and ipw2200. Do you know it?

No. Only ipw2100, ipw2200 and ipw3945 support it.

--
Matthew Garrett | <email address hidden>

On Sat, 2007-01-06 at 18:56 +0000, Matthew Garrett wrote:
> No. Only ipw2100, ipw2200 and ipw3945 support it.

The rt2x00 CVS (not legacy) drivers do as well. rf_kill is one of the
topics coming up at the Wireless Summit week after next, but it wont
affect anything until after feisty.

ok... I hope that in that summit it will be considered that in feisty
the power/state method cannot be used any more...

I'm glad this bug has been noticed!
If you want I can propose a solution that includes leds, notifies and
network-manager support! should I attach it here?

Nicolò: I think that bug #43061 ("code duplication in wireless scripts") might be a better place to keep the long-term solution. This bug will get closed when the upload has gone through; I've done the upload but it's caught in feisty beta freeze.

What upload have you done? is it possible that you post it here? I
will add my proposals to bug #43061 and let's continue to discuss
there of the future of acpi scripts for wireless...

Hello Nicolò, I'm currently up to:

   http://www.paul.sladen.org/ubuntu/upload/acpi-support_0.94.debdiff

but we're still in BetaFreeze for the next couple of days, so this hasn't gone through.

Does this mean that we won't have a working hotkey in Feisty? or just
that we need to wait?

I've had a look at the patch. Great! But I've noticed that the
wireless status is not saved for halt/reboot too (only for suspend or
hibernate/resume). Are you going to add the file also in start.d and
stop.d?

And don't forget to correct another wireless.sh bug (that closes my
report #38354 but don't look at the bug description because it is very
messy):
wireless.sh prints something every time it finds a wireless interface
(you do a echo in the for). in my opinion you shuold do the for
without any echo, and then call
if isAnyWirelessPoweredOn; then
   echo 1
else
   echo 0
fi
using this you actually print the correct status (it is possible that
something fails in changing the status (well, it is sure if the card
does not support rf_kill, because the power/state method is broken),
and currently you don't perform any check!)

another proposal is to use networkmanager to completely disable
wireless so that the applet does not try to automatically connect
after we disabled wireless:

dbus-send --system --type=method_call
--dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager
org.freedesktop.NetworkManager.setWirelessEnabled boolean:false

boolean:true to enable it. This can be put in wireless.sh and in
resume.d if nm forgets its options after the suspend (and in start.d
it you accept to add it)

Thank you!

PS: since you're active now, please have a look at this (very simple)
acpi-support bug:
https://launchpad.net/bugs/76593

I don't really understand the logic of wireless.sh, especially the
part in which you overwrite the variable OFF with "2". The following
wireless interface will fail if using rf_kill because off is not 2 but
1...

Why didn't you remove the reference to power/state? Since it does not
work it is not needed... It is only useful in isAnyWirelessPoweredOn,
because you have to check if that device is off

acpi-support (0.93) feisty; urgency=low

  * Change 'wireless.sh' to use 'device/rf_kill' for wireless devices (if
    available) in preference to 'device/power/state' which was been
    removed by the upstream kernel developers.
    (Closes: LP #42820)
  * Teach 'lib/state-funcs:isAnyWirelessPoweredOn()' to also check
    'device/rf_kill' if it's available.
    (Closes: LP #42820)
  * Change 'ibm-wireless.sh' to rotate wireless and bluetooth states
    through the sequence: both, bluetooth only, wireless only, neither.
    (Closes: LP #24680)
  * Correct inverted logic in 'isAnyWirelessPoweredOn()'.
    (Closes: LP #66083)
  * Change script shebangs to use '/bin/sh' instead of '/bin/bash'.

 -- Paul Sladen <email address hidden> Wed, 21 Mar 2007 04:55:27 +0000

Hi,
Since Feisty I cannot turn off my wireless, using the /power/state or the rf_kill method. Indeed, both files are reported to be unwritable.

I am using an Asus centrino laptop with ipw2200. I think this wireless device is supposed to support the rf_kill method.

Do you have any hints why this does not work ?

Thanks

It is strange that the rf_kill method is not supported... I have
ipw2200 too (and an asus centrino) and they are supported. Are you
sure?

Yes pretty sure. I get :

$ sudo echo -n 2 >/sys/class/net/eth1/device/rf_kill
bash: /sys/class/net/eth1/device/rf_kill: Permission denied
$ sudo echo -n 1 >/sys/class/net/eth1/device/power/state
bash: /sys/class/net/eth1/device/power/state: Permission denied

If any debug output may help, I will be glad to attach it.

you should do
echo 1 | sudo tee /sys/class/net/eth1/device/rf_kill
echo 0 | sudo tee /sys/class/net/eth1/device/rf_kill

the first one disables the radio.

Oops.

It works. Sorry for bothering you with that kind of things.

Thanks a lot.