by Tim Parker

IN THIS CHAPTER

• What Is TCP/IP?

• Hardware Requirements

• Configuring Linux Files

• Testing and Troubleshooting

• SLIP Connections

• Setting Up PPP

In this chapter, you will look at the world of networking. In particular, you will learn the following:

• What is TCP/IP?

• How do you set up Linux to use TCP/IP and Ethernet?

• What changes to your configuration files are necessary?

• How can you test and troubleshoot Ethernet connections?

• What is necessary for a SLIP and PPP connection?

Linux offers a complete implementation of TCP/IP (Transmission Control Protocol/Internet Protocol), the protocol used extensively on the Internet and that is commonly found in local area networks involving UNIX machines. All you need to create a network, or to add your existing machine to a TCP/IP network, is a network card and some modifications to files already on your Linux system.

Whether you are setting up two machines in your room to talk to each other, or adding your Linux machine to an existing network of 5,000 workstations, the process is the same.

TCP/IP is an open networking protocol, which simply means that the technical description of all aspects of the protocol have been published. They are available for anyone to implement on their hardware and software. This open nature has helped make TCP/IP very popular. Versions of TCP/IP are now available for practically every hardware and software platform in existence, which has helped make TCP/IP the most widely used networking protocol in the world. The advantage of TCP/IP for a network operating system is simple: Interconnectivity is possible for any type of operating system and hardware platform that you might want to add.

TCP/IP is not a single protocol, but a set of over a dozen protocols. Each protocol within the TCP/IP family is dedicated to a different task. All the protocols that make up TCP/IP use the primary components of TCP/IP to send packets of data.

Transmission Control Protocol and Internet Protocol are two of the primary protocols in the TCP/IP family. The different protocols and services that make up the TCP/IP family can be grouped according to their purposes. The groups and their protocols are the following:

Transport: These protocols control the movement of data between two machines. TCP (Transmission Control Protocol): A connection-based service, meaning that the sending and receiving machines communicate with each other at all times.

UDP (User Datagram Protocol): A connectionless service, meaning that the two machines don't communicate with each other through a constant connection.

Routing: These protocols handle the addressing of the data and determine the best routing to the destination. They also handle the way large messages are broken up and reassembled at the destination. IP (Internet Protocol): Handles the actual transmission of data.

ICMP (Internet Control Message Protocol): Handles status messages for IP, such as errors and network changes that can affect routing.

RIP (Routing Information Protocol): One of several protocols that determine the best routing method.

OSPF (Open Shortest Path First): An alternative protocol for determining routing.

Network Addresses: These services handle the way machines are addressed, both by a unique number and a more common symbolic name. ARP (Address Resolution Protocol): Determines the unique numeric addresses of machines on the network.

DNS (Domain Name System): Determines numeric addresses from machine names.

RARP (Reverse Address Resolution Protocol): Determines addresses of machines on the network, but in a manner opposite of ARP.

BOOTP (Boot Protocol): This starts up a network machine by reading the boot information from a server. BOOTP is commonly used for diskless workstations.

User Services: These are applications users have access to. FTP (File Transfer Protocol): This transfers files from one machine to another without excessive overhead. FTP uses TCP as the transport.

TFTP (Trivial File Transfer Protocol): A simple file transfer method that uses UDP as the transport.

TELNET: Allows remote logins so that a user on one machine can connect to another machine and behave as though they are sitting at the remote machine's keyboard.

Gateway Protocols: These services help the network communicate routing and status information, as well as handle data for local networks. EGP (Exterior Gateway Protocol): Transfers routing information for external networks.

GGP (Gateway-to-Gateway Protocol): Transfers routing information between Internet gateways.

IGP (Interior Gateway Protocol): Transfers routing information for internal networks.

Others: These are services that don't fall into the categories just mentioned but that provide important services over a network. NFS (Network File System): Allows directories on one machine to be mounted on another, then accessed by users as though the directories were on the local machine.

NIS (Network Information Service): Maintains user accounts across networks, simplifying logins and password maintenance.

RPC (Remote Procedure Call): Allows remote applications to communicate with each other using function calls.

SMTP (Simple Mail Transfer Protocol): A protocol for transferring electronic mail between machines.

SNMP (Simple Network Management Protocol): Used to obtain status messages about TCP/IP configurations and software. It requires a loopback to be in place for proper operation.

If you want to connect your Linux machine to a network, you need a network card. Linux uses Ethernet, a network system that was designed to provide TCP/IP support. A term you'll see often is packet, which is the bundle of data and routing instructions that is assembled by TCP/IP and Ethernet to be sent over the network cables. All messages are broken into packets, then reassembled properly at the destination.

All the TCP/IP protocol definitions are maintained by a standards body that is part of the Internet organization. Although changes to the protocols occasionally occur when new features or better methods of performing older functions are developed, the new versions are almost always backward-compatible.

Linux requires an Ethernet card that is compatible with one of the network cards in the following list: 3Com 3C505

3Com 3C503/16

Novell NE1000

Novell NE2000

Western Digital WD8003

Western Digital WD8013

Hewlett-Packard HP27245

Hewlett-Packard HP27247

Hewlett-Packard HP27250

Most Ethernet cards available today are compatible with one of these cards, but you should carefully check the documentation with the card to ensure that you don't buy a network card that won't work properly.

If you plan to do your networking over the telephone (using a serial port and a modem), you don't need a network card, but you will need a fast modem compatible with the service you are planning to use. For example, to use SLIP (Serial Line Interface Protocol), you generally need a modem supporting at least V.32bis speeds (14.4kbps).

Let's assume you have a typical PC and an Ethernet card, and you want to set up your machine to run TCP/IP over the network. In most cases, the procedure described next will work. However, because there are many versions of Linux, many potential conflicts with other cards and software, and unique software requirements for some systems, this should be considered only a guide.

If, after following these instructions, your TCP/IP network doesn't work properly, it's time to carefully scan all the configuration files and error messages for a clue to the problem. Also, don't forget about the Linux Usenet newsgroups, Linux User Groups, and other sources of information about Linux from which you can get help.

