Bug#618277: PHASE mismatch in ifupdown script

2011-03-17 Thread Kel Modderman 
On Wednesday 16 March 2011 22:19:02 Tormod Volden wrote:
 I agree that nowadays this is usually run through dbus and
 network-manager and not the ifupdown and /etc/interfaces way, but the
 result is the same. Please look at
 /etc/NetworkManager/dispatcher.d/01ifupdown - it sets $PHASE and does
 run-parts on the corresponding /etc/network/if-XXX.d directory.
 
 So in your example above, when run-parts: executing
 /etc/network/if-down.d/wpasupplicant is executed, $PHASE is set to
 down. And the pre-down clause can not be executed since there is
 no if-pre-down.d file.

Incorrect. Add a debug print to the case statement (eg echo $0 $MODE $PHASE)

run-parts: executing /etc/network/if-down.d/wpasupplicant   

  
/etc/network/if-down.d/wpasupplicant stop pre-down

 
 You do agree that any post-up and pre-down clauses in ifupdown.sh will
 not be run, right? 

No, I do not agree.

Kel.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-16 Thread Kel Modderman 
On Tuesday 15 March 2011 22:24:07 Tormod Volden wrote:
 On Tue, Mar 15, 2011 at 12:46 PM, Kel Modderman wrote:
  Can you explain what is actually wrong with the shell code I've been using 
  for
  a few years, which stops it from functioning as advertised?
 
  I'm not going to be interested enough to consume time investigating a 
  problem
  based on a guess.
 
  Thanks, Kel.
 
 
 Hi Kel,
 
 Yes, by analyzing the code I can say what goes wrong: Upon network
 interface activation, the action intended for the post-up phase is
 not executed (because the script is not in any if-post-up.d directory
 - it is linked in the if-up.d directory but $PHASE will here be up).
 The action in question is init_wpa_cli() from functions.sh. This
 function only does something if $WPA_ACTION_SCRIPT is set. Therefore
 if you personally have been using this code for some years without
 WPA_ACTION_SCRIPT set, you would not have experienced any problem.
 What the advertised use for this is, I do not know. But it is
 certainly not working as intended. So I will /guess/ ;) there are
 users out there who have problems with their WPA_ACTION_SCRIPT setup.

/etc/network/interfaces
---
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa-roam.conf

iface default inet dhcp
---

# ifup -v wlan0
Configuring interface wlan0=wlan0 (inet)
run-parts --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
wpa_supplicant: wait for wpa_cli to attach
wpa_supplicant: wpa-driver nl80211,wext (default)
wpa_supplicant: /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid 
-i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa-roam.conf
Starting /sbin/wpa_supplicant...
wpa_supplicant: creating sendsigs omission pidfile: 
/lib/init/rw/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid
run-parts --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/mountnfs
run-parts: executing /etc/network/if-up.d/ntpdate
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/wpasupplicant
wpa_supplicant: /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p 
/var/run/wpa_supplicant -a /sbin/wpa_action
Starting /sbin/wpa_cli...

# ifdown wlan0 -v
Configuring interface wlan0=wlan0 (inet)
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/resolvconf
run-parts: executing /etc/network/if-down.d/wpasupplicant
wpa_supplicant: terminating wpa_cli daemon via pidfile 
/var/run/wpa_action.wlan0.pid
Stopped /sbin/wpa_cli (pid 3707).
run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/bridge
run-parts: executing /etc/network/if-post-down.d/hostapd
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
wpa_supplicant: terminating wpa_supplicant daemon via pidfile 
/var/run/wpa_supplicant.wlan0.pid
Stopped /sbin/wpa_supplicant (pid 3660).
wpa_supplicant: removing 
/lib/init/rw/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid

 
 Upon network deactivation, for the same reasons, kill_wpa_supplicant()
 is not run. This I can verify myself even without using WPA: 1. See
 that there is a running /sbin/wpa_supplicant process. 2. Deactivate
 networking for instance with nm-applet. 3. See that
 /sbin/wpa_supplicant, against intended behaviour, is still running and
 has therefore not been killed by kill_wpa_supplicant() . In case you
 added that logger line, you can see how the ifupdown script is called.
 This is not a guess :)

This process is started/stopped via D-Bus and has *nothing* to do with
the ifupdown shell script glue you are doing your guesswork on.

Kel.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-16 Thread Tormod Volden 
I agree that nowadays this is usually run through dbus and
network-manager and not the ifupdown and /etc/interfaces way, but the
result is the same. Please look at
/etc/NetworkManager/dispatcher.d/01ifupdown - it sets $PHASE and does
run-parts on the corresponding /etc/network/if-XXX.d directory.

So in your example above, when run-parts: executing
/etc/network/if-down.d/wpasupplicant is executed, $PHASE is set to
down. And the pre-down clause can not be executed since there is
no if-pre-down.d file.

You do agree that any post-up and pre-down clauses in ifupdown.sh will
not be run, right? In some cases they will not be reached anyway
because do_start() and do_stop() /exit/ the whole script, but in some
cases do_start() and do_stop() simply /return/ and the script
continues into these case $PHASE clauses. Maybe this is not the
majority of user cases (and not yours) but in these cases I think
things are not working as intended. Or would you think these clauses
are never reached by anyone and should rather be removed?

 This process is started/stopped via D-Bus and has *nothing* to do with
 the ifupdown shell script glue you are doing your guesswork on.

