linux pppd
| These are my personal notes on how to use `pppd' on linux. I need these personal notes to remind me of various sequences of steps. |
| How `pppd' is set up on my old RedHat 5.2 firewall/gateway. On my old decrepit firewall gateway called dog, the operating system is RedHat 5.2, and the `pppd' process is run out of the file ``/etc/rc.d/init.d/network''. Here are some excerpts.
cd /etc/sysconfig/network-scripts
# find all the interfaces besides loopback.
# ignore aliases, alternative configurations, and editor backup files
interfaces=`ls ifcfg* | egrep -v '(ifcfg-lo|:)' | egrep 'ifcfg-[a-z0-9]+$' | \
sed 's/^ifcfg-//g'`
This should result in the shell variable `interfaces' having the value ``eth0 ppp0 ppp1 ppp2'' since the ifcfg files in /etc/rc.d/init.d/network are as follows. -rw-r--r-- 1 root root 129 Aug 15 1999 ifcfg-eth0 -rwxr-xr-x 1 root root 115 Aug 15 1999 ifcfg-lo -rw-r--r-- 1 root root 268 Aug 15 1999 ifcfg-ppp0 -rwxr-xr-x 1 root root 315 Aug 15 1999 ifcfg-ppp1 -rw-r--r-- 1 root root 31 Aug 15 1999 ifcfg-ppp1-ppp2 -rw-r--r-- 1 root root 309 Aug 15 1999 ifcfg-ppp2 The next significant thing in the file ``/etc/rc.d/init.d/network'' is
for i in $interfaces; do
./ifup $i boot
done
The script ``/etc/sysconfig/network-scripts/ifup'' is quite long (179 lines). It commences by including bourne-shell function definitions from the file ``/etc/sysconfig/network-scripts/network-functions''. cd /etc/sysconfig/network-scripts . network-functions In particular, the script ``source_config'' is run. This script is defined in ``/etc/sysconfig/network-scripts/network-functions'' as follows.
source_config ()
{
DEVNAME=`basename $CONFIG | sed 's/^ifcfg-//g'`
if basename $CONFIG | grep -q '[^g]-' ; then
PARENTCONFIG=`echo $CONFIG | sed 's/-[^-]*$//g'`
PARENTDEVNAME=`echo $PARENTCONFIG | sed 's/^ifcfg-//g'`
[ -f $PARENTCONFIG ] || {
echo "Missing config file $PARENTCONFIG." >&2
exit 1
}
. $PARENTCONFIG
fi
. $CONFIG
}
The script ``/etc/sysconfig/network-scripts/ifcfg-ppp2'' contains a big bunch of variable settings as follows. PERSIST=yes DEFROUTE=yes ONBOOT=yes INITSTRING='ATZ0%C0' MODEMPORT=/dev/ttyS1 LINESPEED=115200 ESCAPECHARS=no DEFABORT=yes HARDFLOWCTL=yes DEVICE=ppp2 PPPOPTIONS= DEBUG=no PAPNAME=akenning REMIP=139.130.140.1 IPADDR=139.130.140.14 BOOTPROTO=none MTU=1500 MRU=1500 DISCONNECTTIMEOUT= RETRYTIMEOUT=5 USERCTL=no Next the following code is executed.
if [ "foo$2" = "fooboot" -a "${ONBOOT}" = "no" ]
then
exit
fi
This conditional fails. So the script continues. The next section of ``/etc/sysconfig/network-scripts/ifup'' which seems to be significant is as follows.
DEVICETYPE=`echo $DEVICE | sed "s/[0-9]*$//"`
# [....]
OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-${DEVICETYPE}"
if [ -x $OTHERSCRIPT ]; then
exec $OTHERSCRIPT $CONFIG $2
fi
This causes the script ``/etc/sysconfig/network-scripts/ifup-ppp'' to be executed because the terminal integer is removed by ``sed''. It is called with the parameters ``ppp2'' and ``boot''. The script ``/etc/sysconfig/network-scripts/ifup-ppp'' is quite large (121 lines). It checks to see that the executable file ``/usr/sbin/pppd'' exists, and that the file ``/etc/sysconfig/network-scripts/chat-ppp2'' exists. The ``chat-ppp2'' file contains the following parameters. (The dial-up number has been disguised.) 'ABORT' 'BUSY' 'ABORT' 'ERROR' 'ABORT' 'NO CARRIER' 'ABORT' 'NO DIALTONE' 'ABORT' 'Invalid Login' 'ABORT' 'Login incorrect' '' 'ATZ0%C0' 'OK' 'ATDT99999999' 'CONNECT' '' 'TIMEOUT' '5' '~--' '' Then the script ``/etc/sysconfig/network-scripts/ifup-ppp'' sets the variable ``opts'' to the following. lock modem crtscts defaultroute mru 1500 mtu 1500 139.130.140.14:139.130.140.1 name akenning Then the ifup-ppp script goes into an infinite loop, running the following command line.
/usr/sbin/pppd -detach $opts $MODEMPORT $LINESPEED \
remotename $DEVICE ipparam $DEVICE \
${PPPOPTIONS} \
connect "/usr/sbin/chat $chatdbg -f $CHATSCRIPT"
Hopefully the parameter ``-detach'' means the same as the documented ``nodetach'' option for pppd. If the pppd process exits, the loop goes around again if the variable PERSIST is set to ``yes''. |
| How `pppd' is not set up in SuSE 7.1. The SuSE linux distributions simply don't seem to have the equivalent set-up for configuring permanent modem connections to what RedHat has. Therefore I will have to duplicate the above functionality by hand for the new SuSE 7.1 system. When I look into the file /etc/rc.d/network on my SuSE 7.1 system, I see this sort of thing.
for I in $NETCONFIG; do
eval NETDEV=\$NETDEV$I
eval IFCONFIG=\$IFCONFIG$I
case "$IFCONFIG" in
bootp)
/sbin/bootp $NETDEV -v
continue
;;
dhcpclient)
# Will be done in dhclient boot script, therefore
continue
;;
esac
case $NETDEV in
ippp*|ppp*|isdn*)
# Will be done in i4l boot scripts, therefore
continue
;;
*)
echo "Setting up network device $NETDEV"
ifconfig $NETDEV $IFCONFIG
rc_status -v1
;;
esac
done
Now the variables like NETDEV_0 and IFCONFIG_0 come from the /etc/rc.config file. This config file is supposed to be managed from YaST. But when you try to configure one of the 4 network interfaces in YaST's network selection menu to make it run pppd, it just tells you to go away! For instance, it says the following. The wvdial package replaces the previous PPP configuration in YaST. The wvdial program is easier to use and more flexible than the suseppp solution. Please read the documentation in /usr/doc/packages/wvdial. The configuration of wvdial can also be configured from outside YaST, with the program wvdial.lxdialog . The suseppp scripts are still available, and can be found on CD1 in the directory unsorted/suseppp as an rpm file. So there are two problems here. First, you can't even get the "ppp0" interface into the NETDEV variable with YaST. Second, even if it was there, the /etc/rc.d/network script would ignore it. If you look in the /etc/rc.d/i4l boot script, it also ignores ppp interfaces. It only does ippp interfaces for ISDN. This is the link for wvdial. Conclusion: In SuSE 7.1, there is a script /etc/rc.d/wvdial.dod, but this is for ``dial on demand'', which is not what I want. So I might see if I can get some clues from this script, together with the RedHat scripts. |
| How I'm going to set up a permanent modem link in SuSE 7.1. First, I need to choose an existing script or create a new script in /etc/rc.d to run ``pppd'' out of. Then I need to either add config variables to /etc/rc.config to make adjustements, or else I need to create a new config file, maybe in /etc. Now I've created a new script /etc/rc.d/pppd.ak, and I've added a new variable PPPD_AK_START in /etc/rc.config. The variable PPPD_AK_START should be "yes" or "no" according to whether the pppd.ak script should be activated at boot time or not. To design my /etc/rc.d/pppd.ak script, it's useful to know that when ``init'' runs at boot time, it refers to these lines in the file /etc/inittab. # /etc/init.d/rc takes care of runlevel handling # # runlevel 0 is System halt (Do never use this for initdefault) # runlevel 1 is Single user mode # runlevel 2 is Local multiuser without remote network (e.g. NFS) # runlevel 3 is Full multiuser with network # runlevel 4 is Not used # runlevel 5 is Full multiuser with network and xdm # runlevel 6 is System reboot (Do never use this for initdefault) # l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 #l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 The script /etc/init.d/rc has the following lines to invoke the /etc/rc.d start-up scripts.
for i in $runrc/S${rex}*; do
test -x "$i" || continue
#
# Don't start service if previous runlevel includes the service.
#
service=${i#*/S$rex}
set -- $prerc/K$rex$service
test $# -gt 1 && echo -e "$attn$prerc/: more than one link for service $service$norm"
test -x "$1" && continue
#
# Start the services of the current (new) runlevel if they are missed
# within the previous runlevel.
#
$i start || failed="${failed} ${service}"
echo -n -e "$rc_reset"
done
This clearly shows that the /etc/rc.d scripts are invoked with only one parameter, e.g. ``start'' in the case of entering a run-level. The scripts such as /etc/rc.d/wvdial.dod are way too complex. So I'm going to use the following sort of thing instead, to just hand over the start/stop command to another script.
#! /bin/bash
# dog2:/etc/rc.d/pppd.ak 8 April 2001 Alan Kennington.
#
. /etc/rc.status
. /etc/rc.config
base=${0##*/}
link=${base#*[SK][0-9][0-9]}
test $link = $base && PPPD_AK_START=yes
test "$PPPD_AK_START" = "yes" || exit 0
rc_reset
case "$1" in
start)
echo -n "Starting pppd.ak"
/etc/ppp/ak/pppd.ak
rc_status -v
sleep 1
;;
stop)
echo -n "Shutting down pppd.ak"
killproc -TERM pppd
rc_status -v
;;
restart|reload)
$0 stop && $0 start
rc_status
;;
status)
route -n
;;
*)
echo "Usage: $0 {start|restart|reload|status|stop}"
exit 1
esac
rc_exit
|
| Modem retraining problems again!!!!! After working out a bandage solution for the old modem retraining problem on the old dog computer, the new dog computer has now developed a similar problem. The trouble is that the symptoms are completely different. So my old inference algorithm won't work. Here's a sample of the ping symptoms. Here ping was run on fox (formerly known as dog). PING 139.130.140.1 (139.130.140.1): 56 data bytes 64 bytes from 139.130.140.1: icmp_seq=0 ttl=254 time=11307.6 ms 64 bytes from 139.130.140.1: icmp_seq=12 ttl=254 time=132.9 ms 64 bytes from 139.130.140.1: icmp_seq=13 ttl=254 time=7873.3 ms 64 bytes from 139.130.140.1: icmp_seq=21 ttl=254 time=133.2 ms 64 bytes from 139.130.140.1: icmp_seq=22 ttl=254 time=8453.5 ms 64 bytes from 139.130.140.1: icmp_seq=31 ttl=254 time=133.5 ms 64 bytes from 139.130.140.1: icmp_seq=32 ttl=254 time=8773.8 ms 64 bytes from 139.130.140.1: icmp_seq=41 ttl=254 time=144.0 ms 64 bytes from 139.130.140.1: icmp_seq=42 ttl=254 time=8054.0 ms 64 bytes from 139.130.140.1: icmp_seq=51 ttl=254 time=8334.4 ms --- 139.130.140.1 ping statistics --- 110 packets transmitted, 10 packets received, 90% packet loss round-trip min/avg/max = 132.9/5334.0/11307.6 ms |
Go to my notes on the linux PPP kernel module software.
Go to my notes on other linux configuration topics.
Go to linux links.
Go to Alan Kennington's home page.