Bug 52491 - if{up,down}-ippp non-pppd fixes, enabling IPv6
if{up,down}-ippp non-pppd fixes, enabling IPv6
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-08-24 04:28 EDT by Pekka Savola
Modified: 2014-03-16 22:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-09-02 07:50:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ifup-ippp non-syncppp fixes and ipv6 (2.07 KB, patch)
2001-08-24 04:28 EDT, Pekka Savola
no flags Details | Diff
ifdown-ippp ipv6 support (524 bytes, patch)
2001-08-24 04:29 EDT, Pekka Savola
no flags Details | Diff

  None (edit)
Description Pekka Savola 2001-08-24 04:28:16 EDT
Peter Bieringer, while working to get IPv6 enabled on 'isdn0' like devices,
sent me two patches, which also/mostly contain some generic fixes too.

His comments enclosed.

-    log_isdnctrl pppbind $DEVICE
+    [ "$ENCAP" = "syncppp" ] && log_isdnctrl pppbind $DEVICE

pppbind makes no sense on using isdnX devices

+    # set netmask, if available
+    [ -n "$NETMASK" ] && netmask="netmask $NETMASK"
     # activate ISDN device
-    ifconfig $DEVICE $LOCAL_IP pointopoint $REMOTE_IP up >/dev/null 2>&1
+    ifconfig $DEVICE $LOCAL_IP pointopoint $REMOTE_IP $netmask up
>/dev/null 2>&1

[netmask doesn't matter that much on pointopoint links, but one could be

-    [ -n "$ISDN_HOSTNAME" ] && options="$options hostname
+    [ -n "$ISDN_HOSTNAME" ] && options="$options remotename

option "hostname" isn't recognized by ipppd (ifup won't work)

-        route del default >/dev/null 2>&1
-        if [ -z "$REMOTE_IP" -o "$REMOTE_IP" = "" ]; then
-            route add default $DEVICE >/dev/null 2>&1
-        else
-            route add default gw $REMOTE_IP >/dev/null 2>&1
-	fi
+       if  [ "$DEFROUTE" = "yes" ]; then
+               route del default >/dev/null 2>&1
+               if [ -z "$REMOTE_IP" -o "$REMOTE_IP" = "" ]; then
+                   route add default $DEVICE >/dev/null 2>&1
+               else
+                   route add default gw $REMOTE_IP >/dev/null 2>&1
+               fi
+       fi

defaultroute is set on dialmode auto regardless the setting of
DEFROUTE. This breaks automatic P-t-P links to stub subnets.

[NOTE! Hopefully the isdn-config programs generate DEFROUTE=yes, else this
change would break for those enabling default route..]

And IPv6 additions:

+# Get global network configuration
+. /etc/sysconfig/network

[ probably should get the config from other locations too (the new
scheme).. ]

+    ## Setup IPv6
+    if [ "${NETWORKING_IPV6}" = "yes" ]; then
+	/etc/sysconfig/network-scripts/ifup-ipv6 $DEVICE

[ actually, this probably should be ${CONFIG} .. in this case it shouldn't
matter, but
with general ifup structure it might if you store the 
configs under /etc/sysconfig/networking/ with a different name ]

And similar for ifdown-ippp:

+# Shut down IPv6
+if [ "${NETWORKING_IPV6}" = "yes" ]; then
+    /etc/sysconfig/network-scripts/ifdown-ipv6 $DEVICE

[ $DEVICE => ${CONFIG} ]

( ipppd has a bug wrt. ipv6 but that's beside the point now :-)

Attaching his diffs.
Comment 1 Pekka Savola 2001-08-24 04:28:59 EDT
Created attachment 29349 [details]
ifup-ippp non-syncppp fixes and ipv6
Comment 2 Pekka Savola 2001-08-24 04:29:42 EDT
Created attachment 29350 [details]
ifdown-ippp ipv6 support
Comment 3 Bill Nottingham 2001-08-24 11:49:13 EDT
Than, does this stuff look sane for ISDN?
Comment 4 Pekka Savola 2001-09-02 07:50:12 EDT
Any news?  Don't enable ipv6 if doubtful, but at least some of the blatant bugs should be fixed.. :-)

Additional fix:

--- ifup-isdn.orig      Sun Sep  2 11:22:15 2001
+++ ifup-isdn   Sun Sep  2 11:22:30 2001
@@ -144,6 +144,8 @@
     # set callback
     if [ "$CALLBACK" = "out" ]; then
         log_isdnctrl callback $DEVICE $CALLBACK
+    elif [ "$CALLBACK" = "in" ]; then
+        log_isdnctrl callback $DEVICE $CALLBACK
         log_isdnctrl callback $DEVICE off
Comment 5 Ngo Than 2001-09-02 19:29:29 EDT
>-    log_isdnctrl pppbind $DEVICE
>+    [ "$ENCAP" = "syncppp" ] && log_isdnctrl pppbind $DEVICE

>pppbind makes no sense on using isdnX devices
i don't think so, channel bundling should work with rawip too!

i have cleaned up your changes. The Changes are now in CVS.
i don't want to enable IPv6, because i cannot test it and don't know if ISDN
works with IPv6. It's risky to enable IPv2 now.

Comment 6 Pekka Savola 2001-09-03 03:50:34 EDT
Ok, it's rather late in the process.  Will ask for Peter to verify.


    # check local/remote IP
    [ -z "$IPADDR" ] && IPADDR=""
    [ -z "$GATEWAY" ] && GATEWAY=""

What the heck are these defaults? :-)
Comment 7 Ngo Than 2001-09-03 07:40:51 EDT
typo bug. it's fixed in CVS now.
Comment 8 Pekka Savola 2001-09-03 08:52:10 EDT
Hmm, man isdnctrl says:

       pppbind name [num]
              Binds  the  interface  name to an ippp device /dev/ipppnum.  This works only
              for synchronous ppp. The value must be a number.  If num is omitted and name
              is called ipppX , then the interface is bound to /dev/ipppX.

This,and the name, implies strongly that _this_ method of doing channel bundling only applies to ppp.  
Whether there are alternate methods for channel bundling for rawip etc. is another issue.

So it looks like this should be fixed?  (I think there will be an error printed if you try pppbind with non-ppp).
Comment 9 Ngo Than 2001-09-03 09:40:58 EDT
i have readed another ISDN doku, it says it should work with rawip, too :-(

i have take a look in sources, it seems that pppbind does not work with rawip
(isdn devices).

Thanks, it's fixed in CVS.

Note You need to log in before you can comment on or make changes to this bug.