PPP with Pseudo Terminals
Author
Commands
# start with an empty set of ppp options mv /etc/ppp/options /etc/ppp/options.bak touch /etc/ppp/options # run this first at one command prompt pppd /dev/ptyp0 nodetach local 10.0.3.1:10.0.3.2 # run this at another command prompt pppd /dev/ttyp0 nodetach local
Summary
Connecting two pppd commands together on the same host with pseudo terminal devices.
Discussion
These commands all have to be run from the root account.
Our first two commands move the existing /etc/ppp/options file out of the way and replace it with an empty file.
The pppd command will behave very differently depending on how all of its billion and one options are set. When experimenting, it's best to empty the /etc/ppp/options file so the only options in effect are the ones we supply on the command line. Each linux distribution may ship with a potentially different /etc/ppp/options file; you may want to save the default file somewhere before creating an empty one so you can restore the distribution's default policies once you are done experimenting.
Our last two commands connect two pppd daemon's together using a master/slave pseudo terminal pair: /dev/pty0 (the master terminal) and /dev/ttyp0 (the slave terminal). Pseudo terminal device pairs are normally used to connect a shell session with a remote user through telnet or secure shell processes. They are prefect for experimenting with pppd commands since they act just like serial ports. As an example, you can query and set their baud rate, and a zillion other things that would only make sense for a serial port.
The nodetach option prevents pppd from detaching from the terminal session it is invoked from, like it normally would, and sending its error and status messages to the syslog. Instead, it remains in the foreground, where it can easily be killed with a cntl-c, and all of its diagnostic output is printed to stdout. Without this option, you would be forced to do something like this to see the command's diagnostic messages:
tail -f /var/log/messages
We type the first pppd command in one xterm (or virtual console) and the second one in another. The "local" option tells pppd to not attempt to use modem control lines. The "10.0.3.1:10.0.3.2" parameter is saying that the local IP address should be set to 10.0.3.1 and the remote one to 10.0.3.2.
After typing the first pppd command, you should see something like this:
Using interface ppp0 Connect: ppp0 <--> /dev/ptyp0
After typing the second command, the two pppd's will talk to each other and the first one will tell the second one what its IP address should be. The first window will now display:
Using interface ppp0 Connect: ppp0 <--> /dev/ptyp0 Deflate (15) compression enabled Cannot determine ethernet address for proxy ARP local IP address 10.0.3.1 remote IP address 10.0.3.2
and the second one will show:
Using interface ppp1 Connect: ppp1 <--> /dev/ttyp0 Deflate (15) compression enabled Cannot determine ethernet address for proxy ARP local IP address 10.0.3.2 remote IP address 10.0.3.1
Although you can now ping both addresses, the ICMP packets are not actually sent over either of the ppp links, since the kernel sees that both addresses are owned by network interfaces on the local host. Instead, the kernel delivers the packets over the loopback device.
To verify this, run these commands as root:
tcpdump -i lo -n "imcp" tcpdump -i ppp0 -n "icmp" tcpdump -i ppp1 -n "icmp" ping 10.0.3.1
Run each tcpdump command in a separate xterm, and the ping from yet another. You'll see the packets going through the lo interface and not ppp0 or ppp1.