To configure the TCP/IP files, you must have installed the networking software on your system. If you haven't installed the networking portions of the distribution, you must do so before proceeding. Your kernel must also have been configured and recompiled with network support added. This is usually done during the installation process, although some users will have to force the kernel recompilation manually if they installed their software in a nonstandard manner.

First we'll deal with the use of a network card, and then look at how to change the basic process to handle SLIP over a serial port and modem.

Before you start modifying system files, you should take a few minutes to determine a few basic pieces of information you'll need. It is advisable to write these down somewhere so that they will be handy when you need them, and also so that you won't enter two different values in two files, thereby causing major problems for the system. IP Address First you need an IP address, a unique number for your machine. Every machine on the network has to be identified uniquely to allow proper routing. TCP/IP-based networks use 32-bit addresses to uniquely identify networks and all the devices that reside within that network. These addresses are called Internet addresses or IP addresses.

The 32 bits of the IP address are broken into four 8-bit parts. Each 8-bit part can then have valid numbers ranging from 0 to 255. In IP addresses, the four 8-bit numbers are separated by a period, a notation called dotted quad. Examples of dotted quad IP addresses are 255.255.255.255 and 147.14.123.8.

For convenience, IP addresses are divided into two parts: the network number and the device number within that network. This separation into two components allows devices on different networks to have the same host number. However, since the network number is different, the devices are still uniquely identified.

For connection to the Internet, IP addresses are assigned by the Internet Network Information Center (NIC) based on the size of the network. Anyone who wants to connect to the Internet must register with the NIC to avoid duplication of network addresses. If you don't plan to connect to the Internet, you are free to create your own numbering scheme, although future expansion and integration with Internet-using networks can cause serious problems.

For maximum flexibility, IP addresses are assigned according to network size. Networks are divided into three categories: Class A, Class B, and Class C. The three network classes break the 32-bit IP addresses into different sizes for the network and host identifiers.

A Class A address uses one byte for the network address and three bytes for the device address, allowing more than 16 million different host addresses. Class B networks use two bytes for the network and two bytes for the host. Since 16 bits allow more than 65,000 hosts, only a few large companies will be limited by this type of class. Class C addresses have three bytes for the network and one for the number of hosts. This provides for a maximum of 254 hosts (the numbers 0 and 255 are reserved) but many different network IDs. The majority of networks are Class B and Class C.

You do have a limitation as to the first value. A Class A network's first number must be between 0 and 127, Class B addresses are between 128 and 191, and Class C addresses are between 192 and 223. This is because of the way the first byte is broken up, with a few of the bits at the front saved to identify the class of the network. Also, you can't use the values 0 and 255 for any part, because they are reserved for special purposes.

Messages sent using TCP/IP use the IP address to identify sending and receiving devices, as well as any routing information put within the message headers. If you are going to connect to an existing network, you should find out what their IP addresses are and what numbers you can use. If you are setting up a network for your own use but plan to connect to the Internet at some point, you should contact the Network Information Center for an IP Address. On the other hand, if you are setting up a network for your own use and don't plan to have more than a telephone connection to other networks (including the Internet), you can make up your own IP addresses.

If you are only setting up a loopback driver, you don't even need an IP address. The default value for a loopback driver is 127.0.0.1. Network Mask Next, you need a network mask. This is pretty easy if you have picked out an IP address. The network mask is the network portion of the IP address set to the value 255, and it's used to blank out the network portion to determine routing.

If you have a Class C IP address (three bytes for network and one for devices), your network mask is 255.255.255.0. A Class B network has a network mask of 255.255.0.0, and a Class A network mask is 255.0.0.0.

If you are configuring only a loopback driver, your network mask is 255.0.0.0 (Class A). Network Address The network address is, strictly speaking, the IP address bitwise-ANDed to the netmask. In English, what this means is that it's the network portion of your IP address, so if your IP address is 147.120.46.7 and it's a Class B network, the network address is 147.120.0.0.

To get your own network address, just drop the device-specific part of the IP address and set it to zero. A Class C network with an IP address of 201.12.5.23 has a network address of 201.12.5.0.

If you're only working with a loopback address, you don't need a network mask. Broadcast Address The broadcast address is used when a machine wants to send the same packet to all devices on the network. To get your broadcast address, you set the device portion of the IP address to 255. Therefore, if you have the IP address 129.23.123.2, your broadcast address will be 129.23.123.255. Your network address will be 129.23.123.0.

If you are configuring only a loopback driver, you needn't worry about the broadcast address. Gateway Address The gateway address is the IP address of the machine that is the network's gateway out to other networks (such as the Internet). You need a gateway address only if you have a network that has a dedicated gateway out. If you are configuring a small network for your own use and don't have a dedicated Internet connection, you don't need a gateway address.

Normally, gateways have the same IP address as your machines, but they have the digit 1 as the device number. For example, if your IP address is 129.23.123.36, chances are that the gateway address is 129.23.123.1. This convention has been used since the early days of TCP/IP.

Loopback drivers do not require a gateway address, so if you are configuring your system only for loopback, ignore this address. Name Server Address Many larger networks have a machine whose purpose is to translate IP addresses into English-like names, and vice versa. It is a lot easier to call a machine bobs_pc instead of 123.23.124.23. This translation is done with a system called the Domain Name System (DNS). If your network has a name server, that's the address you need. If you want to have your own machine act as a name server (which requires some extra configuration not mentioned here), use the loopback address 127.0.0.1.

Loopback drivers don't need a name server since the machine only talks to itself. Therefore, you can ignore the nameserver address if you are only configuring a loopback driver.

What's a dummy interface? It's a bit of a trick to give your machine an IP address to work with when it uses only SLIP and PPP interfaces. A dummy interface solves the problem of a standalone machine (no network cards connecting it to other machines) whose only valid IP address to send data to is the loopback driver (127.0.0.1). While SLIP and PPP may be used for connecting your machine to the outside world, when the interface is not active, you have no internal IP address that applications can use.

The problem arises with some applications that require a valid IP address to work. Some word processors and desktop layout tools, for example, require the TCP/IP system to be operational with an IP address for the target machine. The dummy interface essentially sets an IP address for your local machine that is valid as far as TCP/IP is concerned, but doesn't really get used except to fool applications.

