Linux Network Administrator Guide, Second Edition

user	The username of the user invoking dip that this entry will apply to.
password	Field 2 of the /etc/diphosts file is used to add an extra layer of password-based security on the connection. You can place a password in encrypted form here (just as in /etc/passwd) and diplogin will prompt for the user to enter the password before allowing SLIP access. Note that this password is used in addition to the normal login -based password the user will enter.
rem-addr	The address that will be assigned to the remote machine. This address may be specified either as a hostname that will be resolved or an IP address in dotted quad notation.
loc-addr	The IP address that will be used for this end of the SLIP link. This may also be specified as a resolvable hostname or in dotted quad format.
netmask	The netmask that will be used for routing purposes. Many people are confused by this entry. The netmask doesn't apply to the SLIP link itself, but is used in combination with the rem-addr field to produce a route to the remote site. The netmask should be that used by the network supported by that of the remote host.
comments	This field is free-form text that you may use to help document the /etc/diphosts file. It serves no other purpose.
protocol	This field is where you specify what protocol or line discipline you want applied to this connection. Valid entries here are the same as those valid for the -p argument to the slattach command.
MTU	The maximum transmission unit that this link will carry. This field describes the largest datagram that will be transmitted across the link. Any datagram routed to the SLIP device that is larger than the MTU will be fragmented into datagrams no larger than this value. Usually, the MTU is configured identically at both ends of the link.

A sample entry for dent could look like this:

dent::dent.beta.com:vbrew.com:255.255.255.0:Arthur Dent:CSLIP,296

Our example gives our user dent access to SLIP with no additional password required. He will be assigned the IP address associated with dent.beta.com with a netmask of 255.255.255.0. His default route should be directed to the IP address of vbrew.com, and he will use the CSLIP protocol with an MTU of 296 bytes.

When dent logs in, diplogin extracts the information on him from the diphosts file. If the second field contains a value, diplogin will prompt for an 'external security password.' The string entered by the user is encrypted and compared to the password from diphosts. If they do not match, the login attempt is rejected. If the password field contains the string s/key, and dip was compiled with S/Key support, S/Key authentication will take place. S/Key authentication is described in the documentation that comes in the dip source package.

After a successful login, diplogin proceeds by flipping the serial line to CSLIP or SLIP mode, and sets up the interface and route. This connection remains established until the user disconnects and the modem drops the line. diplogin then returns the line to normal line discipline and exits.

diplogin requires superuser privilege. If you don't have dip running setuid root, you should make diplogin a separate copy of dip instead of a simple link. diplogin can then safely be made setuid without affecting the status of dip itself.

Chapter 8. The Point-to-Point Protocol

Like SLIP, PPP is a protocol used to send datagrams across a serial connection; however, it addresses a couple of the deficiencies of SLIP. First, it can carry a large number of protocols and is thus not limited to the IP protocol. It provides error detection on the link itself, while SLIP accepts and forwards corrupted datagrams as long as the corruption does not occur in the header. Equally important, it lets the communicating sides negotiate options, such as the IP address and the maximum datagram size at startup time, and provides client authorization. This built-in negotiation allows reliable automation of the connection establishment, while the authentication removes the need for the clumsy user login accounts that SLIP requires. For each of these capabilities, PPP has a separate protocol. In this chapter, we briefly cover these basic building blocks of PPP. This discussion of PPP is far from complete; if you want to know more about PPP, we urge you to read its RFC specification and the dozen or so companion RFCs.[45] There is also a comprehensive O'Reilly book on the topic of Using & Managing PPP, by Andrew Sun.

At the very bottom of PPP is the High-Level Data Link Control (HDLC) protocol, which defines the boundaries around the individual PPP frames and provides a 16-bit checksum.[46] As opposed to the more primitive SLIP encapsulation, a PPP frame is capable of holding packets from protocols other than IP, such as Novell's IPX or Appletalk. PPP achieves this by adding a protocol field to the basic HDLC frame that identifies the type of packet carried by the frame.

The Link Control Protocol, (LCP) is used on top of HDLC to negotiate options pertaining to the data link. For instance, the Maximum Receive Unit (MRU), states the maximum datagram size that one side of the link agrees to receive.

An important step at the configuration stage of a PPP link is client authorization. Although it is not mandatory, it is really a must for dialup lines in order to keep out intruders. Usually the called host (the server) asks the client to authorize itself by proving it knows some secret key. If the caller fails to produce the correct secret, the connection is terminated. With PPP, authorization works both ways; the caller may also ask the server to authenticate itself. These authentication procedures are totally independent of each other. There are two protocols for different types of authorization, which we will discuss further in this chapter: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP).