Discussion:
wwan3g rfkill: Operation not permitted
(too old to reply)
Thiemo Nagel
2009-07-10 13:35:39 UTC
Permalink
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following on my
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?
/*
* 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.

Kind regards,

Thiemo
--
+-----------------------------------+--------------------------+
| Dipl.-Phys. Thiemo Nagel | |
| Technische Universitaet Muenchen | Room PH1 3276 |
| Physik-Department E18 | |
| James-Franck-Strasse | Phone +49 89 289-12379 |
| D-85747 Garching | Fax +49 89 289-12570 |
+-----------------------------------+--------------------------+
Corentin Chary
2009-07-10 13:46:33 UTC
Permalink
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following on my
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?
        /*
         * 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 <***@sipsolutions.net>
Date: Tue Jun 2 13:01:37 2009 +0200
--
Corentin Chary
http://xf.iksaif.net - http://uffs.org
Thiemo Nagel
2009-07-10 14:32:57 UTC
Permalink
Post by Corentin Chary
Post by Thiemo Nagel
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following on my
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?
/*
* 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
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.

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

Thank you and kind regards,

Thiemo
--
+-----------------------------------+--------------------------+
| Dipl.-Phys. Thiemo Nagel | |
| Technische Universitaet Muenchen | Room PH1 3276 |
| Physik-Department E18 | |
| James-Franck-Strasse | Phone +49 89 289-12379 |
| D-85747 Garching | Fax +49 89 289-12570 |
+-----------------------------------+--------------------------+
Darren Salt
2009-07-10 18:57:50 UTC
Permalink
[full quoting for linux-{kernel,wireless} & the perpetrator]

I demand that Thiemo Nagel may or may not have written...
Post by Thiemo Nagel
Post by Corentin Chary
Post by Thiemo Nagel
On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
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?
/*
* 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
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.
Post by Thiemo Nagel
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.
Corentin Chary
2009-07-10 19:34:32 UTC
Permalink
On Fri, Jul 10, 2009 at 8:57 PM, Darren
Post by Darren Salt
[full quoting for linux-{kernel,wireless} & the perpetrator]
I demand that Thiemo Nagel may or may not have written...
Post by Thiemo Nagel
Post by Corentin Chary
On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
  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?
        /*
         * 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
  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.
Post by Thiemo Nagel
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
Marcel Holtmann
2009-07-10 19:37:42 UTC
Permalink
Hi Corentin,
Post by Corentin Chary
Post by Darren Salt
I demand that Thiemo Nagel may or may not have written...
Post by Thiemo Nagel
Post by Corentin Chary
Post by Thiemo Nagel
On Fri, Jul 10, 2009 at 12:23 PM, Thiemo
I just tested the new GSM rfkill in 2.6.31-rc2 and I get the following
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?
/*
* 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
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.
Post by Thiemo Nagel
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
Darren Salt
2009-07-10 21:36:12 UTC
Permalink
I demand that Marcel Holtmann may or may not have written...
Post by Marcel Holtmann
Hi Corentin,
[snip; scripting rfkill]
Post by Marcel Holtmann
Maybe it would be possible with an rfkill command line tool (in C) ? Is
there such a tool somewhere ?
http://git.sipsolutions.net/?p=rfkill.git
Interesting. Something to package and have eeepc-acpi-scripts (eventually)
make use of...
--
| Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army
| + RIPA NOTICE: NO CONSENT GIVEN FOR INTERCEPTION OF MESSAGE TRANSMISSION

$ ping elvis
Johannes Berg
2009-07-10 19:41:39 UTC
Permalink
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 <***@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,
Darren Salt
2009-07-10 21:09:33 UTC
Permalink
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.
:-)
---
*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 <***@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.
Johannes Berg
2009-07-10 21:55:52 UTC
Permalink
Post by 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 :-\
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 :)
Post by Darren Salt
*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)!
Post by Darren Salt
Please test & report.
With the patch applied, Bluetooth toggling is working again, so you get to
Ok, John, please pick up the patch.

johannes
Darren Salt
2009-07-10 23:09:26 UTC
Permalink
I demand that Johannes Berg may or may not have written...
Post by Johannes Berg
Post by Darren Salt
I demand that Johannes Berg may or may not have written...
[snip]
Post by Johannes Berg
Post by Darren Salt
Post by Johannes Berg
*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.
Rafael J. Wysocki
2009-07-25 20:56:43 UTC
Permalink
Post by Johannes Berg
Post by 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 :-\
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 :)
Post by Darren Salt
*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)!
Post by Darren Salt
Please test & report.
With the patch applied, Bluetooth toggling is working again, so you get to
Ok, John, please pick up the patch.
Is there anything going on with the patch?

Surely it's not in -rc4.

Rafael
John W. Linville
2009-07-25 22:35:06 UTC
Permalink
Post by Rafael J. Wysocki
Post by Johannes Berg
Post by 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 :-\
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 :)
Post by Darren Salt
*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)!
Post by Darren Salt
Please test & report.
With the patch applied, Bluetooth toggling is working again, so you get to
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 <***@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 <***@sipsolutions.net>
Tested-By: Darren Salt <***@youmustbejoking.demon.co.uk>
Signed-off-by: John W. Linville <***@tuxdriver.com>

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

John
--
John W. Linville Someday the world will need a hero, and you
***@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
Rafael J. Wysocki
2009-07-26 19:32:38 UTC
Permalink
Post by John W. Linville
Post by Rafael J. Wysocki
Post by Johannes Berg
Post by 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 :-\
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 :)
Post by Darren Salt
*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)!
Post by Darren Salt
Please test & report.
With the patch applied, Bluetooth toggling is working again, so you get to
Ok, John, please pick up the patch.
Is there anything going on with the patch?
Surely it's not in -rc4.
commit f54c142725ad2ba33c3ee627873cb6966bf05447
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.
Didn't make -rc4, should be in -rc5.
Great, thanks!

Best,
Rafael

Loading...