Creating a dummy interface is very simple. If your machine has an IP address already assigned for it in the /etc/hosts file, all you need to do is set up the interface and create a route. The two required commands are

ifconfig dummy machine_name

route add machine_name

where machine_name is your local machine's name (such as darkstar). This creates a link to your own IP address. If you do not have an IP address for your machine in the /etc/hosts file, you should add one before you create the dummy interface.

Configuring Linux for TCP/IP is not difficult, because only a few configuration files need to have the information about IP address and such added to them. You can do this with any editor, as long as it saves the files in ASCII format. It is advisable to make copies of the configuration files before you modify them, just in case you damage the format in some way.

Many of these files are similar in every version of UNIX, including most versions of Linux, except for one or two slight naming variations. If you've ever set up a UNIX system (or snooped around one in detail), these files and steps might seem familiar. If you haven't done anything with Linux or UNIX before, just take it one step at a time and follow the instructions! rc Files Linux reads the rc (run command) files when the system boots. The init program initiates the reading of these files, and they usually serve to start processes such as mail, printers, cron, and so on. They are also used to initiate TCP/IP connections. Most Linux systems have the rc command files in the directory /etc/rc.d.

The two files of interest to TCP/IP are rc.inet1, which sets the network parameters, and rc.inet2, which starts the daemons used by TCP/IP. On some systems, these two files are combined into one larger file called either rc.inet or rc.net.

To configure the rc.inet files to start up the TCP/IP network, you must first make sure that the files are actually read by the init program. This is handled by the /etc/inittab and /etc/rc.d/rc.M files, where there are one or more lines that control the reading of the rc.inet files.

Some Linux versions use only the /etc/inittab file to start the TCP/IP daemons. The Slackware version, though, has a line in the /etc/inittab file that tells the init program to read the file /etc/rc.d/rc.M when running multiuser mode. The TCP/IP daemons are not started when the system is in single-user mode.

Whichever file is involved, look for a line that refers to the rc.inet1, rc.inet, or rc.net file. In some cases, this line or lines will be commented out (have a pound sign as the first character) to prevent the system from trying to run TCP/IP when there is no requirement for it. If the lines are commented out, remove the comment symbol. The Slackware release of Linux, for example, has an if loop within the rc.M file that has these lines in it:

/bin/hostname `cat /etc/HOSTNAME | cut -f1 -d .`

/bin/sh /etc/rc.d/rc.inet1

/bin/sh /etc/rc.d/rc.inet1

Make sure that these lines (as well as the if loop that the lines are part of) are not commented out. You want these lines to execute each time the if condition is true. With the Slackware version, the if condition checks for the existence of the file rc.inet1.

If you can't find a reference to the rc.inet files in /etc/inittab, or a pointer to another file that has these files referenced (as with Slackware's /etc/rc.d/rc.M), you will have to add the lines to the /etc/inittab file manually. This can be scary for newcomers to Linux, so make copies of the files so you can always recover. An emergency boot floppy is also always handy to have.

Usually there is a good set of comments within the startup files to help you configure the system. There is a section for TCP/IP Ethernet support that often has a number of lines commented out. It consists of lines like this:

#IPADDR="127.0.0.1"

#NETMASK=""

#NETWORK="127.0.0"

#BROADCAST=""

#GATEWAY=""

Obviously, these correspond to the pieces of information you determined earlier. Therefore, uncomment the lines and type in the information about your machine. If you don't have one of the pieces, such as a gateway address, leave that line commented out.

In the rc.inet1 file you will also note several references to the programs ifconfig and route. These programs control TCP/IP communications. ifconfig configures network device interfaces, and route configures the routing table.

Near the top of the rc.inet1 file (or whichever file is used in your version of Linux) are a couple of lines that call both ifconfig and route for the loopback driver. The lines probably look like this:

/sbin/ifconfig lo 127.0.0.1

/sbin/route add -net 127.0.0.0

Neither of these lines should be commented out. They are necessary to set the loopback driver, which must exist on the system in order for TCP/IP to function properly.

Below the settings for your machine's IP address, there will probably be a number of lines that are commented out, with instructions to uncomment one of them. The differences between the lines is whether broadcast and netmask variables are included. To begin, try uncommenting the line that looks like this:

/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}

If this causes problems later during system startup, you should switch the uncommented line to the one that reads

/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK}

eth0 is the first device for the first Ethernet card on your system, called eth0.

Finally, if you have a gateway machine on your network, there will be a section of the rc.inet1 file that lets you enter the IP address of the gateway. Again, these lines should be uncommented. You might want to try to get the system working properly before you set up the gateway, because it is easier to debug when the number of potential problems is smaller.

The rc.inet2 file starts up the daemons used by TCP/IP. In most cases you won't have to make changes to this file, because the most important daemons are usually started anyway. Look for a line that calls the inetd program, which is the most important TCP/IP daemon of all. There should be no comments on the line that starts it. It will probably look like this:

