<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML ><HEAD ><TITLE >PPPD</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="Leased line Mini HOWTO" HREF="index.html"><LINK REL="PREVIOUS" TITLE="Modem" HREF="modem.html"></HEAD ><BODY CLASS="sect1" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >Leased line Mini HOWTO</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="modem.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" ></TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" > </TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="sect1" ><H1 CLASS="sect1" ><A NAME="pppd" ></A >3. PPPD</H1 ><P > You need a pppd (Point to Point Protocol Daemon) and a reasonable knowledge of how it works. Consult the relevant RFC's or the <A HREF="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html" TARGET="_top" >Linux PPP HOWTO</A > if necessary. Since you are not going to use a login procedure, you don't use (m)getty and you do not need a (fake) user associated with the pppd controlling your link. You are not going to dial so you don't need any chat scripts either. In fact, the modem circuit and configuration you have just build, are rather like a fully wired null modem cable. This means you have to configure your pppd the same way as you would with a null modem cable. </P ><P > For a reliable link, your setup should meet the following criteria; <P ></P ><UL ><LI ><P > Shortly after booting your system, pppd should raise the DTR signal in your RS232 port, wait for DCD to go up, and negotiate the link. </P ></LI ><LI ><P > If the remote system is down, pppd should wait until it is up again. </P ></LI ><LI ><P > If the link is up and then goes down, pppd should reset the modem (it does this by dropping and then raising DTR), and then try to reconnect. </P ></LI ><LI ><P > If the quality of the link deteriorates too much, pppd should reset the modem and then reestablish the link. </P ></LI ><LI ><P > If the process controlling the link, that is the pppd, dies, a watchdog should restart the pppd. </P ></LI ></UL > </P ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A NAME="pppd-conf" ></A >3.1. Configuration</H2 ><P > Suppose the modem is connected to COM2, the local IP address is `Loc_Ip' and the remote IP address is `Rem_Ip'. We want to use 576 as our MTU. The <TT CLASS="filename" >/etc/ppp/options.ttyS1</TT > would now be: <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > crtscts mru 576 mtu 576 passive Loc_Ip:Rem_Ip -chap modem #noauth -pap persist #maxfail 0 #holdoff 10 </PRE ></FONT ></TD ></TR ></TABLE > Stuff like `asyncmap 0', `lock', `modem' and `-detach' are probably already in <TT CLASS="filename" >/etc/ppp/options</TT >. If not, add them to your <TT CLASS="filename" >/etc/ppp/options.ttyS1</TT >. So, if the local system is 192.168.1.1 and the remote system is 10.1.1.1, then <TT CLASS="filename" >/etc/ppp/options.ttyS1</TT > on the local system would be: <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > crtscts mru 576 mtu 576 passive 192.168.1.1:10.1.1.1 -chap modem #noauth -pap persist #maxfail 0 #holdoff 10 </PRE ></FONT ></TD ></TR ></TABLE > The options.ttyS1 on the remote system would be: <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > crtscts mru 576 mtu 576 passive 10.1.1.1:192.168.1.1 -chap modem #noauth -pap persist #maxfail 0 #holdoff 10 </PRE ></FONT ></TD ></TR ></TABLE > The passive option limits the number of (re)connection attempts. The persist option will keep pppd alive in case of a disconnect or when it can't connect in the first place. If you telnet a lot while doing filetransfers (FTP or webbrowsing) at the same time, you might want to use a smaller MTU and MRU such as 296. This will make the remote system more responsive. If you don't care much about telnetting during FTP, you could set the MTU and MRU to 1500. Keep in mind though, that UDP cannot be fragmented. <A HREF="http://www.fourmilab.ch/netfone/" TARGET="_top" >Speakfreely</A > for instance uses 512 byte UDP packets. So the minimum MTU for speakfreely is 552 bytes. The noauth option may be necessary with some newer distributions. `maxfail 0' may be necessary with newer PPPDs. After the connection is lost, PPPD will wait for a while before reconnecting. This time can be set with the holdoff option. The default holdoff used to be 30 seconds, but is now zero. A holdoff of 10 is often recommended. </P ></DIV ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A NAME="scripts" ></A >3.2. Scripts</H2 ><DIV CLASS="sect3" ><H3 CLASS="sect3" ><A NAME="start" ></A >3.2.1. Starting the pppd and keeping it alive</H3 ><P > 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 <TT CLASS="filename" >/etc/inittab</TT >; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 </PRE ></FONT ></TD ></TR ></TABLE > 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'. </P ><P > 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. </P ></DIV ><DIV CLASS="sect3" ><H3 CLASS="sect3" ><A NAME="routes" ></A >3.2.2. Setting the routes</H3 ><P > The default route can be set with the defaultroute option or with the <TT CLASS="filename" >/etc/ppp/ip-up</TT > script; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > #!/bin/bash case $2 in /dev/ttyS1) /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 ;; esac </PRE ></FONT ></TD ></TR ></TABLE > Ip-up can also be used to sync your clock using netdate. </P ><P > 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; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > #!/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 </PRE ></FONT ></TD ></TR ></TABLE > 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 <A HREF="http://www.tldp.org/HOWTO/HOWTO-INDEX/networking.html" TARGET="_top" >Linux Networking HOWTOs</A > section on routing. </P ><P > 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 <TT CLASS="filename" >/etc/ppp/ip-up</TT >; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > # 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 </PRE ></FONT ></TD ></TR ></TABLE > Replace 'My_Ip_Address' with your Ip address. <TT CLASS="filename" >/usr/local/sbin/ntpdate.sh</TT > synchronises the clock. It stops the NTPD, syncs using ntpdate and then starts the NTPD again. <TT CLASS="filename" >/usr/local/sbin/null-route.sh</TT > is a script which sets null routes; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > #!/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 </PRE ></FONT ></TD ></TR ></TABLE > 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; <TABLE BORDER="0" BGCOLOR="#E0E0E0" WIDTH="100%" ><TR ><TD ><FONT COLOR="#000000" ><PRE CLASS="screen" > 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 </PRE ></FONT ></TD ></TR ></TABLE > </P ></DIV ></DIV ><DIV CLASS="sect2" ><H2 CLASS="sect2" ><A NAME="pppd-test" ></A >3.3. Test</H2 ><P > Test the whole thing just like the modem test. If it works, get on your bike and bring the remote modem to the remote side of your link. If it doesn't work, one of the things you should check is the COM port speed; Apparently, a common mistake is to configure the modems with Minicom using one speed and then configure the pppd to use an other. This will <EM >NOT</EM > work! You have to use the same speed all of the time! </P ></DIV ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="modem.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" > </TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Modem</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" > </TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" > </TD ></TR ></TABLE ></DIV ></BODY ></HTML >