|
Red Hat Linux: NetworkingLinux 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. What Is TCP/IP? 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.
Hardware Requirements 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. What You Need Before You Start 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. 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). 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. Setting Up the Dummy Interface 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 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! 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 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. /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 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 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 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. /etc/networks 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 At a minimum, you should 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 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):
If a name server is used on your network, you should add a line that gives
its IP address: domain tpci.com 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. /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) 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 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 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: 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 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.
Testing and Troubleshooting 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. The netstat Command 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 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 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. ping 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 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 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. Static IP Addresses 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. Dynamic IP Addresses 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 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.
Setting Up PPP 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. Setting Up a PPP Account 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: 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 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.
Dialing Out chat 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 . 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: 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 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 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 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. Checking 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 Authentication 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 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 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 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 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 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 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: 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. |