if [-f ${NET}/inetd

then

      echo -n " inetd"

      ${NET}/inetd

else

      echo "no INETD found.  INET cancelled."

      exit 1

fi

If you read Chapter 13, "Shell Programming," or you know a little about programming in some other language, this short section might make sense. This routine checks for the existence of the inetd file, and starts it if it's there. If it's not there, an error message is generated on the display (remember this is during the boot process), and the rc.inet2 file is exited.

More commented-out daemons will probably be listed below inetd, such as named (the name server daemon that converts proper names to IP address), routed (used for routing), and several others. Unless you know that you want one of these daemons active, leave them commented out for now.

One other daemon you might want running is syslogd. It usually is set to execute automatically. This is the system logging daemon, which collects log messages from other applications and stores them in log files. The log file locations, which you can change as you desire, are given in the file /etc/syslog.conf.

That's enough changes to the rc files for now. After TCP/IP is installed and tested, the rest of the daemons (routed, named, and so on) can be started one at a time to ensure they work. The first task is to get TCP/IP communicating with other machines properly. Then you tweak it! /etc/hosts The /etc/hosts file is a simple list of IP addresses and the hostnames to which they correspond. This is a good location to list all your favorite machines so that you can use the name and have the system look up the IP address. On very small networks, you can add all the machines in the network here and avoid the need to run the named daemon.

Every /etc/hosts file will have an entry for localhost (also called loopback, IP address 127.0.0.1) and probably one for your machine, if you named it when you installed the software. If you didn't supply a name and there is no line other than localhost, you can add it now. Use an editor and set your IP address and machine name. Don't bother adding too many other machines until you're sure the network works properly! Here's a sample /etc/hosts file:

127.0.0.1         localhost

147.12.2.42       merlin.tpci merlin

You will notice that the format is quite simple: an IP address in one column and the name in another column, separated by tabs. If the machine may have more than one name, supply them all. In the example, which uses random numbers for the IP address, the machine 147.12.2.42 has the name merlin. Since it is also part of a larger network called tpci, the machine can be addressed as merlin.tpci. Both names on the line ensure that the system can resolve either name to the same address.

You can expand the file a little if you want by adding other machines on your local network, or those you will communicate with regularly:

127.0.0.1         localhost

147.12.2.42       merlin.tpci merlin

147.12.2.43       wizard.tpci wizard

147.12.2.44       arthur.tpci arthur bobs_machine

147.12.2.46       lancelot.tpci lancelot

In this example, there are several machines from the same network (the same network address). One has three different names.

If you are only using the loopback driver, the only line that should be in the file is for the IP address 127.0.0.1 with the name localhost and your machine's name after it. /etc/networks The /etc/networks file lists names and IP addresses of your own network and other networks you connect to frequently. This file is used by the route command, started through the rc.inet1 file. One advantage of this file is that it lets you call remote networks by name, so instead of typing 149.23.24, you can type eds_net.

The /etc/networks file should have an entry for every network that will be used with the route command. If there is no entry, errors will be generated, and the network won't work properly.

A sample /etc/networks file using random IP addresses is shown next. Remember that you need only the network address and not the device portion of a remote machine's IP address, although you must fill in the rest with zeroes:

loopback                  127.0.0.0

localnet                  147.13.2.0

eds_net                   197.32.1.0

big_net                   12.0.0.0

At a minimum, you must have a loopback and localnet address in the file. /etc/host.conf The system uses the host.conf file to resolve hostnames. It usually contains two lines that look like this:

order hosts, bind

multi on

These tell the system to first check the /etc/hosts file, then check the nameserver (if one exists) when trying to resolve a name. The multi entry lets you have multiple IP addresses for a machine in the /etc/hosts file (which happens with gateways and machines on more than one network).

If your /etc/host.conf file looks like these two lines, you don't need to make any changes at all. resolv.conf The resolv.conf file is used by the name resolver program. It gives the address of your name server (if you have one) and your domain name (if you have one). You will have a domain name if you are on the Internet.

A sample resolv.conf file for the system merlin.tpci.com has an entry for the domain name, which is tpci.com (merlin is the name of an individual machine):

domain tpci.com

If a name server is used on your network, you should add a line that gives its IP address:

domain tpci.com

nameserver  182.23.12.4

If there are multiple name servers, which is not unusual on a larger network, each name server should be specified on its own line.

If you don't have a domain name for your system, you can safely ignore this file for now. /etc/protocols UNIX systems use the /etc/protocols file to identify all the transport protocols available on the system and their respective protocol numbers. (Each protocol supported by TCP/IP has a special number, but that's not really important at this point.) Usually, this file is not modified but is maintained by the system and updated automatically as part of the installation procedure when new software is added.

The /etc/protocols file contains the protocol name, its number, and any alias that may be used for that protocol. A sample /etc/protocols file looks like this:

# Internet protocols (IP)

ip     0   IP

icmp   1   ICMP

ggp    3   GGP

tcp    6   TCP

egp    8   EGP

pup    12  PUP

udp    17  UDP

hello  63  HELLO

If your entries don't match this, don't worry. You shouldn't have to make any changes to this file at all, but you should know what it does. /etc/services The /etc/services file identifies the existing network services. This file is maintained by software as it is installed or configured.

This file consists of the service name, a port number, and the protocol type. The port number and protocol type are separated by a slash, following the conventions mentioned in previous chapters. Any optional service alias names follow. Here's a short extract from a sample /etc/services file:

# network services

echo     7/tcp

echo     7/udp

discard  9/tcp   sink  null

discard  9/udp   sink  null

ftp      21/tcp

telnet   23/tcp

smtp     25/tcp   mail mailx

tftp     69/udp

# specific services

login    513/tcp

who      513/udp   whod

You shouldn't change this file at all, but you do need to know what it is and why it is there to help you understand TCP/IP a little better. /etc/hostname or /etc/HOSTNAME The file /etc/hostname or /etc/HOSTNAME is used to store the name of the system you are on. (Slackware Linux uses the uppercase version of the name.) This file should have your local machine's name in it:

merlin.tpci

That's all it needs. The host name is used by most protocols on the system and many applications, so it is important for proper system operation. The host name can be changed by editing the system file and rebooting the machine, although many distributions provide a utility program to ensure that this process is performed correctly.

Linux systems have a utility called hostname, which displays the current setting of the system name, as well as the uname program, which can give the node name with the command uname -n. When issued, the hostname and uname commands echo the local machine name, as the following sample session shows:

$ hostname

merlin.tpci.com

$ uname -n

merlin

Some Linux versions of hostname show only the name without the domain name attached. All the configuration files necessary for TCP/IP to function have now been set properly, so you should be able to reboot the machine and see what happens.

To try out TCP/IP, reboot your machine and carefully watch the messages displayed on-screen. If you see any error messages, they may help guide you to the faulty file or process. Otherwise, you will see the TCP/IP daemons load one after another.

Probably the best approach to checking on TCP/IP is to use the netstat command, which gives you many different summaries of all network connections and their status. The netstat program provides comprehensive information. It's the program most commonly used by administrators to quickly diagnose a problem with TCP/IP.

There are many more netstat options than the ones mentioned in the next sections. For more information on netstat, start with the man page on the Linux system, then check a good UNIX networking book. Communications End Points The netstat command with no options shows information on all active communications end points (where data is actually being transferred or communications are established). To display all end points (active and passive), netstat uses the -a option.

The netstat output is formatted in columns that show the protocol (Proto), the amount of data in the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and the current state of the connection. Here's a truncated sample output:

