In Chapter 5, we saw that Ethernet network interfaces come in many varieties and that different Ethernet cards usually have different interface names. You can usually determine which interface is used on a system from the messages displayed on the console during a boot. On many systems these messages can be examined with the dmesg command. The following example shows the output of the dmesg command on two different systems:

$ dmesg | grep ether
Oct  1 13:07:23 crab gld: [ID 944156 kern.info] dnet0: DNET 21x4x:
 type "ether" mac address 00:00:c0:dd:d4:da
 
$ dmesg | grep eth 
eth0: SMC EtherEZ at 0x240, 00 00 C0 9A 72 CA,assigned  IRQ 5 programmed-I/O mode.

The first dmesg command in the example shows the message displayed when an Ethernet interface is detected during the boot of a Solaris 8 system. The string type "ether" makes it clear that dnet0 is an Ethernet interface. The Ethernet address (00:00:c0:dd:d4:da) is also displayed.

The second dmesg example, which comes from a PC running Linux, provides even more information. On Linux systems, the Ethernet interface name starts with the string “eth”, so we look for a message containing that string. The message from the Linux system displays the Ethernet address (00:00:c0:9a:72:ca) and the make and model (SMC EtherEZ) of the network adapter card.

It is not always easy to determine all available interfaces on your system by looking at the output of dmesg. These messages show only the physical hardware interfaces. In the TCP/IP protocol architecture, the Network Access Layer encompasses all functions that fall below the Internet Layer. This can include all three lower layers of the OSI Reference Model: the Physical Layer, the Data Link Layer, and the Network Layer. IP needs to know the specific interface in the Network Access Layer where packets should be passed for delivery to a particular network. This interface is not limited to a physical hardware driver. It could be a software interface into the network layer of another protocol suite. So what other methods can help you determine the network interfaces available on a system? Use the netstat and the ifconfig commands. For example, to see all network interfaces that are already configured, enter:

# netstat -in
Name  Mtu  Net/Dest     Address      Ipkts Ierrs Opkts Oerrs Collis Queue
lo0   8232 127.0.0.0    127.0.0.1    4504  0     4504  0     0      0
dnet0 1500 172.16.12.0  172.16.12.1  366   0     130   0     0      0

The -i option tells netstat to display the status of all configured network interfaces, and the -n tells netstat to display its output in numeric form. In the Solaris 8 example shown above, the netstat -in command displays the following fields:

The output of a netstat -in command on a Linux system appears quite different:

$ netstat -in
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500   0  2234    280      0      0   1829      0      0      0 BRU
lo  16436   0    10      0      0      0     10      0      0      0 LRU

This output appears different, but as is often the case, appearances can fool you. Again we have the interface name, the MTU, and the packet statistics.^[51] Here RX-OK is the total number of input packets, while RX-ERR (errors), RX-DRP (drops), and RX-OVR (overruns) added together give the total number of input errors. The total number of output packets is TX-OK, and the TX-ERR, TX-DRP, and TX-OVR counters provide the total number of output errors. Only two fields, Net/Dest and Address, that are provided in the Solaris output are not provided here. On the other hand, this display has two fields not used in the Solaris output. The Met field contains the routing metric assigned to this interface. The Flg field shows the interface flags:

This display shows that this workstation has only two network interfaces. In this case it is easy to identify each network interface. The lo0 interface is the loopback interface, which every TCP/IP system has. It is the same loopback device discussed in Chapter 5. eth0 is the Ethernet interface, also discussed previously.

On most systems, the loopback interface is part of the default configuration, so you won’t need to configure it. If you do need to configure lo0 on a Solaris system, use the following command:

# ifconfig lo0 plumb 127.0.0.1 up

This example is specific to Solaris because it contains the plumb option. This option literally creates the “plumbing” required by the network interface the first time it is configured. Subsequent reconfigurations of this interface do not require the plumb option, and other systems, such as Linux, do not use this option.

The configuration of the Ethernet interface requires more attention than the loopback interface. Many systems use an installation script to install Unix. This script requests the host address, which it then uses to configure the interface. Later we’ll look at these scripts and what to do when the user does not successfully set up the interface with the installation script.

The ifconfig command can also be used to find out what network interfaces are available on a system. The netstat command shows only interfaces that are configured. On some systems the ifconfig command can be used to show all interfaces, even those that have not yet been configured. On Solaris 8 systems, ifconfig -a does this; on a Linux 2.0.0 system, entering ifconfig without any arguments will list all of the network interfaces.

While most hosts have only one real network interface, some hosts and all gateways have multiple interfaces. Sometimes all interfaces are the same type; e.g., a gateway between two Ethernets may have two Ethernet interfaces. netstat on a gateway like this might display lo0, eth0, and eth1. Deciphering a netstat display with multiple interfaces of the same type is still very simple. But deciphering a system with many different types of network interfaces is more difficult. You must rely on documentation that comes with optional software to choose the correct interface. When installing new network software, always read documentation carefully.

This long discussion about determining the network interface is not meant to overshadow the important ifconfig functions of assigning the IP address, subnet mask, and broadcast address. So let’s return to these important topics.

As noted previously, the Unix installation script configures the network interface. However, this configuration may not be exactly what you want. Check the configuration of an interface with ifconfig. To display the current values assigned to the interface, enter ifconfig with an interface name and no other arguments. For example, to check interface dnet0:

% ifconfig dnet0 
dnet0: flags=1000843<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.16.12.2 netmask ffff0000 broadcast 172.16.255.255

When used to check the status of an interface on a Solaris system, the ifconfig command displays two lines of output. The first line shows the interface name, the flags that define the interface’s characteristics, and the Maximum Transmission Unit (MTU) of this interface.^[52] In our example the interface name is dnet0, and the MTU is 1500 bytes. The flags are displayed as both a numeric value and a set of keywords.

The interface’s flags have the numeric value 1000843, which corresponds to:

The second line of ifconfig output displays information that directly relates to TCP/IP. The keyword inet is followed by the Internet address assigned to this interface. Next comes the keyword netmask, followed by the address mask written in hexadecimal. Finally, the keyword broadcast and the broadcast address are displayed.

On a Linux system the ifconfig command displays up to seven lines of information for each interface instead of the two lines displayed by the Solaris system. The additional information includes the Ethernet address, the PC IRQ, I/O Base Address and memory address, and packet statistics. The basic TCP/IP configuration information is the same on both systems.

> ifconfig eth0 
eth0  Link encap:Ethernet  HWaddr 00:00:C0:9A:D0:DB 
      inet addr:172.16.55.106  Bcast:172.16.55.255  Mask:255.255.255.0 
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
      RX packets:844886 errors:0 dropped:0 overruns:0 frame:0
      TX packets:7668 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:100
      Interrupt:11 Base address:0x7c80 Memory:c0000-c2000

Refer to the Solaris ifconfig dnet0 example at the beginning of this section, and check the information displayed in that example against the subnet configuration planned for our imaginary network. You’ll see that the interface needs to be reconfigured. The configuration done by the user during the Unix installation did not provide all of the values we planned. The address (172.16.12.2) is correct, but the address mask (ffff0000 or 255.255.0.0) and the broadcast address (172.16.0.0) are incorrect. Let’s look at the various ways values are assigned, and how to correct them.

The IP address can be assigned directly on the ifconfig command line or indirectly from a file. The ifconfig examples seen earlier in this chapter had an IP address written in standard dotted decimal notation directly on the command line. An alternative is to use a hostname from the /etc/hosts file on the ifconfig command line to provide the address. For example:

# ifconfig dnet0 crab netmask 255.255.255.0

Most administrators are very comfortable with using hostnames in place of addresses. Vendor configurations, however, tend to take address assignment to another level of indirection. The ifconfig command in the startup script references a file. The file contains a hostname and the hostname maps to an address. Solaris systems place the hostname in a file named /etc/hostname. interface, where interface is the name of the interface being configured. On our sample system the file is called /etc/hostname.dnet0. The hostname.dnet0 file created by a standard Solaris installation contains only a simple hostname:

$ cat /etc/hostname.dnet0
crab
$ grep crab /etc/hosts
172.16.12.1    crab    crab.wrotethebook.com       loghost

The example shows that the Solaris configuration created the hostname.dnet0 file and the necessary entry in the /etc/hosts file to map the name from hostname.dnet0 to an IP address. The Solaris boot first gets the hostname from a file and then gets the address associated with that hostname from a second file. Both of these entries are required for the configuration.

Linux also uses indirection for the ifconfig configuration. Several Linux systems, including Red Hat, Mandrake, and Caldera, place the values used to configure the network interface in a file named ifcfg. interface, where interface is the name of the interface.^[53]

For example, ifcfg.eth0 contains the configuration values for the Ethernet interface eth0.

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
BROADCAST=172.16.12.255
NETWORK=172.16.12.0
NETMASK=255.255.255.0
IPADDR=172.16.12.2
USERCTL=no

This file makes the configuration very easy to see.

Most systems take advantage of the fact that the IP address, subnet mask, and broadcast address can be set indirectly to reduce the extent that startup files need to be customized. Reducing customization lessens the chance that a system might hang while booting because a startup file was improperly edited, and it makes it possible to preconfigure these files for all of the systems on the network. Solaris systems have the added advantage that the hosts, networks, and netmasks files, which provide input to the ifconfig command, all produce NIS maps that can be centrally managed at sites using NIS.

A disadvantage of setting the ifconfig values indirectly is that it can make troubleshooting more cumbersome. If all values are set in the boot file, you only need to check the values there. When network configuration information is supplied indirectly, you may need to check several files to find the problem. An error in any of these files could cause an incorrect configuration. To make debugging easier, a few operating systems set the configuration values directly on the ifconfig command line in the boot file.

My advice is that you follow the standard model used on your system. If you use a Solaris system, set the address in /etc/hostname.dnet0 and /etc/hosts. If you use a Red Hat system, set the address in the /etc/sysconfig/network-scripts/ifcfg.eth0 file. If you use a Slackware system, set the address directly in the rc.inet boot file. Following the standard procedure for your system makes it easier for others to troubleshoot your computer. We’ll see more of these alternatives as we assign the remaining interface configuration values.

In order to function properly, every interface on a specific physical network segment must have the same address mask. For crab and rodent, the netmask value is 255.255.255.0 because both systems are attached to the same subnet. However, although crab’s local network interface and its external network interface are parts of the same computer, they use different netmasks because they are on different networks.

To assign an address mask, write the mask value after the keyword netmask on the ifconfig command line or as a prefix attached to the address. When written as a prefix, the address mask is a decimal number that defines the number of bits in the address mask. For example, 172.16.12.2/24 defines a 24-bit address mask. When the subnet mask follows the keyword netmask, it is usually written in the dotted decimal form used for IP addresses.^[54]

For example, the following command assigns the correct subnet mask to the dnet0 interface on rodent:

# ifconfig le0 172.16.12.2 netmask 255.255.255.0

Putting the netmask value directly on the ifconfig command line is the most common, the simplest, and the best way to assign the mask to an interface manually. But it is rare for the mask to be assigned manually. Like addresses, address masks are made part of the configuration during the initial installation. To simplify configuration, ifconfig is able to take the netmask value from a file instead of from the command line. Conceptually, this is similar to using a hostname in place of an IP address. The administrator can place the mask value in either the hosts file or the networks file and then reference it by name. For example, the books-net administrator might add the following entry to /etc/networks:

 books-mask 255.255.255.0

Once this entry has been added, you can use the name books-mask on the ifconfig command line instead of the actual mask. For example:

# ifconfig dnet0 172.16.5.2 netmask books-mask

The name books-mask resolves to 255.255.255.0, which is the correct netmask value for our sample systems.

Personally, I avoid setting the address mask value indirectly from a file that is not primarily intended for this use. The hosts file is a particularly bad choice for storing mask values. The hosts file is heavily used by other programs, and placing a mask value in this file might confuse one of these programs. Setting the address mask directly on the command line or from a file that is dedicated to this purpose is probably the best approach.

On Solaris systems, the /etc/inet/netmasks file is specifically designed to set the subnet mask.^[55] The /etc/inet/netmasks file is a table of one-line entries, each containing a network address separated from a mask by whitespace.^[56]

If a Solaris system on books-net (172.16.0.0) has an /etc/inet/netmasks file that contains the entry:

 172.16.0.0 255.255.255.0

then the following ifconfig command can be used to set the address mask:

# ifconfig dnet0 172.16.5.1 netmask +

The plus sign after the keyword netmask causes ifconfig to take the mask value from /etc/inet/netmasks. ifconfig searches the file for a network address that matches the network address of the interface being configured. It then extracts the mask associated with that address and applies it to the interface.

Most Linux systems also set the address mask indirectly from a file. The ifcfg-eth0 file shown in the previous section contains the following line:

NETMASK=255.255.255.0

This line clearly defines the netmask value that is used by the ifconfig command. To modify the address mask on this Red Hat system, edit this line in the ifcfg-eth0 file.

RFC 919, Broadcasting Internet Datagrams, clearly defines the format of a broadcast address as an address with all host bits set to 1. Since the broadcast address is so precisely defined, ifconfig is able to compute it automatically, and you should always be able to use the default. Unfortunately, the user in the example under Section 6.1.2 " used a broadcast address with all host bits set to 0 and didn’t allow the broadcast address to be set by default.

Correct this mistake by defining a broadcast address for the network device with the ifconfig command. Set the broadcast address in the ifconfig command using the keyword broadcast followed by the correct broadcast address. For example, the ifconfig command to set the broadcast address for crab’s dnet0 interface is:

# ifconfig dnet0 172.16.12.1 netmask 255.255.255.0 
               broadcast 172.16.12.255

Note that the broadcast address is relative to the local subnet. crab views this interface as connected to network 172.16.12.0; therefore, its broadcast address is 172.16.12.255. Depending on the implementation, a Unix system could interpret the address 172.16.255.255 as host address 255 on subnet 255 of network 172.16.0.0, or as the broadcast address for books-net as a whole. In neither case would it consider 172.16.255.255 the broadcast address for subnet 172.16.12.0.

Solaris systems can indirectly set the broadcast address from the netmask value defined in /etc/inet/netmasks, if that file is used. The previous section showed that netmask + takes the netmask value from a file. Likewise, the broadcast + syntax calculates the correct broadcast value using the netmask value from the netmasks file:

# ifconfig dnet0 172.16.12.1 netmask + broadcast +

Assume that the netmask defined in netmasks is 255.255.255.0. This tells the Solaris system that the first three bytes are network bytes and that the fourth byte contains the host portion of the address. Since the standard broadcast address consists of the network bits plus host bits of all 1s, Solaris can easily calculate that the broadcast address in this case is 172.16.12.255.

Linux makes it even easier. The ifcfg-eth0 file on our sample Red Hat system clearly defines the broadcast address with the line:

BROADCAST=172.16.12.255

Modify the broadcast address by modifying this line in the ifcfg-eth0 file.

We’ve used ifconfig to set the interface address, the subnet mask, and the broadcast address. These are certainly the most important functions of ifconfig, but it has other functions as well. It can enable or disable the address resolution protocol and the interface itself. ifconfig can set the routing metric used by the Routing Information Protocol (RIP) and the maximum transmission unit (MTU) used by the interface. We’ll look at examples of each of these functions.

# ifconfig eth0 down
# ifconfig eth0 172.16.1.2 up

$ ifconfig eth0 promisc

% netstat -in 
Name Mtu  Net/Dest    Address     Ipkts  Ierrs Opkts Oerrs Collis Queue 
le0  1500 172.16.12.0 172.16.12.1 1125826 16   569786  0    8914   0
lo0  1536 127.0.0.0   127.0.0.1   94280   0    94280   0    0      0

# ifconfig std0 10.104.0.19 metric 3

# ifconfig eth0 192.168.0.4 metric 3
SIOCSIFMETRIC: Operation not supported

# ifconfig fddi0 172.16.16.1 netmask 255.255.255.0 mtu 1500

# ifconfig zs0 172.16.62.1 172.16.62.2

$ ifconfig sl0 172.16.62.1 point-to-point 172.16.62.2

ifconfig eth0 172.16.12.1 broadcast 172.16.12.255 netmask 255.255.255.0

Serial Line IP was created first. It is a minimal protocol that allows isolated hosts to link via TCP/IP over the telephone network. The SLIP protocol defines a simple mechanism for framing datagrams for transmission across serial lines. SLIP sends the datagram across the serial line as a series of bytes, and it uses special characters to mark when a series of bytes should be grouped together as a datagram. SLIP defines two special characters for this purpose:

SLIP is described in RFC 1055, A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP. As the name of the RFC makes clear, SLIP is not an Internet standard. The RFC does not propose a standard; it documents an existing protocol. The RFC identifies the deficiencies in SLIP, which fall into two categories:

To address SLIP’s weaknesses, Point-to-Point Protocol (PPP) was developed as an Internet standard. There are several RFCs that document Point-to-Point Protocol.^[60] Two key documents are RFC 1661, The Point-to-Point Protocol (PPP), and RFC 1172, The Point-to-Point Protocol (PPP) Initial Configuration Options.

PPP addresses the weaknesses of SLIP with a three-layered protocol:

Point-to-Point Protocol is the best TCP/IP serial protocol. PPP is preferred because it is an Internet standard, which ensures interoperability between systems from a wide variety of vendors. It has more features than SLIP and is more robust. These benefits make PPP the best choice as an open protocol for connecting routers over serial lines and for connecting remote computers via dial-up lines.

Some Linux systems include both SLIP and PPP. However, on most Unix systems, such as Solaris, PPP is included and SLIP is not. This is fine, as you should avoid using SLIP and use PPP instead.

Point-to-Point Protocol is implemented on the Linux system in the PPP daemon (pppd), which was derived from a freeware PPP implementation for BSD systems. pppd can be configured to run in all modes: as a client, as a server, over dial-up connections, and over dedicated connections. (Clients and servers are familiar concepts from Chapter 3.) A dedicated connection is a direct cable connection or a leased line, neither of which requires a telephone to establish the connection. A dial-up connection is a modem link established by dialing a telephone number.

Configuring pppd for a dedicated line is the simplest configuration. A dial-up script is not needed for a leased line or direct connection. There is no point in dynamically assigning addresses because a dedicated line always connects the same two systems. Authentication is of limited use because the dedicated line physically runs between two points. There is no way for an intruder to access the link, short of “breaking and entering” or a wiretap. A single pppd command placed in a startup file configures a dedicated PPP link for our Linux system:

pppd /dev/cua3 56000 crtscts defaultroute

The /dev/cua3 argument selects the device to which PPP is attached. It is, of course, the same port to which the dedicated line is attached. Next, the line speed is specified in bits per second (56000). The remainder of the command line is a series of keyword options. The crtscts option turns on hardware flow control. The final option, defaultroute , creates a default route using the remote server as the default gateway.^[62]

PPP exchanges IP addresses during the initial link connection process. If no address is specified on the pppd command line, the daemon sends the address of the local host, which it learns from DNS or the host table, to the remote host. Likewise, the remote system sends its address to the local host. The addresses are then used as the source and destination addresses of the link. You can override this by specifying the addresses on the command line in the form local-address : remote-address. For example:

 pppd /dev/cua3 56000 crtscts defaultroute 172.16.24.1:

Here we define the local address as 172.16.24.1 and leave the remote address blank. In this case pppd sends the address from the command line and waits for the remote server to send its address. The local address is specified on the command line when it is different from the address associated with the local hostname in the host table or the DNS server. For example, the system might have an Ethernet interface that already has an address assigned. If we want to use a different address for the PPP connection, we must specify it on the pppd command line; otherwise, the PPP link will be assigned the same address as the Ethernet interface.

The pppd command has many more options than those used in these examples (see Appendix A for a full list of options). In fact, there are so many pppd command-line options that it is sometimes easier to put them in a file than to enter them all on the command line. pppd reads its options from the /etc/ppp/options file, then the ~/.ppprc file, then the /etc/ppp/options.device file (where device is a device name like cua3), and finally from the command line. The order in which they are processed creates a hierarchy such that options on the command line can override those in the ~/.ppprc file, which can in turn override those in the /etc/ppp/options file. This permits the system administrator to establish certain systemwide defaults in the /etc/ppp/options file while still permitting the end user to customize the PPP configuration. The /etc/ppp/options file is a convenient and flexible way to pass parameters to pppd.

A single pppd command is all that is needed to set up and configure the software for a dedicated PPP link. Dial-up connections are more challenging.

A direct-connect cable can connect just two systems. When a third system is purchased, it cannot be added to the network. For that reason, most people use expandable network technologies, such as Ethernet, for connecting systems in a local area. Additionally, leased lines are expensive. They are primarily used by large organizations to connect networks of systems. For these reasons, using PPP for dedicated network connections is less common than using it for dial-up connections.

Several different utilities provide dial-up support for PPP. Dial-up IP (dip ) is a popular package for simplifying the process of dialing the remote server, performing the login, and attaching PPP to the resulting connection. We discuss dip in this section because it is popular and freely available for a wide variety of Unix systems, and because it comes with Red Hat Linux, which is the system we have been using for our PPP examples.

One of the most important features of dip is a scripting language that lets you automate all the steps necessary to set up an operational PPP link. Appendix A covers all the scripting commands supported by the 3.3.7o-uri version of dip, which is the version included with Red Hat. You can list the commands supported by your system by running dip in test mode (-t) and then entering the help command:

> dip -t 
DIP: Dialup IP Protocol Driver version 3.3.7o-uri (8 Feb 96) 
Written by Fred N. van Kempen, MicroWalt Corporation. 
 
DIP> help 
DIP knows about the following commands: 
 
        beep     bootp    break    chatkey  config    
        databits dec      default  dial     echo      
        flush    get      goto     help     if        
        inc      init     mode     modem    netmask   
        onexit   parity   password proxyarp print     
        psend    port     quit     reset    send      
        shell    sleep    speed    stopbits term      
        timeout  wait      
 DIP> quit

These commands can configure the interface, control the execution of the script, and process errors. Only a subset of the commands is required for a minimal script:

# Ask PPP to provide the local IP address 
get $local 0.0.0.0 
# Select the port and set the line speed 
port cua1 
speed 38400 
# Reset the modem and flush the terminal 
reset 
flush 
# Dial the PPP server and wait for the CONNECT response 
dial *70,301-555-1234 
wait CONNECT 
# Give the server 2 seconds to get ready 
sleep 2 
# Send a carriage-return to wake up the server 
send \r 
# Wait for the Login> prompt and send the username 
wait ogin> 
send kristin\r 
# Wait for the Password> prompt and send the password 
wait word> 
password 
# Wait for the PPP server's command-line prompt 
wait > 
# Send the command required by the PPP server 
send ppp enabled\r 
# Set the interface to PPP mode 
mode PPP 
# Exit the script 
exit

The get command at the beginning of the script allows PPP to provide the local and remote addresses. $local is a script variable. There are several available script variables, all of which are covered in Appendix A. $local normally stores the local address, which can be set statically in the script. A PPP server, however, is capable of assigning an address to the local system dynamically. We take advantage of this capability by giving a local address of all 0s. This peculiar syntax tells dip to let pppd handle the address assignments. A pppd client can get addresses in three ways:

The next two lines select the physical device to which the modem is connected, and set the speed at which the device operates. The port command assumes the path /dev, so the full device path is not used. On most PC Unix systems, the value provided to the port command is cua0, cua1, cua2, or cua3. These values correspond to MS-DOS ports COM1 to COM4. The speed command sets the maximum speed used to send data to the modem on this port. The default speed is 38400. Change it if your modem accepts data at a different speed.

The reset command resets the modem by sending it the Hayes modem interrupt (+++) followed by the Hayes modem reset command (ATZ). This version of dip uses the Hayes modem AT command set and works only with Hayes-compatible modems.^[63] Fortunately, that includes most brands of modems. After being reset, the modem responds with a message indicating that the modem is ready to accept input. The flush command removes this message, and any others that might have been displayed by the modem, from the input queue. Use flush to avoid the problems that can be caused by unexpected data in the queue.

The next command dials the remote server. The dial command sends a standard Hayes ATD dial command to the modem. It passes the entire string provided on the command line to the modem as part of the ATD command. The sample dial command generates ATD*70,301-555-1234. This causes the modem to dial *70 (which turns off call waiting^[64]), and then area code 301, exchange 555, and number 1234.When this modem successfully connects to the remote modem, it displays the message CONNECT. The wait command waits for that message from the modem.

The sleep 2 command inserts a two-second delay into the script. It is often useful to delay at the beginning of the connection to allow the remote server to initialize. Remember that the CONNECT message is displayed by the modem, not by the remote server. The remote server may have several steps to execute before it is ready to accept input. A small delay can sometimes avoid unexplained intermittent problems.

The send command sends a carriage return (\r) to the remote system. Once the modems are connected, anything sent from the local system goes all the way to the remote system. The send command can send any string. In the sample script, the remote server requires a carriage return before it issues its first prompt. The carriage return is entered as \r and the newline is entered as \n.

The remote server then prompts for the username with Login>. The wait ogin> command detects this prompt, and the send kristin command sends the username kristin as a response. The server then prompts for the password with Password>. The password command causes the script to prompt the local user to manually enter the password. It is possible to store the password in a send command inside the script. However, this is a potential security problem if an unauthorized person gains access to the script and reads the password. The password command improves security.

If the password is accepted, our remote server prompts for input with the greater-than symbol (>). Many servers require a command to set the correct protocol mode. The server in our example supports several different protocols. We must tell it to use PPP by using send to pass it the correct command.

The script finishes with a few commands that set the correct environment on the local host. The mode command tells the local host to use the PPP protocol on this link. The protocol selected must match the protocol running on the remote server. Protocol values that are valid for the dip mode command are SLIP, CSLIP, PPP, and TERM. SLIP and CSLIP are variations of the SLIP protocol, which was discussed earlier. TERM is terminal emulation mode. PPP is the Point-to-Point Protocol. Finally, the exit command ends the script, while dip keeps running in the background servicing the link.

This simple script does work and it should give you a good idea of the wait/send structure of a dip script. However, your scripts will probably be more complicated. The sample script is not robust because it does not do any error checking. If an expected response does not materialize, the sample script hangs. To address this problem, use a timeout on each wait command. For example, the wait OK 10 command tells the system to wait 10 seconds for the OK response. When the OK response is detected, the $errlvl script variable is set to zero and the script falls through to the next command. If the OK response is not returned before the 10-second timer expires, $errlvl is set to a nonzero value and the script continues on to the next command. The $errlvl variable is combined with the if and goto commands to provide error handling in dip scripts. Refer to Appendix A for more details.

Once the script is created, it is executed with the dip command. Assume that the sample script shown above was saved to a file named start-ppp.dip. The following command executes the script, creating a PPP link between the local system and the remote server:

> dip start-ppp

Terminate the PPP connection with the command dip -k. This closes the connection and kills the background dip process.

pppd options are not configured in the dip script. dip creates the PPP connection; it doesn’t customize pppd. pppd options are stored in the /etc/ppp/options file.

Assuming the dip script shown above, we might use the following pppd options:

noipdefault 
ipcp-accept-local 
ipcp-accept-remote defaultroute

The noipdefault option tells the client not to look up the local address. ipcp-accept-local tells the client to obtain its local address from the remote server. The ipcp-accept-remote option tells the system to accept the remote address from the remote server. Finally, pppd sets the PPP link as the default route. This is the same defaultroute option we saw on the pppd command line in an earlier example. Any pppd option that can be invoked on the command line can be put in the /etc/ppp/options file and thus be invoked when pppd is started by a dip script.

I use dip on my home computer to set up my dial-up PPP connection.^[65] Personally, I find dip simple and straightforward to use, in part because I am familiar with the dip scripting language. You may prefer to use the chat command that comes with the pppd software package.

A chat script is a simple expect/send script consisting of the strings the system expects and the strings it sends in response. The script is organized as a list of expect/send pairs. chat does not really have a scripting language, but it does have some special characters that can be used to create more complex scripts. The chat script to perform the same dial-up and login functions as the sample dip script would contain:

'' ATZ 
OK ATDT*70,301-555-1234 
CONNECT \d\d\r 
ogin> kristin 
word> Wats?Wat?
> 'set port ppp enabled'

Each line in the script begins with an expected string and ends with the string sent as a response. The modem does not send a string until it receives a command. The first line in the script says, in effect, “expect nothing and send the modem a reset command.” The pair of single quotes ('') at the beginning of the line tells chat to expect nothing. The script then waits for the modem’s OK prompt and dials the remote server. When the modem displays the CONNECT message, the script delays two seconds (\d\d) and then sends a carriage return (\r). Each \d special character causes a one-second delay. The \r special character is the carriage return. chat has many special characters that can be used in the expect strings and the send strings.^[66] Finally, the script ends by sending the username, password, and remote server configuration command in response to the server’s prompts.

Create the script with your favorite editor and save it in a file such as dial-server. Test the script using chat with the -V option, which logs the script execution through stderr:

% chat -V -f dial-server

Invoking the chat script is not sufficient to configure the PPP line. It must be combined with pppd to do the whole job. The connect command-line option allows you to start pppd and invoke a dial-up script all in one command:

# pppd /dev/cua1 56700 connect "chat -V -f dial-server" \
                    nodetach crtscts modem defaultroute

The chat command following the connect option is used to perform the dial-up and login. Any package capable of doing the job could be called here; it doesn’t have to be chat.

The pppd command has some other options that are used when PPP is run as a dial-up client. The modem option causes pppd to monitor the carrier-detect (DCD) indicator of the modem. This indicator tells pppd when the connection is made and when the connection is broken. pppd monitors DCD to know when the remote server hangs up the line. The nodetach option prevents pppd from detaching from the terminal to run as a background process. This is necessary only when running chat with the -V option. When you are done debugging the chat script, you can remove the -V option from the chat subcommand and the nodetach option from the pppd command. An alternative is to use -v on the chat command. -v does not require pppd to remain attached to a terminal because it sends the chat logging information to syslogd instead of to stderr. We have seen all of the other options on this command line before.

A major benefit of PPP over SLIP is the enhanced security PPP provides. Put the following pppd options in the /etc/ppp/options file to enhance security:

lock 
auth 
usehostname domain wrotethebook.com

The first option, lock, makes pppd use UUCP-style lock files. This prevents other applications, such as UUCP or a terminal emulator, from interfering with the PPP connection. The auth option requires the remote system to be authenticated before the PPP link is established. This option causes the local system to request authentication data from the remote system. It does not cause the remote system to request similar data from the local system. If the remote system administrator wants to authenticate your system before allowing a connection, she must put the auth keyword in the configuration of her system. The usehostname option requires that the hostname is used in the authentication process and prevents the user from setting an arbitrary name for the local system with the name option. (More on authentication in a minute.) The final option makes sure that the local hostname is fully qualified with the specified domain before it is used in any authentication procedure.

Recall that the ~/.ppprc file and the pppd command-line options can override options set in the /etc/ppp/options file, which could be a security problem. For this reason, several options, once configured in the /etc/ppp/options file, cannot be overridden. That includes the options just listed.

pppd supports two authentication protocols: Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). PAP is a simple password security system that is vulnerable to all of the attacks of any reusable password system. CHAP, however, is an advanced authentication system that does not use reusable passwords and that repeatedly reauthenticates the remote system.

Two files are used in the authentication process, the /etc/ppp/chap-secrets file and the /etc/ppp/pap-secrets file. Given the options file shown above, pppd first attempts to authenticate the remote system with CHAP. To do this, there must be data in the chap-secrets file, and the remote system must respond to the CHAP challenge. If either of these conditions is not true, pppd attempts to authenticate the remote system with PAP. If there is no applicable entry in the pap-secrets file or the remote system does not respond to the PAP challenge, the PPP connection is not established. This process allows you to authenticate remote systems with CHAP (the preferred protocol), if they support it, and to fall back to PAP for systems that support only PAP. For this to work, however, you must have the correct entries in both files.

Each entry in the chap-secrets file contains up to four fields:

A sample chap-secrets file for the host ring might contain:

limulus     ring        Peopledon'tknowyou    172.16.15.3
ring        limulus     andtrustisajoke.      172.16.15.1

The first entry is used to validate limulus, the remote PPP server. limulus is being authenticated and the system performing the authentication is ring. The secret key is “Peopledon’tknowyou”. The allowable address is 172.16.15.3, which is the address assigned to limulus in the host table. The second entry is used to validate ring when limulus issues the challenge. The secret key is “andtrustisajoke.”. The only address ring is allowed to use is 172.16.15.1. A pair of entries, one for each end of the link, is normal. The chap-secret file usually contains two entries for every PPP link: one for validating the remote system and one for answering the challenge of that remote system.

Use PAP only when you must. If you deal with a system that does not support CHAP, make an entry for that system in the pap-secrets file. The format of pap-secrets entries is the same as those used in the chap-secrets file. A system that does not support CHAP might have the following entry in the pap-secrets file:

24seven  ring       Wherearethestrong?  24seven.wrotethebook.com
ring     24seven    Whoarethetrusted?   ring.wrotethebook.com

Again we have a pair of entries: one for the remote system and one for our system. We support CHAP but the remote system does not. Thus we must be able to respond using the PAP protocol in case the remote system requests authentication.

PPP authentication improves security in a dial-up environment. It is most important when you run the PPP server into which remote systems dial. In the next section, we look at PPP server configuration.

The PPP server can be started in several different ways. One way is to use pppd as a login shell for dial-in PPP users. Replace the login shell entry in the /etc/passwd file with the path of pppd to start the server. A modified /etc/passwd entry might contain:

 craig:wJxX.iPuPzg:101:100:Craig Hunt:/etc/ppp:/usr/sbin/pppd

The fields are exactly the same as in any /etc/passwd entry: username, password, uid, gid, gcos information, home directory, and login shell. For a remote PPP user, the home directory is /etc/ppp and the login shell is the full path of the pppd program. The encrypted password must be set using the passwd program, just as for any user, and the login process is the same as it is for any user. When getty detects incoming traffic on the serial port it invokes login to authenticate the user. login verifies the username and the password entered by the user and starts the login shell. In this case, the login shell is actually the PPP daemon.

When the server is started in this manner, server options are generally placed in the /etc/ppp/.ppprc file. login validates the user, and pppd authenticates the client. Therefore the chap-secrets or pap-secrets file must be set up to handle the client system from which this user logs in.

A traditional alternative to using pppd as the login script is to create a real script in which pppd is only one of the commands. For example, you might create an /etc/ppp/ppplogin script such as the following:

#!/bin/sh 
mesg -n 
stty -echo
exec /sbin/pppd auth passive crtscts modem

You can see that the script can contain more than just the pppd command. The mesg -n command makes sure that other users cannot write to this terminal with talk, write, or similar programs. The stty command turns off character echoing. On some systems, characters typed at the terminal are echoed from the remote host instead of being locally echoed by the terminal; this behavior is called full duplex. We don’t want to echo anything back on a PPP link, so we turn full duplex off. Controlling the characteristics of the physical line is the main reason that pppd is often placed inside a script file.

