[2.6.31-rc2] Writing to /sys/class/rfkill/*/state fails

[2.6.31-rc2] Writing to /sys/class/rfkill/*/state fails

[Darren Salt]

[full quoting for linux-{kernel,wireless} & the perpetrator]

I demand that Thiemo Nagel may or may not have written...

> Corentin Chary wrote:
>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<thiemo.nagel@ph.tum.de>
>> wrote:
>>> Corentin Chary wrote:
>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
>>>> Nagel<thiemo.nagel@ph.tum.de> wrote:
>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
>>>>> on my EeePC 1000HGO:
>>>>>   eee:/# cat /sys/class/rfkill/rfkill2/name
>>>>>   eeepc-wwan3g
>>>>>   eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
>>>>>   bash: echo: write error: Operation not permitted
>>>>> What could be the reason for that?
>>>> Reading the kernel source I can find:
>>>>         /*
>>>>          * The intention was that userspace can only take control over
>>>>          * a given device when/if rfkill-input doesn't control it due
>>>>          * to user_claim. Since user_claim is currently unsupported,
>>>>          * we never support changing the state from userspace -- this
>>>>          * can be implemented again later.
>>>>          */
>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
>>>> Documentation/rfkill.txt).
>>>> Maybe network-manager can control that .. But I'm not sure.
>>>> Maybe you should CC the wireless mailing list.
>>> Thanks for the quick reply.  The interesting thing is, that the direct
>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills.  I've CC'd
>>> debian-eeepc-devel, maybe they know something.
>> Are you sure that it works with newer kernels ?
>> This commit should have broken it for all rfkill.
>>   commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
>>   Author: Johannes Berg <johannes@sipsolutions.net>
>>   Date:   Tue Jun 2 13:01:37 2009 +0200

> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.

This is the first that I've heard of this. I'd not noticed since I've not
needed Bluetooth on my 901 recently.

> For the debian-eeepc folks:  2.6.31-rc2 breaks bluetooth toggling using
> eeepc-acpi-scripts, but WLAN toggling still works.

FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
different problem.

I consider this a regression. It breaks an interface which, though flawed, is
ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
scripts.

/dev/rfkill is not useful in shell scripts.

Trying to read from it to determine the current state (and only the current
state) results in the shell effectively hanging, and parsing is less than
trivial. So either we continue to use .../state or eeepc-acpi-scripts needs a
complete rewrite of the ACPI event-handling scripts in something other than
sh (probably perl) and would need a daemon instead of having scripts launched
from acpid (well, that or they'd need a helper binary or two).

Writing to it is doable, though slightly interesting. "echo 1 >/..." is
ideal.

We can't just drop support for older kernels ‒ at least, not yet – though
fortunately, prior to this breakage, all that we had to cope with were
changed file names; the content can be treated identically. We don't have to
deal with hard-blocked states, which helps...

-- 
| Darren Salt            | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds    ,demon,co,uk    | Northumberland | Army
| + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.

Passwords are implemented as a result of insecurity.

Re: [2.6.31-rc2] Writing to /sys/class/rfkill/*/state fails

[Corentin Chary]

On Fri, Jul 10, 2009 at 8:57 PM, Darren
Salt<linux@youmustbejoking.demon.co.uk> wrote:
> [full quoting for linux-{kernel,wireless} & the perpetrator]
>
> I demand that Thiemo Nagel may or may not have written...
>
>> Corentin Chary wrote:
>>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<thiemo.nagel@ph.tum.de>
>>> wrote:
>>>> Corentin Chary wrote:
>>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
>>>>> Nagel<thiemo.nagel@ph.tum.de> wrote:
>>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
>>>>>> on my EeePC 1000HGO:
>>>>>>   eee:/# cat /sys/class/rfkill/rfkill2/name
>>>>>>   eeepc-wwan3g
>>>>>>   eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
>>>>>>   bash: echo: write error: Operation not permitted
>>>>>> What could be the reason for that?
>>>>> Reading the kernel source I can find:
>>>>>         /*
>>>>>          * The intention was that userspace can only take control over
>>>>>          * a given device when/if rfkill-input doesn't control it due
>>>>>          * to user_claim. Since user_claim is currently unsupported,
>>>>>          * we never support changing the state from userspace -- this
>>>>>          * can be implemented again later.
>>>>>          */
>>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
>>>>> Documentation/rfkill.txt).
>>>>> Maybe network-manager can control that .. But I'm not sure.
>>>>> Maybe you should CC the wireless mailing list.
>>>> Thanks for the quick reply.  The interesting thing is, that the direct
>>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills.  I've CC'd
>>>> debian-eeepc-devel, maybe they know something.
>>> Are you sure that it works with newer kernels ?
>>> This commit should have broken it for all rfkill.
>>>   commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
>>>   Author: Johannes Berg <johannes@sipsolutions.net>
>>>   Date:   Tue Jun 2 13:01:37 2009 +0200
>
>> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.
>
> This is the first that I've heard of this. I'd not noticed since I've not
> needed Bluetooth on my 901 recently.
>
>> For the debian-eeepc folks:  2.6.31-rc2 breaks bluetooth toggling using
>> eeepc-acpi-scripts, but WLAN toggling still works.
>
> FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
> different problem.
>
> I consider this a regression. It breaks an interface which, though flawed, is
> ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
> scripts.
>
> /dev/rfkill is not useful in shell scripts.