merlin> netstat -a

Active Internet connections (including servers)

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)

ip         0      0  *.*                    *.*

tcp        0   2124  tpci.login             oscar.1034             ESTABL.

tcp        0      0  tpci.1034              prudie.login           ESTABL.

tcp    11212      0  tpci.1035              treijs.1036            ESTABL.

tcp        0      0  tpci.1021              reboc.1024             TIME_WAIT

tcp        0      0  *.1028                 *.*                    LISTEN

tcp        0      0  *.*                    *.*                    CLOSED

udp        0      0  localhost.1036         localhost.syslog

udp        0      0  *.1034                 *.*

udp        0      0  *.*                    *.*

udp        0      0  *.*                    *.*

This excerpt has three active TCP connections, as identified by the state ESTABL., with one that has data being sent (as shown in the Send-Q column). An asterisk means that no end point is yet associated with that address. Network Interface Statistics The behavior of the network interface (such as the network interface card) can be shown with the netstat -i option. This quickly shows administrators whether there are major problems with the network connection.

The netstat -i command displays the name of the interface, the maximum number of characters a packet can contain (MTU), the number of input packets received error free (RX-OK), number of received packets with errors (RX-ERR), number of received packets dropped (RX-DRP), and the number of packets that could not be received (RX-OVR). This is followed by the same statistics for sent packets. The following is a sample output from a netstat -i command:

merlin> netstat -i

Kernel Interface table

Iface   MTU Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flags

lo     2000   0      0      0      0      0     12      0      0      0 BLRU

eth0   1500   0    218      0      0      0    144      0      0      0 BRU

Routing Table Information Routing tables are continually updated to reflect connections to other machines. To obtain information about the routing tables (if there are any on your system), the netstat -r option is used.

Columns show the destination machine, the address of the gateway to be used, a flag to show whether the route is active (U) and whether it leads to a gateway (G) or a machine (H for host), a reference counter (Refs) that specifies how many active connections may use that route simultaneously, the number of packets that have been sent over the route (Use), and the interface name.

merlin> netstat -r

Kernel routing table

Destination     Gateway         Genmask         Flags Metric Ref Use    Iface

localnet        *               255.255.0.0     U     0      0    262   eth0

loopback        *               255.0.0.0       U     0      0     12   lo

default         *               0.0.0.0         U     0      0      0   eth0

The ping (Packet Internet Groper) program is used to query another system and ensure that a connection is active. The ping program operates by sending a request to the destination machine for a reply. If the destination machine's IP software receives the request, it issues a reply immediately.

The sending machine will continue to send requests until the ping program is terminated with a break sequence. After termination, ping displays a set of statistics. A sample ping session is shown as follows:

prudie> ping merlin

PING merlin: 64 data bytes

64 bytes from 142.12.130.12: icmp_seq=0.  time=20.  ms

64 bytes from 142.12.130.12: icmp_seq=1.  time=10.  ms

64 bytes from 142.12.130.12: icmp_seq=2.  time=10.  ms

64 bytes from 142.12.130.12: icmp_seq=3.  time=20.  ms

64 bytes from 142.12.130.12: icmp_seq=4.  time=10.  ms

64 bytes from 142.12.130.12: icmp_seq=5.  time=10.  ms

64 bytes from 142.12.130.12: icmp_seq=6.  time=10.  ms

-- merlin PING Statistics --

7 packets transmitted, 7 packets received, 0% packet loss

round-trip (ms) min/avg/max = 10/12/20

If ping was unable to reach the remote machine, it will display error messages. You can also ping the localhost, which will show if there is an error in the loopback driver configuration files.

The ping program is useful because it provides four important pieces of information: whether the TCP/IP software is functioning correctly, whether a local network device can be addressed (validating its address), whether a remote machine can be accessed (again validating the address and testing the routing), and verifying the software on the remote machine.

SLIP connections are configured in much the same manner as the TCP/IP connections described earlier. SLIP is one method of using a modem (or other serial port device) to communicate instead of a network card. SLIP is especially useful for connecting to the Internet through service providers such as UUNET Technologies or NetCom.

For SLIP connections, two Linux programs are involved: dip and slattach. Both programs can be used to initiate the SLIP connection. You cannot dial into a SLIP line with a standard communications program because of the special system calls SLIP uses.

dip and slattach have different purposes. The slattach program, which simply connects to the serial device, is used when there is a permanent connection to the SLIP server (no modem or setup handshaking is required). The dip program handles the initiation of the connection, the login, and connection handshaking. If you use a modem to connect to a SLIP server, you should use dip. The dip program can also be used to configure your own system as a SLIP server, allowing others to call in to it.

SLIP is a fairly simple network protocol because only two devices are involved: yours and the server's. When the connection is established, SLIP sends an IP address that will be used for that connection. Some systems use the same IP address (static), while others will have a different IP address each time a connection is made (dynamic). The configuration is slightly different for each type.

A static connection requires that the IP addresses be included in the same files as for an Ethernet network connection. Your machine's IP address should be in the files /etc/hosts, rc.inet1, rc.inet2, host.conf, and resolv.conf. The gateway address should be the IP address of the SLIP server. The SLIP device names used are sl0, sl1, sl2, and so on.

The only difference in configuration between Ethernet and SLIP is in the rc.inet1 file, where you only want to execute the ifconfig and route programs for the loopback driver. If you use dip to establish the SLIP connection, it will probably take care of this for you, although some problems are occasionally encountered. In these cases, manual changes to the file should be made to allow ifconfig and route to be executed manually from the shell, or from inside a shell script.

The ifconfig routine might need to be modified with the argument pointopoint. SLIP is a variation of Point-to-Point Protocol (PPP). The line would look like this:

ifconfig sl0 147.123.12.2 pointopoint 121.12.234.2

The first IP address (147.123.12.2) is your machine's IP address, and the numbers following the argument (121.12.234.2) are the IP address of the SLIP server.

If you have a dedicated connection to the SLIP server and you want to use slattach, the rc.inet1 file is modified to have the following lines in it:

IPADDR="123.12.3.1"          # Your machine's IP address

REMADDR="142.12.3.12"  # The SLIP server IP address



slattach -p cslip -s 19200 /dev/ttyS0     # set baud and port as needed

