Bug#618277: PHASE mismatch in ifupdown script
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
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
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
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
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
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
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
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
