Bug 52491

Summary: if{up,down}-ippp non-pppd fixes, enabling IPv6
Product: [Retired] Red Hat Linux Reporter: Pekka Savola <pekkas>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: rvokal, than
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-02 11:50:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
ifup-ippp non-syncppp fixes and ipv6
ifdown-ippp ipv6 support none

Description Pekka Savola 2001-08-24 08:28:16 UTC
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 08:28:59 UTC
Created attachment 29349 [details]
ifup-ippp non-syncppp fixes and ipv6

Comment 2 Pekka Savola 2001-08-24 08:29:42 UTC
Created attachment 29350 [details]
ifdown-ippp ipv6 support

Comment 3 Bill Nottingham 2001-08-24 15:49:13 UTC
Than, does this stuff look sane for ISDN?

Comment 4 Pekka Savola 2001-09-02 11:50:12 UTC
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 23:29:29 UTC
>-    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 07:50:34 UTC
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 11:40:51 UTC
typo bug. it's fixed in CVS now.

Comment 8 Pekka Savola 2001-09-03 12:52:10 UTC
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 13:40:58 UTC
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.