/etc/ifconfig sl0 $IPADDR pointopoint $REMADDR up

/etc/route add default gw $REMADDR

These lines, or very similar lines, will appear in most rc.inet1 or rc.inet files, usually commented out. Amend the information to show the proper IP addresses, ports, and baud rates. The cslip argument for slattach tells the program to use slip with header compression. If this causes problems, change it to slip.

If the SLIP server you are connecting to allocates IP addresses dynamically, you can't put an IP address in the configuration files, because it will change each time. Most SLIP servers display a message with the IP address when you connect, and dip can capture these numbers and use them to alter the system parameters appropriately.

The dip program greatly simplifies the connection to a SLIP server. To use it, you need a chat script that contains all the commands used to establish communications with the SLIP server during login. The chat script usually includes your login and password too, automating the login process.

A sample dip chat script is included in the man pages for dip, so you should display the man page and read the contents, then save the file (by redirection or copying the man page source) and edit the script. Here's a sample chat script that you can enter by hand if necessary, making sure you put in your own data:

# Connection script for SLIP

# Fetch the IP address of our target host.

main:

  # Set the desired serial port and speed.

  port /dev/cua0

  speed 38400

  # Reset the modem and terminal line.

  reset

  # Prepare for dialing.

  send ATZ1\r

  wait OK 4

  if $errlvl != 0 goto error

  dial 666-0999                     ## Change to your server's number!

  if $errlvl != 0 goto error

  wait CONNECT 60

  if $errlvl != 0 goto error

  # We are connected.  Log into the system.

login:

  sleep 3

  send \r\n\r\n

  wait merlin> 20             ## Change to your server's prompt

  if $errlvl != 0 goto error

  send login\n

  wait name: 10               ## Wait username: prompt

  if $errlvl != 0 goto erro

  send login_name\n                 ## Change to your own

  wait ord: 10                      ## Wait password prompt

  if $errlvl != 0 goto error

  send my_password\n                ## Change to your own!

  wait merlin> 10

  if $errlvl != 0 goto error

  send slip\n                       ## Change to suit your server

  wait SLIP 30                      ### Wait for SLIP prompt

  if $errlvl != 0 goto error

  get $local remote 10              ## Assumes the server sends your IP..

  if $errlvl != 0 goto error        ## address as soon as you enter slip.

  get $remote merlin                ## slip server address from /etc/hosts

done:

  print CONNECTED to $remote with address $rmtip we are $local

  default

  mode SLIP

  goto exit

error:

  print SLIP to $host failed.

exit:

# End dip script

Several different variations of the chat scripts are currently available, including a few on most CD-ROM distributions. If you have access to the Internet, you can find them on some FTP sites or posted on a Linux newsgroup. (See Appendix A, "FTP Sites and Newsgroups.")

PPP is a more talented protocol than SLIP and is preferable for most uses. However, the configuration is a little more complex than SLIP's. Linux divides the PPP functions into two parts, one for the High-Level Data Link Control (HLDC) protocol which helps define the rules for sending PPP datagrams between the two machines, and one for the PPP daemon, called pppd, which handles the protocol once the HLDC system has established communications parameters. In addition, Linux uses a program called chat, which calls the remote system.

As with SLIP, PPP establishes a modem link between the two machines, and then hands over the control of the line to PPP. You, as the user, never get to see a shell prompt or login, because PPP handles it all for you. Both HLDC and pppd are complex utilities with many options available to fine-tune their behavior. Because you may never use most of these options, you can safely ignore all but the most important aspects necessary to get a PPP connection up and running properly.

Prior to establishing a PPP link, you must have a loopback driver established. You should also have a name resolution system in operation, even if it's the /etc/hosts file or a simple DNS cache-only name server.

It is best to use PPP with a special user account called PPP for optimum protection and behavior. This is not necessary, and you can easily use PPP from any user account, but for more secure operation, you should consider creating a PPP user. The process is simple. First, you need to add a new user to the /etc/passwd file. You can use whatever script your system normally uses to add new users, or edit the /etc/passwd file yourself. (See Chapter 41, "Users," for more information about users and /etc/passwd.)

A sample /etc/passwd entry for the ppp account (with UID set to 201 and GID set to 51) looks like this:

ppp:*:201:51:PPP account:/tmp:/etc/ppp/pppscript

In this case, the account is set with no password (so no one can log into the account) and a home directory of /tmp (because no files are created). The startup program is set to /etc/ppp/pppscript, a file you create with the configuration information in it (you can use any filename, of course). A sample contents for the pppscript file looks like this:

#!/bin/sh

mesg n

stty -echo

exec pppd -detach silent modem crtscts

The first line forces execution of the script into the Bourne shell. The second command turns off all attempts to write to the ppp account's tty. The stty command is necessary to stop everything the remote sends being echoed again. Finally, the exec command runs the pppd daemon (which handles all PPP traffic). You will see the pppd daemon and the options later in this section.

PPP requires you to establish a modem connection to the remote machine before it can take over and handle the communications. There are several utilities available to do this, the most commonly used of which is chat. The chat program is popular because it uses a scripting style similar to that used by UUCP. (See Chapter 44, "UUCP.")

To use chat, you have to assemble a command line that looks almost the same as a UUCP /etc/Systems file entry. For example, to call a remote machine with a Hayes-compatible modem (using the AT command set) at the number 555-1234, you use the following command. It is all formatted as a chat script, UUCP style:

chat "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

If you read the UUCP chapter, this may look familiar. If not, all the entries are in a "send-expect" format, with what you send to the remote specified after what you receive from it. The chat script always starts with an expect string, which you must set to be empty because the modem won't talk to you without any signal to it. After the empty string, send the ATZ (reset) command, wait for an OK back from the modem, and then send the dial command. Once a CONNECT message is received back from the modem, the login script for the remote machine is executed--you send a blank character, wait for the ogin: (login) prompt, send the login name ppp, wait for the word: (password) prompt, and then send your password. After the login is complete, chat terminates but leaves the line open.

If you want to see all the activity that goes on with the chat program, you can force all messages to the syslog daemon for future study. The -v option forces the messages to syslog, so the command would be as follows:

chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

If the other end of the connection doesn't answer with a login script as soon as its modem answers, you may have to force a Break command down the line to jog the remote end. This is done in the same way as with UUCP:

chat -v "" ATZ OK ATDT5551234 CONNECT "" ogin:-BREAK-ogin: ppp word: secret1

There's a security problem with this type of chat entry, because any user doing a ps -ef command will see the entire command line (with its passwords). If you are the only user of your system, this isn't a concern, but to save yourself any problems, you can embed the script portion of the command in a file and read the file into chat. Then, the script will not appear on a ps output. To call a file for use with chat, use the -f option:

chat -f chat_file

The chat_file will contain the string:

"" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

The chat script can help you detect common error conditions, such as a line busy or no connection established. The messages from your modem (Hayes uses BUSY and NO CARRIER respectively) are embedded in the chat script with the ABORT option, which enables you to exit from the chat script gracefully if one of these error conditions occurs.

To handle these abort conditions, you embed the chat keyword ABORT followed by the message that should trigger an abort, prior to your normal chat script. For example, to modify the chat script above to abort on a BUSY or NO CARRIER message from the modem, the script would look like this:

ABORT BUSY ABORT `NO CARRIER' "" ATZ OK ATDT5551234 CONNECT "" ogin: ppp word: secret1

We needed two ABORT commands because each takes only one argument. The rest of the chat script is as usual. Note the need to put quotation marks around the NO CARRIER message because the space in the middle would confuse the script otherwise.

To set up a PPP connection, you need to invoke the pppd daemon. If you have a PPP connection already established and your machine is logged into a remote using the ppp account, you can start the pppd daemon. If you assume your local machine is using the device /dev/cua1 for its PPP connection at 38,400 baud, you would start up the pppd daemon with this command:

pppd /dev/cua1 38400 crtscts defaultroute

This command tells the Linux kernel to switch the interface on /dev/cua1 to PPP, and establish an IP link to the remote machine. The crtscts option, which is usually used on any PPP connection above 9600 baud, switches on hardware handshaking. The IP address the local system will use is taken from the local hostname, unless one is specified on the pppd command line (which you will seldom need to do, as the local host IP address should be correct for the PPP line).

If you want to force the local or remote IP addresses to be something other than the machine's default values, you can add the addresses with an option to pppd. The general format is to specify the local IP address, a colon, and then the remote IP address. For example, when the option

147.23.43.1:36.23.1.34

is added to the pppd command line, it sets the local IP address as 147.23.43.1 and the remote IP address to 36.23.1.34, regardless of what the local values are. If you only want to modify one IP address, leave the other portion blank. The command

147.23.43.1:

just sets the local IP address and accepts the remote IP address as whatever the machine sends.

Because you need chat to establish the connection in the first place, you can embed the chat command as part of the pppd command if you want. This is best done when reading the contents of the chat script from a file (using the -f option). For example, you could issue the following pppd command:

pppd connect "chat -f chat_file" /dev/cua1 38400 -detach crtscts modem defaultroute

Notice a few modifications to the pppd command other than the addition of the chat command in quotation marks. The connect command specifies the dialup script that pppd should start with, while the -detach command tells pppd not to detach from the console and move to background. The modem keyword tells pppd to monitor the modem port (in case the line drops prematurely) and hang up the line when the call is finished.

The pppd daemon begins setting up the connection parameters with the remote by exchanging IP addresses, and then sets communications values. Once that is done, pppd sets the network layer on your Linux kernel to use the PPP link by setting the interface to /dev/ppp0 (if it's the first PPP link active on the machine). Finally, pppd establishes a kernel routing table entry to point to the machine on the other end of the PPP link.

If you want to change the default behavior of the pppd daemon, you can do so through command line options or a control file. The file is a better approach if you want to change the parameters for every connection established using PPP.

Before completing the command line, pppd scans a number of possible options files. The more common file is /etc/ppp/options, which usually is used to set global defaults. An example of a /etc/ppp/options file looks like this:

# /etc/ppp/options: global definitions

domain merlin.com

auth            # force authentication

usehostname     # use local hostname for authentication

lock            # use file locking UUCP-style

The domain is established with the domain keyname followed by the full domain name (minus the machine name). The next two lines (auth and usehostname) deal with authentication of the PPP line, preventing unwanted usage and access. We will discuss authentication later in this section. The lock keyword tells pppd to use UUCP-style file locking to prevent device clashes. Locking should be used on all PPP systems to prevent problems.

The pppd daemon echoes all warnings and error messages to the syslog facility. If you used the -v option with the chat script, chat's messages are also sent to syslog. If you are having trouble with your PPP connections, check the syslog for details and try to isolate the problem.

Unless there is an entry in the /etc/syslog.conf file that redirects incoming error and warning messages to another file, the messages are discarded by syslog. To save the messages from pppd and chat, add this line to the /etc/syslog.conf file:

daemon.*        /tmp/ppp-log

This entry tells syslog to save any incoming messages from a daemon to the /tmp/ppp-log file. You can use any filename you want instead of /tmp/ppp-log. Many Linux versions of the syslog.conf file insist on tabs to separate the columns instead of spaces. Once your script is working, remember to remove this line or the log file will grow quite large!

If you really want to watch what is going on with pppd, you can invoke a debugging option with the kdebug command followed by a number. There are three values for debugging, as shown in this list:

• 1 General debug messages

• 2 Display incoming HLDC data

• 4 Display outgoing HLDC data

The numbers are added together to give the debug level you want. For example, the command kdebug 5 displays all general debug messages and all outgoing HLDC data. A value of 7 displays everything (this display gets very long!). You can send the output to a file or the console.

PPP is a wonderful protocol for modem-based communications, but it has one major problem: It has security holes large enough to drive a bus through. If even slightly incorrectly configured, anyone can use the PPP line to get into your machine, or use the PPP line to get out to other systems. To help prevent this, authentication is often used. Authentication essentially makes sure that each end of the connection is who they say they are and ensures that they are allowed to use the link.

There are two authentication schemes used by PPP: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP). PAP is much like a login procedure. When one machine sends the login name and password to the other, the receiving machine verifies the information with a database on its end. While it is a simpler scheme, PAP has the problem that anyone can tap into the line and monitor the passwords being sent.

CHAP solves this problem, and hence is the more favored form of authentication for PPP links. CHAP allows one machine to send a random string to the other, along with its hostname. The other end uses the hostname to look up the proper reply, combine it with the first string, encrypt it, and then resend it to the first machine along with its hostname. The first machine performs the same sort of manipulation on the random string it first sent, and if the two replies match, the authentication is complete. CHAP doesn't authenticate only at start time, but at random intervals throughout the connection, which adds to its power.

When two machines connect, they don't use authentication unless explicitly instructed to do so. When authentication is active, one end tries to use CHAP first; then, if that fails because the other end doesn't support CHAP, it uses PAP. If neither authentication scheme is supported by the other end, the connection is terminated. If you are going to use authentication for all your PPP connections, put the auth entry in the /etc/ppp/options file. If not all your connections support authentication, then those connections will fail if auth is specified.

The information needed for both CHAP and PPP is kept in two files called /etc/ppp/chap-secrets and /etc/ppp/ppp-secrets, respectively. When authentication is active, one end will check the other for these files, trying CHAP first. If you are going to use authentication for all your connections (which is a very good idea), you can build up the chap-secrets and pap-secrets files. If you configure both chap-secrets and pap-secrets and specify the auth option in /etc/ppp/options, no unauthenticated host can connect to your machine.

The /etc/ppp/chap-secrets file consists of four columns for the client name, the server name, the secret password string, and an optional list of IP addresses. The behavior of the system is different depending on whether the local machine is being challenged to authenticate itself or is issuing a challenge to the remote. When the local machine has to authenticate itself, pppd examines the /etc/ppp/chap-secrets file for an entry in the client field that matches the local host name and the server field equal to the remote hostname, and then uses the string to build the authentication message. Such an entry in the /etc/ppp/chap-secrets file looks like this:

#   client            server           string        addresses

merlin.tpci.com    big_guy.big_net.com   "I hate DOS"

This entry uses the string I hate DOS to build an authentication message back to big_guy.big_net.com. The quotations are necessary to surround the string in the file. (We will look at the addresses column in a moment.) If you are setting up your system to connect to three different PPP remotes, you will want an entry for each server, so your file may look like this:

#   client            server           string        addresses

merlin.tpci.com    big_guy.big_net.com "I hate DOS"

merlin.tpci.com    chatton.cats.com     "Meow, Meow, Meow"

merlin.tpci.com    roy.sailing.ca         "Hoist the spinnaker"

When your machine is sending the challenge, the process is reversed. The pppd daemon looks for the remote hostname in the client field, the local hostname in the server field, and uses the string to compare the encryption results with the string sent back by the remote. Entries in the /etc/ppp/chap-secrets file for this purpose look like this:

#   client            server           string        addresses

big_guy.big_net.com    merlin.tpci.com      "Size isn't everything"

Again, you need an entry for each remote machine you may need to authenticate. You can see that you will end up having mirror image entries for the client and server fields for each machine you connect to (because either end may require authentication at any time). A simple /etc/ppp/chap-secrets file really looks like this:

#   client            server           string        addresses

merlin.tpci.com    big_guy.big_net.com   "I hate DOS"

big_guy.big_net.com merlin.tpci.com      "Size isn't everything"

merlin.tpci.com    chatton.cats.com       "Meow, Meow, Meow"

chatton.cats.com    merlin.tpci.com      "Here, Kitty, Kitty"

merlin.tpci.com    roy.sailing.ca          "Hoist the spinnaker"

roy.sailing.ca      merlin.tpci.com      "Man overboard"

The size of the file could get quite large, so CHAP enables you to use a wildcard match, usually only for your local machine. For example, in the following /etc/ppp/chap-secrets file, the last entry allows any other machine connecting to the localhost and requiring authentication to use the same string:

#   client            server           string        addresses

merlin.tpci.com    big_guy.big_net.com   "I hate DOS"

big_guy.big_net.com merlin.tpci.com      "Size isn't everything"

merlin.tpci.com    chatton.cats.com       "Meow, Meow, Meow"

chatton.cats.com    merlin.tpci.com      "Here, Kitty, Kitty"

merlin.tpci.com    roy.sailing.ca          "Hoist the spinnaker"

*                 merlin.tpci.com      "Man overboard"

Of course, the remote must have the same string in its chap-secrets file. This is a little less secure than a dedicated string for each remote, but can be a handy time-saver when using a number of machines only rarely.

The addresses field, which wasn't used in the preceding samples, lets you list either symbolic names or IP addresses for the clients. This is necessary if the remote wants to use another IP address than its normal one, which would normally cause the authentication to fail. If the address field is empty (as they all are in the samples), any IP address is allowed. A hyphen in the field disallows all IP addresses with that client.

The /etc/ppp/pap-secrets file is much the same as the chap-secrets file. The fields in the pap-secrets file are the client (called a user in the pap-secrets format) and server names, a secret string, and valid address aliases. However, the look of the file is different because the client and server names are not full domain names, and the secret string is a single block of text. A sample pap-secrets file looks like this:

# /etc/ppp/pap-secrets

#    user        server            string        addresses

merlin        darkstar            yG55Sj29    darkstar.big_net.com

darkstar        merlin            5Srg7S    merlin.tpci.com

merlin        chatton            MeowMeow    chatton.cats.com

chatton        merlin            73wrh6s    merlin.tpci.com

In this example, the first two lines show a connection to the machine darkstar. The first line is how you authenticate a request from darkstar, and the second is how you authenticate a request from us to them. The user name in the first column is the name you send to the remote, while the server field is their identification to you. This poses a problem: The pppd daemon has no way of knowing the remote host's name because all it gets is an IP address. You can put the IP address in the addresses column of the file, or you can specify the remote host name at the end of the pppd command line like this:

pppd ..... remotename chatton user merlin

This shows that the remote is called chatton, and your local host is merlin. The last portion giving the local host name will override any default values.

In this chapter you've seen how to install, configure, and test Ethernet connections to your Linux machine. You've also seen how to set up a SLIP or PPP connection. The only other networking process usually found on a Linux box uses UUCP (UNIX-to-UNIX Copy), which is described in Chapter 44.