Bugfix default route handling by using GRANDparent process ID to uniquely identify...

In 01d3b8c0, I tried to fix an issue with default route restoration when
multiple "stacked" VPNs were running.  However, this actually caused more
problems than it solved, by breaking default route restoration in the
"usual" case of a single VPN.

The problem is that OpenConnect (and vpnc) always call the vpnc-script via
an intermediary, ephemeral shell process.  So the GRANDparent process ID
must be used to persistently identify the VPN connection between vpnc-script
'connect' and 'disconnect' invocations.

Fixes #28.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

diff --git a/vpnc-script b/vpnc-script
index 5a169618c79a797a5682e7aca464ccb4f82b8be2..47a62a20410709fd2f157744f10082b901f12b68 100755 (executable)
--- a/vpnc-script
+++ b/vpnc-script
@@ -88,8 +88,18 @@ PATH=/sbin:/usr/sbin:$PATH
 OS="`uname -s`"
 
 HOOKS_DIR=/etc/vpnc
-DEFAULT_ROUTE_FILE=/var/run/vpnc/defaultroute.${PPID}
-DEFAULT_ROUTE_FILE_IPV6=/var/run/vpnc/defaultroute_ipv6.${PPID}
+
+# Use the PID of the controlling process (vpnc or OpenConnect) to
+# uniquely identify this VPN connection. Normally, the parent process
+# is a shell, and the grandparent's PID is the relevant one.
+VPNPID=$PPID
+PCMD=`ps -c -o cmd= -p $PPID`
+case "$PCMD" in
+    *sh) VPNPID=`ps -o ppid= -p $PPID` ;;
+esac
+
+DEFAULT_ROUTE_FILE=/var/run/vpnc/defaultroute.${VPNPID}
+DEFAULT_ROUTE_FILE_IPV6=/var/run/vpnc/defaultroute_ipv6.${VPNPID}
 RESOLV_CONF_BACKUP=/var/run/vpnc/resolv.conf-backup
 SCRIPTNAME=`basename $0`