If by this process you refer to wpa_supplicant, I corrected that in
the following message which you might have missed.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-15 Thread Kel Modderman 
Hi Tormod,

On Monday 14 March 2011 08:06:31 Tormod Volden wrote:
 Package: wpasupplicant
 Version: 0.7.3-1
 
 Note that I don't use wpasupplicant so I can not test this, but I
 noticed it while studying various ifupdown script.

Can you explain what is actually wrong with the shell code I've been using for
a few years, which stops it from functioning as advertised?

I'm not going to be interested enough to consume time investigating a problem
based on a guess.

Thanks, Kel.


 
 The /etc/wpa_supplicant/ifupdown.sh is linked in /etc/network/if-up.d
 so it will be run with PHASE=up and not post-up. However the script
 checks for post-up. Same goes for pre-down.
 
 --- /etc/wpa_supplicant/ifupdown.sh   2009-06-01 12:32:26.0 +0200
 +++ /tmp/ifupdown.sh  2011-03-13 23:01:35.0 +0100
 @@ -141,7 +141,7 @@ case $MODE in
   init_wpa_supplicant || exit 1
   conf_wpa_supplicant || { 
 kill_wpa_supplicant; exit 1; }
   ;;
 - post-up)
 + up)
   init_wpa_cli|| { 
 kill_wpa_supplicant; exit 1; }
   ;;
   esac
 @@ -150,7 +150,7 @@ case $MODE in
   stop)
   do_stop
   case $PHASE in
 - pre-down)
 + down)
   kill_wpa_cli
   ;;
   post-down)
 
 
 
 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-15 Thread Tormod Volden 
On Tue, Mar 15, 2011 at 12:46 PM, Kel Modderman wrote:
 Can you explain what is actually wrong with the shell code I've been using for
 a few years, which stops it from functioning as advertised?

 I'm not going to be interested enough to consume time investigating a problem
 based on a guess.

 Thanks, Kel.


Hi Kel,

Yes, by analyzing the code I can say what goes wrong: Upon network
interface activation, the action intended for the post-up phase is
not executed (because the script is not in any if-post-up.d directory
- it is linked in the if-up.d directory but $PHASE will here be up).
The action in question is init_wpa_cli() from functions.sh. This
function only does something if $WPA_ACTION_SCRIPT is set. Therefore
if you personally have been using this code for some years without
WPA_ACTION_SCRIPT set, you would not have experienced any problem.
What the advertised use for this is, I do not know. But it is
certainly not working as intended. So I will /guess/ ;) there are
users out there who have problems with their WPA_ACTION_SCRIPT setup.

Upon network deactivation, for the same reasons, kill_wpa_supplicant()
is not run. This I can verify myself even without using WPA: 1. See
that there is a running /sbin/wpa_supplicant process. 2. Deactivate
networking for instance with nm-applet. 3. See that
/sbin/wpa_supplicant, against intended behaviour, is still running and
has therefore not been killed by kill_wpa_supplicant() . In case you
added that logger line, you can see how the ifupdown script is called.
This is not a guess :)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-15 Thread Tormod Volden 
Sorry, I messed up the deactivation part in my explanation: It is the
pre-down clause that never is executed (as hinted by my patch), that
is kill_wpa_cli(). That wpa_supplicant was still running, is a
different bug/feature (fwiw there is no pid-file).

kill_wpa_cli() also depends on a pid-file, which I do not have on my
system. So it won't do anything here, but again, I am not even using
WPA.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-14 Thread Tormod Volden 
The easiest way to verify this is to add for instance:
 logger $0: $IFACE $ADDRFAM $MODE $PHASE
to /etc/wpa_supplicant/ifupdown.sh and check the output in /var/log/syslog.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#618277: PHASE mismatch in ifupdown script

2011-03-13 Thread Tormod Volden 
Package: wpasupplicant
Version: 0.7.3-1

Note that I don't use wpasupplicant so I can not test this, but I
noticed it while studying various ifupdown script.

The /etc/wpa_supplicant/ifupdown.sh is linked in /etc/network/if-up.d
so it will be run with PHASE=up and not post-up. However the script
checks for post-up. Same goes for pre-down.

--- /etc/wpa_supplicant/ifupdown.sh 2009-06-01 12:32:26.0 +0200
+++ /tmp/ifupdown.sh2011-03-13 23:01:35.0 +0100
@@ -141,7 +141,7 @@ case $MODE in
init_wpa_supplicant || exit 1
conf_wpa_supplicant || { 
kill_wpa_supplicant; exit 1; }
;;
-   post-up)
+   up)
init_wpa_cli|| { 
kill_wpa_supplicant; exit 1; }
;;
esac
@@ -150,7 +150,7 @@ case $MODE in
stop)
do_stop
case $PHASE in
-   pre-down)
+   down)
kill_wpa_cli
;;
post-down)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org