Incorrect /etc/NetworkManager/dispatcher.d/01ifupdown

Bug #661951 reported by Sergiy Matrunchyk on 2010-10-16
44
This bug affects 9 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Low
Mathieu Trudel-Lapierre

Bug Description

Binary package hint: network-manager

Ubuntu 10.10
Package: network-manager
Priority: optional
Section: net
Installed-Size: 1352
Maintainer: Ubuntu Core Dev Team <email address hidden>
Architecture: i386
Version: 0.8.1+git.20100810t184654.ab580f4-0ubuntu2

Preabule.
When I connect to my VPN-connection configured in network-manager GUI I see in error log:
-----
Oct 17 02:04:20 adm04 nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.
-----
Anyway connection is going complete, but startup scripts don't start.

I've tried to understand what's going on and therefore I've changed original 01ifupdown file to suggest an issue.
The problem is because script don't support vpn connections. Lets look into the original script:

--------------------------------------

#!/bin/sh -e
# Script to dispatch NetworkManager events
#
# Runs ifupdown scripts when NetworkManager fiddles with interfaces.

if [ -z "$1" ]; then
    echo "$0: called with no interface" &>2
    exit 1;
fi

# Fake ifupdown environment
export IFACE="$1"
export LOGICAL="$1"
export ADDRFAM="NetworkManager"
export METHOD="NetworkManager"
export VERBOSITY="0"

# Run the right scripts
case "$2" in
    up )
 export MODE="start"
 export PHASE="up"

 if [ -d /var/run/network/ ] ; then
  tmpfile=`mktemp -t`
  if [ -e /var/run/network/ifstate ] ; then
   cat /var/run/network/ifstate | grep -v ^$IFACE= > $tmpfile || true
  fi
  echo $IFACE=$IFACE >> $tmpfile
  mv $tmpfile /var/run/network/ifstate
 fi

 exec run-parts /etc/network/if-up.d
 ;;
    down )
 export MODE="stop"
 export PHASE="down"
 if [ -e /var/run/network/ifstate ] ; then
  tmpfile=`mktemp -t`
  cat /var/run/network/ifstate | grep -v ^$IFACE= > $tmpfile || true
  mv $tmpfile /var/run/network/ifstate
 fi

 exec run-parts /etc/network/if-down.d
 ;;
    pre-up)
 export MODE="start"
 export PHASE="pre-up"
 exec run-parts /etc/network/if-pre-up.d
 ;;
    post-down)
 export MODE="stop"
 export PHASE="post-down"
 exec run-parts /etc/network/if-post-down.d
 ;;
    *)
 echo "$0: called with unknown action \`$2'" 1>&2
 exit 1
 ;;
esac

--------------------------------
It seems like ok, but there is no handler of $2 variable when i has value "vpn-up" or "vpn-down".

So to fix an issue I've modified 2 lines in this script:
from

case "$2" in
    up )

to

case "$2" in
    up | vpn-up )

and the second one:
from

down )
 export MODE="stop"
 export PHASE="down"

to

down | vpn-down )
 export MODE="stop"
 export PHASE="down"

After this manipulations my start scripts under /etc/network/if-down.d and /etc/network/if-up.d now works fine.

Changed in network-manager (Ubuntu):
assignee: nobody → Сергій Матрунчик (SkyMan) (skymanphp)

also before every ending of "case" block it should be exit 0:

exec run-parts /etc/network/if-up.d
exit 0;
 ;;

without it the script causes an error.

Looks reasonable, marking as Triaged/Low, and assigning myself.

Changed in network-manager (Ubuntu):
assignee: Сергій Матрунчик (SkyMan) (skymanphp) → Mathieu Trudel (mathieu-tl)
status: New → Triaged
importance: Undecided → Low
Eric (pcapademic) (pcapademic) wrote :

Would suggest increasing the priority a little, because it seems that if the 01ifupdown script fails, other scripts in the

 /etc/NetworkManager/dispatcher.d/

directory don't get run. Or perhaps the fault is will NetworkManager - should it error out if one script stops working? New bug?

Eric (pcapademic) (pcapademic) wrote :

I just tried the fix of adding