The key line in the script is, of course, the line that starts pppd. We start the daemon with several options, but one thing that is not included on the command line is the tty device name. In all of the previous pppd examples, we provided a device name. When it is not provided, as is this case, pppd uses the controlling terminal as its device and doesn’t put itself in background mode. This is just what we want. We want to use the device that login was servicing when it invoked the ppplogin script.

The auth command-line option tells pppd to authenticate the remote system, which of course requires us to place an entry for that system in the chap-secrets or the pap-secrets file. The crtscts option turns on hardware flow control, and the modem option tells PPP to monitor the modem’s DCD indicator so that it can detect when the remote system drops the line. We have seen all of these options before. The one new option is passive. With passive set, the local system waits until it receives a valid LCP packet from the remote system, even if the remote system fails to respond to its first packet. Normally, the local system would drop the connection if the remote system fails to respond in a timely manner. This option gives the remote system time to initialize its own PPP daemon.

A final option for running PPP as a server is to allow the user to start the server from the shell prompt. To do this, pppd must be installed as setuid root, which is not the default installation. Once pppd is setuid root, a user with a standard login account can log in and then issue the following command:

$ pppd proxyarp

This command starts the PPP daemon. Assuming that the auth parameter is set in the /etc/ppp/options file, pppd authenticates the remote client using CHAP or PAP. Once the client is authenticated, a proxy ARP entry for the client is placed in the server’s ARP table so that the client appears to other systems to be located on the local network.

Of these three approaches, I prefer to create a shell script that is invoked by login as the user’s login shell. With this approach, I don’t have to install pppd setuid root. I don’t have to place the burden of running pppd on the user. And I get all the power of the pppd command plus all the power of a shell script.

dip and pppd are available for Linux, BSD, AIX, Ultrix, OSF/1, and SunOS. If you have a different operating system, you probably won’t use these packages. Solaris is a good example of a system that uses a different set of commands to configure PPP.

PPP is implemented under Solaris as the Asynchronous PPP Daemon (aspppd). aspppd is configured by the /etc/asppp.cf file. The asppp.cf file is divided into two sections: an ifconfig section and a path section.

ifconfig ipdptp0 plumb ring limulus up 
 
path 
   interface ipdptp0 
   peer_system_name limulus    inactivity_timeout 300

The ifconfig command configures the PPP interface (ipdptp0) as a point-to-point link with a local address of ring and a destination address of limulus. The ifconfig command does not have to define the destination address of the link. However, if you always connect to the same remote server, it will probably be defined here as the destination address. We saw all of these options in the discussion of the ifconfig command earlier in this chapter.

The more interesting part of this file is the path section, which defines the PPP environment. The interface statement identifies the interface used for the connection. It must be one of the PPP interfaces defined in the ifconfig section. In the example, only one is defined, so it must be ipdptp0. The peer_system_name statement identifies the system at the remote end of the connection. This may be the same address as the destination address from the ifconfig statement, but it doesn’t have to be. It is possible to have no destination address on the ifconfig command and several path sections if you connect to several different remote hosts. The hostname on the peer_system_name statement is used in the dialing process, as described later.

The path section ends with an inactivity_timeout statement. The command in the sample sets the timeout to 300 seconds. This points out a nice feature of the Solaris system. Solaris automatically dials the remote system when it detects data that needs to be delivered through that system. Further, it automatically disconnects the PPP link when it is inactive for the specified time. With this feature you can use a PPP link without manually initiating the dial program and without tying up phone lines when the link is not in use.

Like pppd, aspppd does not have a built-in dial facility. It relies on an external program to do the dialing. In the case of aspppd, it utilizes the dial-up facility that comes with UUCP. Here’s how.

First, the serial port, the modem attached to it, and the speed at which they operate are defined in the /etc/uucp/Devices file. For example, here we define an Automatic Call Unit (ACU is another name for a modem) attached to serial port B (cua/b) that operates at any speed defined in the Systems file, and that has the modem characteristics defined by the “hayes” entry in the Dialers file:

ACU cua/b - Any hayes

Next, the modem characteristics, such as its initialization setting and dial command, are defined in the /etc/uucp/Dialers file. The initialization and dial commands are defined as a chat script using the standard expect/send format and the standard set of chat special characters. For example:

hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT

The system comes with Devices and Dialers preconfigured. The preconfigured entries are probably compatible with the modem on your system. The /etc/uucp/Systems file may be the only configuration file that you modify. In the Systems file, you need to enter the name of the remote system, select the modem you’ll use, enter the telephone number, and enter a chat script to handle the login. For example:

limulus Any ACU 56700 5551234 "" \r ogin> kristin word> Wats?Watt? >      set ppp on

In this one line, we identify limulus as the remote system, declare that we allow connections to and from that host at any time of the day (Any), select the ACU entry in the Devices file to specify the port and modem, set the line speed to 56700, send the dialer the telephone number, and define the login chat script.

This is not a book about UUCP, so we won’t go into further details about these files. I’d suggest looking at the Solaris AnswerBook and the Solaris TCP/IP Network Administration Guide (where did they come up with such a great name?) for more information about UUCP and aspppd.

There are several layers of complexity that make PPP connections difficult to debug. To set up PPP, we must set up the serial port, configure the modem, configure PPP, and configure TCP/IP. A mistake in any one of these layers can cause a problem in another layer. All of these layers can obscure the true cause of a problem. The best way to approach troubleshooting on a serial line is by debugging each layer, one layer at a time. It is usually best to troubleshoot each layer before you move on to configure the next layer.

The physical serial ports should be configured by the system during the system boot. Check the /dev directory to make sure they are configured. On a Linux system with four serial ports, the inbound serial ports are /dev/ttyS0 through /dev/ttyS3 and the outbound serial ports are /dev/cua0 through /dev/cua3. There are many more tty and cua device names. However, the other devices are associated with real physical devices only if you have a multi-port serial card installed in your Linux system. Most Unix systems use the names tty and cua, even if those names are just symbolic links to the real devices. Solaris is a good example:

% ls -l /dev/tty? 
lrwxrwxrwx 1 root root 6 Sep 23  2001 /dev/ttya -> term/a 
lrwxrwxrwx 1 root root 6 Sep 23  2001 /dev/ttyb -> term/b 
% ls -l /dev/cua/* 
lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/a -> 
     /devices/obio/zs@0,100000:a,cu 
lrwxrwxrwx 1 root root 35 Sep 23 2001 /dev/cua/b ->   /devices/obio/zs@0,100000:b,cu

If the serial devices do not show up in the /dev directory, they can be manually added with a mknod command. For example, the following commands create the serial devices for the first serial port on a Linux system:

# mknod -m 666 /dev/cua0 c 5 64
# mknod -m 666 /dev/ttyS0 c 4 64

However, if you need to add the serial devices manually, there may be a problem with the kernel configuration. The serial devices should be installed in your system by default during the boot when the hardware is detected. The following boot message shows the detection of a single serial interface on a Linux system:

$ dmesg | grep tty
ttyS00 at 0x03f8 (irq = 4) is a 16550

You should see similar messages from your system boot for each interface that is detected. If you don’t, you may have a hardware problem with the serial interface board.

The modem used for the connection is attached to one of the serial ports. Before attempting to build a dial-up script, make sure the modem works and that you can communicate with it through the port. Use a simple serial communications package, such as minicom, kermit, or seyon. First, make sure the program is configured to use your modem. It must be set to the correct port, speed, parity, number of databits, etc. Check your modem’s documentation to determine these settings.

We’ll use minicom on a Linux system for our examples. To configure minicom , su to root and run it with the -s option, which displays a configuration menu. Walk through the menu and make sure everything is properly set. One thing you might notice is that the port is set to /dev/modem. That device name is sometimes symbolically linked to the port to which the modem is connected. If you’re not sure that the link exists on your system, enter the correct port name in the minicom configuration, e.g., /dev/cua1. After checking the configuration, exit the menu and use the minicom terminal emulator to make sure you can communicate with the modem:

Welcome to minicom 1.83.1

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Feb 23 2001, 07:31:40.

Press CTRL-A Z for help on special keys

AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
OK 
atz                                                  
OK                                                    
atdt555-1234                                          
CONNECT 26400/LAPM-V 
^M                                  
Enter login> kristin 
Enter user password> Wats?Watt? 
 
   Welcome to the PPP MODEM POOL 
 
PORT-9> set port ppp enabled  
+++ 
OK 
ath 
OK 
atz 
OK 
^A 
CTRL-A Z for help | 57600 8N1 | NOR | Minicom 1.83.1 | VT102 | Offline
X

In the sample, minicom displays a few header lines and then sends a Hayes command (AT) to the modem. We didn’t set this command; it was part of the default minicom configuration. (If it causes problems, edit it out of the configuration using the menus discussed previously.) We then reset the modem (atz) and dial the remote server (atdt). When the modems connect, we log into the server and configure it. (The login process is different for every remote server; this is just an example.) Everything appears to be running fine, so we end the connection by getting the modem’s attention (+++), hanging up the line (ath), and resetting the modem. Exit minicom by pressing Ctrl-A followed by X. On our sample system the port and modem are working. If you cannot send simple commands to your modem, ensure that:

When the modem responds to simple commands, use it to dial the remote server as we did in the example above. If the modem fails to dial the number or displays the message NO DIALTONE, check that the telephone line is connected to the correct port of the modem and to the wall jack. You may need to use an analog phone to test the telephone wall jack and replace the line between the modem and the wall to make sure that the cable is good. If the modem dials but fails to successfully connect to the remote modem, check that the local modem configuration matches the configuration required by the remote system. You must know the requirements of that remote system to successfully debug a connection. See the following list of script debugging tips for some hints on what to check. If you can successfully connect to the remote system, note everything you entered to do so, and note everything that the modem and the remote server display. Then set the remote server to PPP or SLIP mode and note how you accomplished this. You will need to duplicate all of these steps in your dip script.

Start with a bare-bones script, like the sample start-ppp.dip script, so that you can debug the basic connection before adding the complexity of error processing to the script. Run the script through dip using the verbose option (-v) option. This displays each line of the script as it is processed. Look for the following problems:

If you have trouble with the script, try running dip in test mode (-t), which allows you to enter each command manually one at a time. Do this repeatedly until you are positive that you know all the commands needed to log into the remote server. Then go back to debugging the script. You’ll probably have fresh insight into the login process that will help you find the flaw in the script.

Once the script is running and the connection is successfully made, things should run smoothly. You should be able to ping the remote server without difficulty. If you have problems, they may be in the IP interface configuration or in the default route. The script should have created the serial interface. The netstat -ni command shows which interfaces have been configured:

# netstat -ni 
Name  Mtu  Net/Dest     Address     Ipkts Ierrs Opkts Oerrs Collis Queue 
dnet0 1500 172.16.15.0  172.16.15.1      1     0    4     0      0     0 
lo0   1536 127.0.0.0    127.0.0.1     1712     0 1712     0      0     0 
ppp0  1006 172.16.15.26 172.16.15.3      0     0    0     0      0     0

The interface, ppp0 in the example, has been installed. The default command in the script creates a default route. Use netstat to see the contents of the routing table:

# netstat -nr 
Routing tables 
Destination      Gateway          Flags  Refcnt  Use Interface 
127.0.0.1        127.0.0.1           UH      1    28      lo0 
default          172.16.25.3          U      0     0      ppp0
172.16.15.0      172.16.15.1          U      21 1687      le0

The contents of routing tables are explained in detail in the next chapter. For now, just notice that the interface used for the default route is ppp0 and that the default route is a route to the remote PPP server (172.16.25.3 in the example).

If the script creates the connection, the interface is installed, and the routing table contains the default route, everything should work fine. If you still have problems they may be related to other parts of the TCP/IP installation. Refer to Chapter 13 for more troubleshooting information.