3. PPPD

3.2.1. Starting the pppd and keeping it alive

You could start the pppd form a boot (rc) script. However, if you do this, and the pppd dies, you are without a link. A more stable solution, is to start the pppd from /etc/inittab;

s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200

This way, the pppd will be restarted if it dies. Make sure you have a `-detach' option (nodetach on newer systems) though, otherwise inittab will start numerous instances of pppd, while complaining about `respawning too fast'.

Note: Some older systems will not accept the speed `115200'. In this case you will have to set the speed to 38400 and set the `spd_vhi' flag with setserial. Some systems expect you to use a `cua' instead of `ttyS' device.

3.2.2. Setting the routes

The default route can be set with the defaultroute option or with the /etc/ppp/ip-up script;

#!/bin/bash case $2 in /dev/ttyS1) /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 ;; esac

Ip-up can also be used to sync your clock using netdate.

Of course the route set in ip-up is not necessarily the default route. Your ip-up sets the route to the remote network while the ip-up script on the remote system sets the route to your network. If your network is 192.168.1.0 and your ppp interface 192.168.1.1, the ip-up script on the remote machine looks like this;

#!/bin/bash case $2 in /dev/ttyS1) /sbin/route add -net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0 ;; esac

The `case $2' and `/dev/ttyS1)' bits are there in case you use more than one ppp link. Ip-up will run each time a link comes up, but only the part between `/dev/ttySx)' and `;;' will be executed, setting the right route for the right ttyS. You can find more about routing in the Linux Networking HOWTOs section on routing.

Some systems use dynamic ttys, in which case you can't route on a tty basis. In this case it might be handy to translate the ip address to a ppp interface and then do the routing (and firewalling) on a ppp interface basis. For this purpose I edited /etc/ppp/ip-up;

# These variables are for the use of the scripts run by run-parts PPP_IFACE="$1" PPP_TTY="$2" PPP_SPEED="$3" PPP_LOCAL="$4" PPP_REMOTE="$5" PPP_IPPARAM="$6" export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM # translate ip to ppp echo $PPP_IFACE > "/var/run/ppp/if-$PPP_LOCAL" sleep 1 # Rerun firewall. /usr/local/sbin/rc.block # Take care of the (default) route(s) case $PPP_LOCAL in "My_Ip_Address") /sbin/route add -net 0.0.0.0 gw $PPP_REMOTE netmask 0.0.0.0 ;; esac # Fix things missed at boot if ! ( netstat -an | grep 'My_Ip_Address:53' > /dev/null 2>&1 ) then # Just booted # Sync clock /usr/local/sbin/ntpdate.sh & # Set the null routes /usr/local/sbin/null-route.sh & # Bind 9 needs this; sleep 1 /etc/init.d/bind9 restart fi # An audiable notification /bin/echo -ne "\007" >> /dev/tty1

Replace 'My_Ip_Address' with your Ip address. /usr/local/sbin/ntpdate.sh synchronises the clock. It stops the NTPD, syncs using ntpdate and then starts the NTPD again. /usr/local/sbin/null-route.sh is a script which sets null routes;

#!/bin/bash route add -net 10.0.0.0 netmask 255.0.0.0 reject route add -net 172.16.0.0 netmask 255.240.0.0 reject route add -net 192.168.0.0 netmask 255.255.0.0 reject

If you have RFC 1918 addresses in use, the above null routes won't interfere provided you use a smaller netmask. A network 192.168.1.0/24 won't be bothered by the null route 192.168.0.0/16;

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth1 195.190.249.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 - 255.255.0.0 ! 0 - 0 - 172.16.0.0 - 255.240.0.0 ! 0 - 0 - 10.0.0.0 - 255.0.0.0 ! 0 - 0 - 0.0.0.0 195.190.249.4 0.0.0.0 UG 0 0 0 ppp0