exit 0;

after line 33 of /etc/NetworkManager/dispatcher.d/01ifupdown
I am still getting the error

ubuntu nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.

Not sure what to do stop the problem. Again, I wonder if the real problem isn't with nm-dispatcher that it stops running scripts in /etc/NetworkManager/dispatcher.d if one fails, but I don't know how the system needs to work to function properly.

It seems that the scripts in /etc/NetworkManager/dispatcher.d would still have been run, because the reason for the failures was the addition of a "hostname" action to trigger dispatcher scripts on hostname changes. Any other "standard" case would have just worked as usual to run dispatcher scripts in dispatcher.d (and then the ones from /etc/network/if*.d...) for up, down, pre-up and post-down events.

As a fix, and since ifupdown action scripts don't support the 'hostname' action AFAIK, I'll apply a fix to add a case for 'hostname' to just exit with status 0 and do nothing.

Changed in network-manager (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.8.3+git.20101209t061929.638fb18-0ubuntu1

---------------
network-manager (0.8.3+git.20101209t061929.638fb18-0ubuntu1) natty; urgency=low

  * upstream snapshot 2010-12-09 06:19:29 (GMT)
    + 638fb1878019ac75617b653d13f4970af6e9c970
    - core: correct TIMESTAMP type; fixes potential crash when time() is 32bit
      (LP: #686320)
    - libnm-glib: actually define the "ip-interface" property
    - ifupdown: Correctly mark unmanaged devices (debian #569215)
    - ifupdown: Allow to mark bridge ports as unmanaged (debian #530335)
  * Finish fixing daily builds: explicitly checkout/switch to the branch we're
    interested in before pulling new revisions so that it get properly updated.
    - update debian/rules
  * Revert s390 devices patch, it was applied upstream.
    - remove debian/patches/fix-natty-build.patch
    - update debian/patches/series
  * Add support for the 'hostname' dispatcher action that would previously
    trigger useless "exited with error status 1" messages (but not actually
    break anything). For now it will just exit doing nothing. (LP: #661951)
    - update debian/network-manager-dispatcher.script
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 10 Dec 2010 12:26:21 -0500

Changed in network-manager (Ubuntu):
status: Fix Committed → Fix Released

I suck, I obviously lost track of the original bug report -- the scripts are still missing vpn-up and vpn-down handlers, so I've reopened and I will upload another revision with this fixed after lunch ;)

Changed in network-manager (Ubuntu):
status: Fix Released → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.8.3+git.20101219t181118.e919218-0ubuntu1

---------------
network-manager (0.8.3+git.20101219t181118.e919218-0ubuntu1) natty; urgency=low

  * upstream snapshot 2010-12-19 18:11:18 (GMT)
    + e91921814569bf9033fa0779837a77b22eb98e4a
    - libnm-util: fix a memory leak in nm_setting_to_string()
    - various ipv6 fixes
    - libnm-util: fix nm_utils_security_valid() checks for Ad-Hoc APs
    - dns: direct IPv4 reverse DNS queries to split DNS servers
    - policy: stop touching /etc/hosts
    - dhclient: split out dhclient config merging and add testcases
    - dhclient: explicitly request WPAD option (bgo #368423)
  * Drop the patch to not write localhost.localdomain in /etc/hosts, it's no
    longer needed now that NM doesn't change the hosts file.
    - delete debian/patches/never-localhostlocaldomain.patch
    - update debian/patches/series
  * debian/libnm-glib2.symbols: Add new symbols for libnm-glib2:
    + nm_dhcp6_config_get_one_option
    + nm_dhcp6_config_get_options
    + nm_dhcp6_config_get_type
    + nm_dhcp6_config_new
  * Add vpn-up/vpn-down options for the NM dispatcher script. This should really
    fix bug 661951. (LP: #661951)
    - update debian/network-manager-dispatcher.script
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 20 Dec 2010 13:55:42 -0500

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released

The above script was slightly different to the one I have but I copied it and made the mods as above. The errors in syslog have gone but I'm no further forward. The OpenVPN connects, as before, but no data throughput.
Presumably the fix will come in the regular updates??

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers