Point-to-point data-link protocol


Point-to-point protocol (PPP) is the data link protocol used to connect two computers over a serial wire. It is the basis of dial-up connections, its most widespread use. But dial-up's telephones and modems play no role in establishing the data-link connection. They simply lengthen the wire over which PPP does so. Hence the dial-up part of "dial-up connection" comes from the modem and phone, while the connection part comes from PPP. We're interested in the latter not the former. To study PPP in a computer lab you don't need a phone. Here, we'll use direct cabling. No need to distract ourselves. Just understand that though dial-up is (almost always) point-to-point, point-to-point isn't dial-up.

Ideally there will be a null-modem serial cable in the lab for every pair of students. Alternatively, here we assume a single available cable used to extend an existing ethernet network by addition of one extra machine (B), tied to an existing one (A):


Independently there's typically protocol activity at the network layer too. What network protocol is found on either network is independent of both its underlying data link protocol and the network protocol on the other network. Also there could be more than one network protocol operational on either or both nets. We will have IP on both nets. Superimposing it, we get:


The assignment to be performed

1. Create a point-to-point link

That means, get the software up and running that can carry arbitrary data between the two serial ports. You aren't familiar with doing that for ppp's data link alternative, ethernet. You never have to launch any programs to make ethernet happen. That's only because ethernet doesn't run on your CPU. It runs instead in chips on the NIC, so is automatic and invisible. Not ppp. You run a program for that. It's pppd. You run it twice-- once on each computer referencing that computer's end of the serial cable (ie, its serial port). In this lab, you will run it if you are provided a cable. If only your instructor has one, he will run and show it instead.

There isn't really a client and server with ppp. Just two mirror-image counterparts. The name of the program pppd ends with the letter d, the UNIX convention for server ("daemon"), but the usual client/server distinction here doesn't really apply. Never mind, just run pppd on each of the 2 cabled-up computers, with the proper command options, and everything is going to be just fine! I'll call them B and A. Let B be the the above diagram's leftmost computer, and A the other one. Blue commands run on B, red on A. Do, within a few seconds of each other:

pppd  /dev/ttyS0  115200  crtscts  lock  local

pppd  /dev/ttyS0  115200  crtscts  lock  local


ifconfig  ppp0
ping  -c2

ifconfig  ppp0
ping  -c2
killall  pppd

pppd is now terminated on both ends.

2. Examine the link creation action with Wireshark

Wireshark has a problem showing ppp activity, for this and that reason. However you can get pppd itself, instead of the packet capture library, to record its actions in a file Wireshark can read later. Re-erect the point-to-point link, but record the actions involved:

pppd  /dev/ttyS0  115200  crtscts  lock  local
pppd  /dev/ttyS0  115200  crtscts  lock  local  record  ~/pppd-establish.cap
ifconfig  ppp0  >  ~/ppp01.txt
killall  pppd

If you did the above commands yourself, you possess the resultant file pppd-establish.cap. If your instructor did them, he will provide you the file

This file is in a particular format:

 "record filename" specifies that pppd should record all characters sent and received
 to a file named filename... The characters are stored in a tagged format with timestamps,
 which can be displayed in readable form using the pppdump(8) program.

    -- pppd man page description of "record" option

As such, tcpdump can't read it. Try it:

tcpdump  -r  ~/pppd-establish.cap

gets an error message. Wireshark, however, has this format in its repertoire. So run Wireshark and tell it to open pppd-establish.cap. It shows something like this:

It's all PPP protocol, with a mix of the sub-protocols LCP, CCP, and IPCP that belong to the PPP family.

Spend some time examining the frames closely in Wireshark, simultaneously comparing against rfc 1661's definition of  pppd or a good networking textbook's description of it. Have that document open on the desk beside you while Wireshark is on screen before you. Look back and forth between them a lot.

3. Repeat, exercising one of the command options

pppd  /dev/ttyS0  115200  crtscts  lock  local
pppd  /dev/ttyS0  115200  crtscts  lock  local mtu 500
ifconfig  ppp0  >  ~/ppp01.txt
killall  pppd

The command option is mtu, expressed as "mtu 500" above. The command options are given in the man page for pppd, which for mtu tells us:

"mtu n
Set the MTU [Maximum Transmit Unit] value to n. ... pppd will request that the kernel networking code send data packets of no more than n bytes through the PPP network interface."

In ppp01.txt find where the interface's mtu is shown to be 500 bytes (by default it would be 1500).

4. Make IP routing adjustments to integrate networks

Reconstruct the data link connection:

pppd  /dev/ttyS0  115200  crtscts  lock  local
pppd  /dev/ttyS0  115200  crtscts  lock  local

We want, in the IP layer on top of it, to tell IP on all machines where to reach all the others-- specifically, to include machine B so it becomes reachable on the same footing as the other computers. This is all about routing. On machine B:

route  add  -net  gw

On machine A:

echo  1  >  /proc/sys/net/ipv4/ip_forward

On all the other machines:

route  add  -host  gw

Now make sure all hosts can ping the new machine B and that B can ping all of them. For the network overall, between the two physical networks, there is disunity at the data link layer but now unity at the network layer.

5. Observe mtu's effect

The effect is fragmentation. An mtu of 1500 means the data link layer won't carry anything bigger than that. If something bigger comes down from the network layer, it will get split into multiple frames by data link. Ethernet has an mtu of 1500. ppp has an artificial mtu that you can set to a value you choose. Let's watch both in operation. To see ethernet's mtu, experiment on a link that runs ethernet. To see ppp's, use one that runs ppp. For ethernet, let's examine the link between your computer (one of the ethernet LAN members) and computer A since that link uses ethernet; for ppp, let's examine the link between B and A since it uses ppp. We'll do so by shooting controlled amounts of data over udp to a service that discards whatever it gets. Such a service is assumed to be running on port 9 of the target machine A. UDP packets layer an 8-byte header on the data they transport, and IP layers a further 20-byte header on top of that. If we send 1472 bytes of application data it adds up to 1500 and could travel in a single frame. Send 1473 however, and it will get split into 2 frames. Using two terminals or terminal windows on your machine, run tcpdump in one while running sock in the other to send controlled amounts of data. In the one terminal:

tcpdump  -nntvi  eth0  udp

and in the other:

sock  -u  -i  -n1  -w1472 9

followed by

sock  -u  -i  -n1  -w1473 9

How many frames resulted from the first sock command? How many from the second?

Move to machine B and repeat. This time the mtu imposed on you is that of ppp, not ethernet. But the result is the same because both are 1500. Now do it a second time on B, but revisit section 4 so you can tear down your existing ppp connection and create a new one with a 500-byte mtu at B. Sending 1472 bytes through, which could all fit in a single frame previously, will now take 3 or 4 of them.