Maybe it would be possible with an rfkill command line tool (in C) ?
Is there such a tool somewhere ?


-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

Re: [2.6.31-rc2] Writing to /sys/class/rfkill/*/state fails

[Marcel Holtmann]

Hi Corentin,

> > I demand that Thiemo Nagel may or may not have written...
> >
> >> Corentin Chary wrote:
> >>> On Fri, Jul 10, 2009 at 3:35 PM, Thiemo Nagel<thiemo.nagel@ph.tum.de>
> >>> wrote:
> >>>> Corentin Chary wrote:
> >>>>> On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
> >>>>> Nagel<thiemo.nagel@ph.tum.de> wrote:
> >>>>>> I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
> >>>>>> on my EeePC 1000HGO:
> >>>>>>   eee:/# cat /sys/class/rfkill/rfkill2/name
> >>>>>>   eeepc-wwan3g
> >>>>>>   eee:/# echo 0 > /sys/class/rfkill/rfkill2/state
> >>>>>>   bash: echo: write error: Operation not permitted
> >>>>>> What could be the reason for that?
> >>>>> Reading the kernel source I can find:
> >>>>>         /*
> >>>>>          * The intention was that userspace can only take control over
> >>>>>          * a given device when/if rfkill-input doesn't control it due
> >>>>>          * to user_claim. Since user_claim is currently unsupported,
> >>>>>          * we never support changing the state from userspace -- this
> >>>>>          * can be implemented again later.
> >>>>>          */
> >>>>> It seems that rfkill should be controlled by /dev/rfkill (cf
> >>>>> Documentation/rfkill.txt).
> >>>>> Maybe network-manager can control that .. But I'm not sure.
> >>>>> Maybe you should CC the wireless mailing list.
> >>>> Thanks for the quick reply.  The interesting thing is, that the direct
> >>>> access works well for eeepc-wlan and eeepc-bluetooth rfkills.  I've CC'd
> >>>> debian-eeepc-devel, maybe they know something.
> >>> Are you sure that it works with newer kernels ?
> >>> This commit should have broken it for all rfkill.
> >>>   commit 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5
> >>>   Author: Johannes Berg <johannes@sipsolutions.net>
> >>>   Date:   Tue Jun 2 13:01:37 2009 +0200
> >
> >> You're right, all rfkills work with 2.6.30, but none works with 2.6.31-rc2.
> >
> > This is the first that I've heard of this. I'd not noticed since I've not
> > needed Bluetooth on my 901 recently.
> >
> >> For the debian-eeepc folks:  2.6.31-rc2 breaks bluetooth toggling using
> >> eeepc-acpi-scripts, but WLAN toggling still works.
> >
> > FSVO "works" (http://bugzilla.kernel.org/show_bug.cgi?id=13390), but that's a
> > different problem.
> >
> > I consider this a regression. It breaks an interface which, though flawed, is
> > ideally suited for scripting use and which eeepc-acpi-scripts uses in shell
> > scripts.
> >
> > /dev/rfkill is not useful in shell scripts.
> 
> Maybe it would be possible with an rfkill command line tool (in C) ?
> Is there such a tool somewhere ?

yes there is:

http://git.sipsolutions.net/?p=rfkill.git

Regards

Marcel

[PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Johannes Berg]

Apparently there actually _are_ tools that try to set
this in sysfs even though it wasn't supposed to be used
this way without claiming first. Guess what: now that
I've cleaned it all up it doesn't matter and we can
simply allow setting the soft-block state in sysfs.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
*shrug*, I don't like it, but whatever...

Please test & report.

 net/rfkill/core.c |   27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

--- wireless-testing.orig/net/rfkill/core.c	2009-07-10 21:29:10.000000000 +0200
+++ wireless-testing/net/rfkill/core.c	2009-07-10 21:36:31.000000000 +0200
@@ -648,15 +648,26 @@ static ssize_t rfkill_state_store(struct
 				  struct device_attribute *attr,
 				  const char *buf, size_t count)
 {
-	/*
-	 * The intention was that userspace can only take control over
-	 * a given device when/if rfkill-input doesn't control it due
-	 * to user_claim. Since user_claim is currently unsupported,
-	 * we never support changing the state from userspace -- this
-	 * can be implemented again later.
-	 */
+	struct rfkill *rfkill = to_rfkill(dev);
+	unsigned long state;
+	int err;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	err = strict_strtoul(buf, 0, &state);
+	if (err)
+		return err;
+
+	if (state != RFKILL_USER_STATE_SOFT_BLOCKED &&
+	    state != RFKILL_USER_STATE_UNBLOCKED)
+		return -EINVAL;
+
+	mutex_lock(&rfkill_global_mutex);
+	rfkill_set_block(rfkill, state == RFKILL_USER_STATE_SOFT_BLOCKED);
+	mutex_unlock(&rfkill_global_mutex);
 
-	return -EPERM;
+	return err ?: count;
 }
 
 static ssize_t rfkill_claim_show(struct device *dev,

Re: [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Darren Salt]

I demand that Johannes Berg may or may not have written...

> Apparently there actually _are_ tools that try to set this in sysfs even
> though it wasn't supposed to be used this way without claiming first.

Then it should have been documented as such. I don't see anything about this
in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
statement that "Kernel handles events", which isn't exactly helpful :-\

> Guess what: now that I've cleaned it all up it doesn't matter and we can
> simply allow setting the soft-block state in sysfs.

:-)

> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> *shrug*, I don't like it, but whatever...

I do. It means that we have a nice simple text-based interface for use in
scripts (for now), and a binary interface which is better suited to the likes
of desktop applications.

> Please test & report.

With the patch applied, Bluetooth toggling is working again, so you get to
add this:

Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>

[snip]
-- 
| Darren Salt            | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds    ,demon,co,uk    | Northumberland | Army
| + Output *more* particulate pollutants.      BUFFER AGAINST GLOBAL WARMING.

For sale: one complete set of hen's teeth.

Re: [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Johannes Berg]

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

On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> I demand that Johannes Berg may or may not have written...
> 
> > Apparently there actually _are_ tools that try to set this in sysfs even
> > though it wasn't supposed to be used this way without claiming first.
> 
> Then it should have been documented as such. I don't see anything about this
> in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> statement that "Kernel handles events", which isn't exactly helpful :-\

Oh, it's not just that rfkill was horrible, the documentation matched :)
All the SHOUTING in it about what you must and must not do but nothing
actually helpful :)

