In this chapter, you will look at the world of networking. In particular, you will learn the following:
Linux offers a complete implementation of Transmission Control Protocol/Internet Protocol (TCP/IP), 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 or network interface 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 more than 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 through a stream of messages. TCP has message delivery assurance routines incorporated into it.
UDP (User Datagram Protocol): A connectionless service, meaning that the data is sent without the sending and receiving machines being in contact with each other. It's like sending snail-mail (regular postal service) with an address but no guarantee it
will arrive.
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 network hardware addresses of machines on the network based on their IP address.
DNS (Domain Name System): Determines numeric addresses from machine names.
RARP (Reverse Address Resolution Protocol): Determines IP addresses of machines on the network based on their network address (the 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 protocol efficiently transfers files from one machine to another. 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, and 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): An administrator's service that sends status messages about the network and devices attached to it.
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.
You can actually configure Linux to use TCP/IP without any network card or connection to a network, using a technique called loopback. Loopback is a method of instruction that enables part of TCP/IP to talk to another part without leaving the machine.
Essentially, you are creating a loop between a software exit and a software entry. Loopbacks are frequently used to test TCP/IP configurations, and some software 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.
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 are compatible with one of these cards, but you should carefully check the documentation with the card to ensure 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 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, 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.
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, because 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. Because 16 bits allows
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, 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.
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). If you have a complex network setup with subnets or shared IP addresses, you should consult your network administrator for more information about setting your
network mask and IP 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.
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.
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.
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 because 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 stand-alone 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 commands required are
ifconfig dummy machine_name route add machine_name
where machine_name is your local machine's name (such as darkstar). This will create a link to your own IP address. If you do not have an IP address for your machine in the /etc/hosts file, 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!
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 files of interest to TCP/IP, at least as far as Red Hat Linux is concerned, are under the /etc/rc.d/rc2.d directory. The files in this directory start different TCP/IP services. The names of most of the files identify their purposes. For example,
the file K20nfs deals with starting the NFS service.
If you want to change services that are started when Red Hat Linux boots, you can edit these files with as ASCII editor. Identify the file that is involved with the service you need to modify (you can often use grep to find the right file, or you can
look through them all with more). Whichever file is involved, look for a line that refers to the service. 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 them. If
the lines are commented out, remove the comment symbol.
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 nameserver.
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 mask). 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.
The /etc/networks file lists names and IP address of your own network and other networks you connect to frequently. This file is used by the route command. 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 you plan on using the network name as an identifier. If there is no entry, errors will be generated, and the network won't work properly. On the
other hand, if you don't need to use a network name instead of its IP address, then you can skip the /etc/networks file.
A sample /etc/networks file using random IP addresses is shown next. Remember that you need only the network mask 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 should have a loopback and localnet address in the file.
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.
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 the moment.
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.
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.
The file /etc/HOSTNAME is used to store the name of the system you are on. (Red Hat 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 operating
systems 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
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.
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.
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 meaning of each column in the netstat
command output is intuitive from the title, but if you need clarification check the man page on netstat.
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.
The ping (Packet Internet Groper) program is used to query another system and ensure 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.0 ms 64 bytes from 142.12.130.12: icmp_seq=1 time=10.1 ms 64 bytes from 142.12.130.12: icmp_seq=2 time=10.3 ms 64 bytes from 142.12.130.12: icmp_seq=3 time=20.2 ms 64 bytes from 142.12.130.12: icmp_seq=4 time=10.1 ms 64 bytes from 142.12.130.12: icmp_seq=5 time=10.2 ms 64 bytes from 142.12.130.12: icmp_seq=6 time=10.1 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 are used to initiate the SLIP connection. One of the two must be used to initiate the 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, host.conf, and resolv.conf. The gateway address should be the IP address
of the SLIP server. The SLIP device files used are sl0, sl1, sl2, and so on.
The only difference in configuration between Ethernet and SLIP is that you only want to execute the ifconfig and route programs for the loopback driver with SLIP. 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 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 in to 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.
PPP is a more talented and faster protocol than SLIP and is preferable for most uses. The configuration, however, 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 to 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 includes a
program called chat that can be used to call a remote system, although there are several other applications that make use of PPP for the same reason. One popular communications package for this purpose is Kermit.
As with SLIP, PPP establishes a modem link between the two machines, and then hands over the control of the line to PPP. As the user, you never get to see a shell prompt or login, as PPP handles it all for you. Both HLDC and pppd are complex utilities
with many options available to fine-tune their behavior. Because you will never use most of these options, we 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.
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 that 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. Several utilities are 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 43, "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, which 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
we must set to be empty because the modem won't talk to us without any signal to it. After the empty string, we 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: we send a blank character, wait for the ogin: (login) prompt, send the login name ppp, wait for word: (password) prompt, and then send our 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:
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 their 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, as 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. The script will not appear on a ps output, then. 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) are embedded in the chat script with the ABORT option, which allows you to exit
gracefully from the chat script 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, as 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 as 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 we 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 to establish an IP link to the remote machine. The crtscts option, which is usually used on any PPP connection about 9,600 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).
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, the option
147.23.43.1:36.23.1.34
when added to the pppd command line sets the local IP address as 147.23.43.1 and the remote IP address to 36.23.1.34, regardless of that the local values are. If you only want to modify one IP address, leave the other portion blank. The command
147.23.43.1:
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. 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
You will 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, then setting 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 it 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 above (auth and usehostname) deal with authentication of the PPP line, preventing unwanted usage and access. We will look at
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, you can 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, which are:
The numbers are added together to give the debug level you want. For example, the command kdebug 5 will display 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 are allowed to use the link. Authentication can also be used
with SLIP, but not many systems support it.
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 simple, 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 most 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, 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 a 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 (see the auth entry in the /etc/ppp/options file, discussed earlier). When authentication is active, one end will try to use CHAP first, then, if that fails
because the other end doesn't support CHAP, it will use 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 are 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, then uses the string to build the authentication message. Such as 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 will use 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 will have 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 (as 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 allows you to use a wildcard match, usually only for your local machine. For example, in the /etc/ppp/chap-secrets file below:
# 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"
The last entry allows any other machine connecting to the local host and requiring authentication to use the same string. Of course, the remote must have the same string in its chap-secrets file. This is a little less secure that 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 samples above, 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 cause the authentication
to fail normally. If the addresses 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 we authenticate a request from darkstar, and the second how we authenticate a request from us to them. The user name in the first column is the name we
send to the remote, while the server field is their identification to us. This poses a problem: The pppd daemon has no way of knowing the remote hosts name, as 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 our local host is merlin. The last portion giving the local host name override the default values, if specified.
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 43, "UUCP."
If you want to install a network to connect several of your machines (assuming you have more than one), you will find it quite easy and useful. If you have two machines, it is fast and efficient to connect a Linux machine and a DOS machine, as long as the DOS machine is running TCP/IP. There are shareware versions of TCP/IP for Windows and many commercial implementations for both DOS and Windows, and TCP/IP is built into both Windows 95 and Windows NT.
