This is an usability improvement that makes wifi-menu to temporarily enable the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being smart", because it honors existing per-interface rfkill settings, so it is just in line with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
--- src/lib/rfkill | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/src/lib/rfkill b/src/lib/rfkill index e388f08..b7adfc2 100644 --- a/src/lib/rfkill +++ b/src/lib/rfkill @@ -26,6 +26,19 @@ get_rf_path() { return 1 }
+## Determine whether the transmission is allowed (unblocked) at the moment +# $1: interface name +# $2: rfkill name +rf_is_enabled() { + local interface=$1 rfkill=$2 path hard soft + + path=$(get_rf_path "$interface" "$rfkill") || return 1 + read hard < "$path/hard" + read soft < "$path/soft" + + (( ! hard && ! soft )) +} + ## Unblock transmission through a wireless device # $1: interface name # $2: rfkill name
Temporarily enable the interface's rfkill (if specified) before issuing a scan and restore its state afterwards.
--- src/wifi-menu | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/wifi-menu b/src/wifi-menu index a62881e..9f0fbea 100755 --- a/src/wifi-menu +++ b/src/wifi-menu @@ -2,6 +2,7 @@
. /usr/lib/network/globals . "$SUBR_DIR/wpa" +. "$SUBR_DIR/rfkill"
usage() @@ -208,10 +209,25 @@ if [[ ! -d "/sys/class/net/$INTERFACE" ]]; then exit_error "No such interface: $INTERFACE" fi
+if [[ -x "$PROFILE_DIR/interfaces/$INTERFACE" ]]; then + source "$PROFILE_DIR/interfaces/$INTERFACE" +fi + +if [[ $RFKill ]] && ! rf_is_enabled "$INTERFACE" "$RFKill"; then + enable_rf "$INTERFACE" "$RFKill" || exit_error "Cannot enable rfkill" + RFKILL_WAS_ENABLED=1 +fi + echo -n "Scanning for networks... " CONNECTION=$(wpa_call "$INTERFACE" status 2> /dev/null | sed -n "s/^ssid=//p") NETWORKS=$(wpa_supplicant_scan "$INTERFACE" 3,4,5) -if [[ $? -eq 0 ]]; then +SCAN_RESULT=$? + +if (( RFKILL_WAS_ENABLED )); then + disable_rf "$INTERFACE" "$RFKill" +fi + +if [[ $SCAN_RESULT -eq 0 ]]; then trap 'rm -f "$NETWORKS"' EXIT echo "done" init_profiles "$INTERFACE" @@ -256,6 +272,7 @@ case $RETURN in RETURN=7 ;; esac + exit $RETURN
On Saturday 21 September 2013 at 19:37:21, you wrote:
This is an usability improvement that makes wifi-menu to temporarily enable the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being smart", because it honors existing per-interface rfkill settings, so it is just in line with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
Any news on this?
Regards,
As you can see, your first patch inspired a rewrite. I prefer my version, as it has a little less duplicate code.
The discussion is thus on whether we want wifi-menu to unblock the wireless signal. I still think this kind of defeats the idea of rfkill. Its not hard to unblock outside of wifi-menu, agreed?
Regards, - Jouke
On Thu, Oct 24, 2013 at 7:20 AM, Ivan Shapovalov intelfx100@gmail.com wrote:
On Saturday 21 September 2013 at 19:37:21, you wrote:
This is an usability improvement that makes wifi-menu to temporarily enable the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being smart", because it honors existing per-interface rfkill settings, so it is just in line with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
Any news on this?
Regards,
-- Ivan Shapovalov / intelfx /
On Thursday, October 24, 2013, Jouke Witteveen j.witteveen@gmail.com wrote:
As you can see, your first patch inspired a rewrite. I prefer my version, as it has a little less duplicate code.
The discussion is thus on whether we want wifi-menu to unblock the wireless signal. I still think this kind of defeats the idea of rfkill. Its not hard to unblock outside of wifi-menu, agreed?
At least make it an explicit choice: 'cannot scan, should I enable the WiFi?'.
Cheers,
Tom
Regards,
- Jouke
On Thu, Oct 24, 2013 at 7:20 AM, Ivan Shapovalov intelfx100@gmail.com
wrote:
On Saturday 21 September 2013 at 19:37:21, you wrote:
This is an usability improvement that makes wifi-menu to temporarily
enable
the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being
smart",
because it honors existing per-interface rfkill settings, so it is just
in line
with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
Any news on this?
Regards,
-- Ivan Shapovalov / intelfx /
Ok, I will make it a dialog.
However, I seem to miss the idea: netctl already automatically turns the radio on when asked to connect. What's wrong with doing the same when asked to scan networks?
We're assuming that RFKill= is specified, which can be IMO understood as "user has granted netctl permissions to manage their rfkill switches".
Regards,
On second thought, I think setting RFKill in an interface hook can indeed be considered an explicit choice. Unless someone (Tom?) feels otherwise very strongly, I want to apply Ivan's second patch (I made the necessary changes so that it applies to the current code base).
Regards, - Jouke
On Sun, Oct 27, 2013 at 10:57 PM, Ivan Shapovalov intelfx100@gmail.com wrote:
Ok, I will make it a dialog.
However, I seem to miss the idea: netctl already automatically turns the radio on when asked to connect. What's wrong with doing the same when asked to scan networks?
We're assuming that RFKill= is specified, which can be IMO understood as "user has granted netctl permissions to manage their rfkill switches".
Regards,
-- Ivan Shapovalov / intelfx /
On Thursday 24 October 2013 at 10:28:20, Tom wrote:
On Thursday, October 24, 2013, Jouke Witteveen j.witteveen@gmail.com wrote:
As you can see, your first patch inspired a rewrite. I prefer my version, as it has a little less duplicate code.
The discussion is thus on whether we want wifi-menu to unblock the wireless signal. I still think this kind of defeats the idea of rfkill. Its not hard to unblock outside of wifi-menu, agreed?
At least make it an explicit choice: 'cannot scan, should I enable the WiFi?'.
Cheers,
Tom
Regards,
- Jouke
On Thu, Oct 24, 2013 at 7:20 AM, Ivan Shapovalov intelfx100@gmail.com
wrote:
On Saturday 21 September 2013 at 19:37:21, you wrote:
This is an usability improvement that makes wifi-menu to temporarily
enable
the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being
smart",
because it honors existing per-interface rfkill settings, so it is just
in line
with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
Any news on this?
Regards,
-- Ivan Shapovalov / intelfx /
On Thu, Feb 27, 2014 at 2:15 PM, Jouke Witteveen j.witteveen@gmail.com wrote:
On second thought, I think setting RFKill in an interface hook can indeed be considered an explicit choice. Unless someone (Tom?) feels otherwise very strongly, I want to apply
Nope, I don't feel strongly about this.
Ivan's second patch (I made the necessary changes so that it applies to the current code base).
Regards,
- Jouke
On Sun, Oct 27, 2013 at 10:57 PM, Ivan Shapovalov intelfx100@gmail.com wrote:
Ok, I will make it a dialog.
However, I seem to miss the idea: netctl already automatically turns the radio on when asked to connect. What's wrong with doing the same when asked to scan networks?
We're assuming that RFKill= is specified, which can be IMO understood as "user has granted netctl permissions to manage their rfkill switches".
Regards,
-- Ivan Shapovalov / intelfx /
On Thursday 24 October 2013 at 10:28:20, Tom wrote:
On Thursday, October 24, 2013, Jouke Witteveen j.witteveen@gmail.com wrote:
As you can see, your first patch inspired a rewrite. I prefer my version, as it has a little less duplicate code.
The discussion is thus on whether we want wifi-menu to unblock the wireless signal. I still think this kind of defeats the idea of rfkill. Its not hard to unblock outside of wifi-menu, agreed?
At least make it an explicit choice: 'cannot scan, should I enable the WiFi?'.
Cheers,
Tom
Regards,
- Jouke
On Thu, Oct 24, 2013 at 7:20 AM, Ivan Shapovalov intelfx100@gmail.com
wrote:
On Saturday 21 September 2013 at 19:37:21, you wrote:
This is an usability improvement that makes wifi-menu to temporarily
enable
the interface's rfkill switch before doing a network scan.
I don't think that this is too much of automatism and "software being
smart",
because it honors existing per-interface rfkill settings, so it is just
in line
with the rest of netctl's wireless support.
Ivan Shapovalov (2): rfkill: add rf_is_enabled (query current rfkill state) wifi-menu: handle interface's rfkill switch
src/lib/rfkill | 13 +++++++++++++ src/wifi-menu | 19 ++++++++++++++++++- 2 files changed, 31 insertions(+), 1 deletion(-)
Any news on this?
Regards,
-- Ivan Shapovalov / intelfx /
arch-projects@lists.archlinux.org