> > *shrug*, I don't like it, but whatever...
> 
> I do. It means that we have a nice simple text-based interface for use in
> scripts (for now), and a binary interface which is better suited to the likes
> of desktop applications.

Indeed, and as long as you expect to only use soft toggle... problem is
that you won't know whether it's soft-toggled or not while it's
hard-blocked (off)!

> > Please test & report.
> 
> With the patch applied, Bluetooth toggling is working again, so you get to
> add this:
> 
> Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>

Ok, John, please pick up the patch.

johannes

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

Re: [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Darren Salt]

I demand that Johannes Berg may or may not have written...

> On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
>> I demand that Johannes Berg may or may not have written...
[snip]
>>> *shrug*, I don't like it, but whatever...
>> I do. It means that we have a nice simple text-based interface for use in
>> scripts (for now), and a binary interface which is better suited to the
>> likes of desktop applications.

> Indeed, and as long as you expect to only use soft toggle... problem is
> that you won't know whether it's soft-toggled or not while it's
> hard-blocked (off)!

Which is fine for eeepc-acpi-scripts and anything else which doesn't care
about hard-blocking because the hardware doesn't do that.

eeepc-acpi-scripts should eventually use your rfkill utility, though. (I
intend to make sure that it does so.)

[snip]
-- 
| Darren Salt            | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds    ,demon,co,uk    | Northumberland | Army
|   Kill all extremists!

A large dog will have a surprising effect on your life.

Re: [Acpi4asus-user] [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Rafael J. Wysocki]

On Friday 10 July 2009, Johannes Berg wrote:
> On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > I demand that Johannes Berg may or may not have written...
> > 
> > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > though it wasn't supposed to be used this way without claiming first.
> > 
> > Then it should have been documented as such. I don't see anything about this
> > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > statement that "Kernel handles events", which isn't exactly helpful :-\
> 
> Oh, it's not just that rfkill was horrible, the documentation matched :)
> All the SHOUTING in it about what you must and must not do but nothing
> actually helpful :)
> 
> > > *shrug*, I don't like it, but whatever...
> > 
> > I do. It means that we have a nice simple text-based interface for use in
> > scripts (for now), and a binary interface which is better suited to the likes
> > of desktop applications.
> 
> Indeed, and as long as you expect to only use soft toggle... problem is
> that you won't know whether it's soft-toggled or not while it's
> hard-blocked (off)!
> 
> > > Please test & report.
> > 
> > With the patch applied, Bluetooth toggling is working again, so you get to
> > add this:
> > 
> > Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
> 
> Ok, John, please pick up the patch.

Is there anything going on with the patch?

Surely it's not in -rc4.

Rafael

Re: [Acpi4asus-user] [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[John W. Linville]

On Sat, Jul 25, 2009 at 10:56:43PM +0200, Rafael J. Wysocki wrote:
> On Friday 10 July 2009, Johannes Berg wrote:
> > On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > > I demand that Johannes Berg may or may not have written...
> > > 
> > > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > > though it wasn't supposed to be used this way without claiming first.
> > > 
> > > Then it should have been documented as such. I don't see anything about this
> > > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > > statement that "Kernel handles events", which isn't exactly helpful :-\
> > 
> > Oh, it's not just that rfkill was horrible, the documentation matched :)
> > All the SHOUTING in it about what you must and must not do but nothing
> > actually helpful :)
> > 
> > > > *shrug*, I don't like it, but whatever...
> > > 
> > > I do. It means that we have a nice simple text-based interface for use in
> > > scripts (for now), and a binary interface which is better suited to the likes
> > > of desktop applications.
> > 
> > Indeed, and as long as you expect to only use soft toggle... problem is
> > that you won't know whether it's soft-toggled or not while it's
> > hard-blocked (off)!
> > 
> > > > Please test & report.
> > > 
> > > With the patch applied, Bluetooth toggling is working again, so you get to
> > > add this:
> > > 
> > > Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
> > 
> > Ok, John, please pick up the patch.
> 
> Is there anything going on with the patch?
> 
> Surely it's not in -rc4.

commit f54c142725ad2ba33c3ee627873cb6966bf05447
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Fri Jul 10 21:41:39 2009 +0200

    rfkill: allow toggling soft state in sysfs again
    
    Apparently there actually _are_ tools that try to set
    this in sysfs even though it wasn't supposed to be used
    this way without claiming first. Guess what: now that
    I've cleaned it all up it doesn't matter and we can
    simply allow setting the soft-block state in sysfs.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Didn't make -rc4, should be in -rc5.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
			¡Viva Honduras Libre!

Re: [Acpi4asus-user] [PATCH 2.6.31] rfkill: allow toggling soft state in sysfs again

[Rafael J. Wysocki]

On Sunday 26 July 2009, John W. Linville wrote:
> On Sat, Jul 25, 2009 at 10:56:43PM +0200, Rafael J. Wysocki wrote:
> > On Friday 10 July 2009, Johannes Berg wrote:
> > > On Fri, 2009-07-10 at 22:09 +0100, Darren Salt wrote:
> > > > I demand that Johannes Berg may or may not have written...
> > > > 
> > > > > Apparently there actually _are_ tools that try to set this in sysfs even
> > > > > though it wasn't supposed to be used this way without claiming first.
> > > > 
> > > > Then it should have been documented as such. I don't see anything about this
> > > > in Documentation/rfkill.txt (as found in 2.6.30), other than a vague
> > > > statement that "Kernel handles events", which isn't exactly helpful :-\
> > > 
> > > Oh, it's not just that rfkill was horrible, the documentation matched :)
> > > All the SHOUTING in it about what you must and must not do but nothing
> > > actually helpful :)
> > > 
> > > > > *shrug*, I don't like it, but whatever...
> > > > 
> > > > I do. It means that we have a nice simple text-based interface for use in
> > > > scripts (for now), and a binary interface which is better suited to the likes
> > > > of desktop applications.
> > > 
> > > Indeed, and as long as you expect to only use soft toggle... problem is
> > > that you won't know whether it's soft-toggled or not while it's
> > > hard-blocked (off)!
> > > 
> > > > > Please test & report.
> > > > 
> > > > With the patch applied, Bluetooth toggling is working again, so you get to
> > > > add this:
> > > > 
> > > > Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
> > > 
> > > Ok, John, please pick up the patch.
> > 
> > Is there anything going on with the patch?
> > 
> > Surely it's not in -rc4.
> 
> commit f54c142725ad2ba33c3ee627873cb6966bf05447
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date:   Fri Jul 10 21:41:39 2009 +0200
> 
>     rfkill: allow toggling soft state in sysfs again
>     
>     Apparently there actually _are_ tools that try to set
>     this in sysfs even though it wasn't supposed to be used
>     this way without claiming first. Guess what: now that
>     I've cleaned it all up it doesn't matter and we can
>     simply allow setting the soft-block state in sysfs.
>     
>     Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>     Tested-By: Darren Salt <linux@youmustbejoking.demon.co.uk>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> Didn't make -rc4, should be in -rc5.

Great, thanks!

Best,
Rafael