Chapter 15. TCP/IP and PPP
So, you've staked out your homestead on the Linux frontier,
and installed and configured your system. What next? Eventually
you'll want to communicate with other systems--Linux and
otherwise--and the Pony Express isn't going to suffice.
Fortunately, Linux supports a number of methods for data communication
and networking. This includes serial communications,
TCP/IP, and UUCP. In this
chapter and the next, we will discuss how to configure your
system to communicate with the world.
Linux Network Administrator's Guide, available
from the Linux Documentation Project (see the Bibliography) and also published by O'Reilly &
Associates, is a complete guide to configuring
TCP/IP and UUCP networking under
Linux. For a detailed account of the information presented here, we
refer you to that book.
15.1. Networking with TCP/IP
Linux supports a full implementation of the Transmission Control
Protocol/Internet Protocol (TCP/IP) networking
protocols. TCP/IP has become the most successful
mechanism for networking computers worldwide. With Linux and an
Ethernet card, you can network your machine to a Local Area Network
(LAN) or (with the proper network connections) to
the Internet--the worldwide TCP/IP network.
Hooking up a small LAN of Unix
machines is easy. It simply requires an Ethernet controller in each
machine and the appropriate Ethernet cables and other hardware. Or if
your business or university provides access to the Internet, you can
easily add your Linux machine to this network.
Linux TCP/IP support has had its ups and
downs. After all, implementing an entire protocol stack from scratch
isn't something that one does for fun on a weekend. On the other
hand,
the Linux TCP/IP code has benefited greatly from
the hoard of beta testers and developers to have crossed its path, and
as time has progressed many bugs and configuration problems have
fallen in their wake.
The current implementation of TCP/IP and related
protocols for Linux is called NET-4. This has no
relationship to the so-called NET-2 release of
BSD Unix; instead, in this context,
NET-4 means the fourth implementation of
TCP/IP for Linux. Before NET-4
came (no surprise here) NET-3,
NET-2, and NET-1, the last having been
phased out around kernel Version 0.99.pl10. NET-4
supports nearly all the features you'd expect from a Unix
TCP/IP implementation and a wide range of
networking hardware.
Linux NET-2 also supports Serial Line Internet
Protocol (SLIP) and Point-to-Point Protocol
(PPP). SLIP and PPP
allow you to have dial-up Internet access using a modem.
If your business or university provides SLIP or
PPP access, you can dial in to the
SLIP or PPP server and put your machine on the Internet over the phone line.
Alternatively, if your Linux machine also has Ethernet access to the Internet,
you can configure it as a SLIP or PPP server.
In the following sections, we won't mention SLIP any more, because
nowadays most people use PPP. If you want to run SLIP on your machine,
you can find all the information in the Linux Network
Administrator's Guide.
Besides the Linux Network Administrator's Guide, the Linux
NET-3 HOWTO contains
more or less complete information on configuring
TCP/IP and
PPP
for Linux.
The Linux Ethernet HOWTO is a related document that describes
configuration of various Ethernet card drivers for Linux.
Also of interest is TCP/IP Network Administration by
Craig Hunt. It contains complete information on using and configuring
TCP/IP on Unix systems. If you plan to set up a network of Linux
machines or do any serious TCP/IP hacking, you should have the
background in network administration presented by that book.
If you really want to get serious about setting up and operating
networks, you will probably also want to read DNS and
BIND by Cricket Liu and Paul Albitz. This book tells you
all there is to know about name servers in a refreshingly funny manner.
15.1.1. TCP/IP Concepts
In order to fully appreciate (and utilize) the power of
TCP/IP, you should be familiar with its underlying
principles. Transmission Control Protocol/Internet Protocol is a suite
of protocols (the magic buzzword for this
chapter) that define how machines should communicate
with each other via a network, as well as internally to other layers
of the protocol suite. For the theoretical background of the Internet
protocols, the best sources of information are the first volume of
Douglas Comer's Internetworking with TCP/IP and
the first volume of W. Richard Stevens' TCP/IP
Illustrated.
TCP/IP was originally developed for use on the Advanced Research Projects
Agency network, ARPAnet, which was funded to support military
and computer-science research. Therefore, you may hear TCP/IP being
referred to as the "DARPA Internet
Protocols." Since then, many other
TCP/IP networks have come into use, such as the National Science
Foundation's NSFNET, as well as thousands of other local and regional
networks around the world. All of these networks are interconnected into
a single conglomerate known as the Internet.
On a TCP/IP network, each machine is assigned an
IP address, which is a 32-bit number uniquely
identifying the machine. You need to know a little about IP addresses
to structure your network and assign addresses to hosts. The IP
address is usually represented as a dotted quad: four numbers in
decimal notation, separated by dots. As an example, the IP address
0x80114b14 (in hexadecimal format) can be written as 128.17.75.20.
The IP address is divided into two parts: the network address and the
host address. The network address consists of the higher-order bits of
the address and the host address of the remaining bits. (In general,
each host is a separate machine on the network.)
The size of these two fields depends upon the type of network in
question. For example, on a Class B network (for which the first byte
of the IP address is between 128 and 191), the first two bytes of the
address identify the network, and the remaining two bytes identify the
host (see Figure 15-1). For the example address
just given, the network address is 128.17, and the host address is
75.20. To put this another way, the machine with IP address
128.17.75.20 is host number 75.20 on the network 128.17.
Figure 15-1. IP address
In addition, the host portion of the IP address may be subdivided
to allow for a subnetwork address. Subnetworking allows
large networks to be divided into smaller subnets, each of which
may be maintained independently. For example, an organization
may allocate a single Class B network, which provides two bytes
of host information, up to 65,534 hosts on the network. The organization may then wish to dole out
the responsibility of maintaining portions of the network, so that
each subnetwork is handled by a different department.
Using subnetworking, the organization can specify, for example, that
the first byte of the host address (that is, the third byte of the overall
IP address) is the subnet address, and the second byte is the
host address for that subnetwork (see Figure 15-2). In this
case, the IP address
128.17.75.20 identifies host number 20 on subnetwork 75 of network
128.17.[57]
[57]Why
not 65,536 instead? For reasons to be discussed later, a host
address of 0 or 255 is invalid.
Figure 15-2. IP address with subnet
Processes (either on the same machine or on different machines)
that wish to communicate via TCP/IP generally specify the destination
machine's IP address as well as a port address. The destination
IP address is used, of course, to route data from one machine to
the destination machine. The port address is a 16-bit number that
specifies a particular service or application on the destination
machine that should receive the data. Port numbers can be thought of
as office numbers at a large office building: the entire building
has a single IP address, but each business has a separate office
there.
Here's a real-life example of how IP addresses and port numbers are
used. The telnet program allows a user on one machine to
start a login session on another. On the remote machine,
there is the telnet "daemon," telnetd, which is listening
to a specific port for incoming connections (in this case, the
port number is 23).[58]
[58]On many systems, telnetd is not
always listening to port 23; the Internet services daemon inetd
is listening on its behalf. For now, let's sweep that detail under the
carpet.
The user executing telnet specifies the address of the machine
to log in to, and the telnet program attempts to open a connection
to port 23 on the remote machine. If it is successful, telnet
and telnetd are able to communicate with each other to provide
the remote login for the user in question.
Note that the telnet client on the local machine has a
port address of its own. This port address is allocated to
the client dynamically when it begins execution. This is because
the remote telnetd doesn't need to know the port number of
the incoming telnet client beforehand. When the client
initiates the connection, part of the information it sends
to telnetd is its port number. telnetd can be thought
of as a business with a well-known mailing address. Any
customers that wish to correspond with the telnetd running
on a particular machine need to know not only the IP address
of the machine to talk to (the address of the telnetd office
building), but also the port number where telnetd can be found
(the particular office within the building). The address and
port number of the telnet client are included as part of
the "return address" on the envelope containing the letter.
The TCP/IP family contains a number of protocols. Transmission
Control Protocol (TCP) is responsible for providing reliable,
connection-oriented communications between two processes, which may
be running on different machines on the network.
User Datagram
Protocol (UDP) is similar to TCP except that it provides
connectionless, unreliable service. Processes that use UDP must
implement their own acknowledgment and synchronization routines
if necessary.
TCP and UDP transmit and receive data in units known as packets.
Each packet contains a chunk of information to send to another
machine, as well as a header specifying the destination and source
port addresses.
Internet Protocol (IP) sits beneath TCP and UDP in the protocol
hierarchy. It is responsible for transmitting and routing TCP or
UDP packets via the network. In order to do so, IP wraps each TCP
or UDP packet within another packet (known as an IP datagram),
which includes a header with routing and destination information.
The IP datagram header includes the IP address of the source and
destination machines.
Note that IP doesn't know anything about
port addresses; those are the responsibility of TCP and UDP.
Similarly, TCP and UDP don't deal with IP addresses, which
(as the name implies) are only IP's concern. As you can see,
the mail metaphor with return addresses and envelopes is quite
accurate: each packet can be thought of as a letter contained within
an envelope. TCP and UDP wrap the letter in an envelope with the
source and destination port numbers (office numbers) written on it.
IP acts as the mail room for the office building sending the letter.
IP receives the envelope and wraps it in yet another envelope, with the
IP address (office building address) of both the destination and the
source affixed. The post office (which we haven't
discussed quite yet) delivers the letter to the appropriate
office building. There, the mail room unwraps the outer envelope
and hands it to TCP/UDP, which delivers the letter to the
appropriate office based on the port number (written on the
inner envelope). Each envelope has a return address that
IP and TCP/UDP use to reply to the letter.
In order to make the specification of machines on the Internet
more humane, network hosts are often given a name as well as an
IP address. The Domain Name Service (DNS) takes care of
translating hostnames to IP addresses, and vice versa, as well
as handles the distribution of the name-to-IP address database
across the entire Internet. Using hostnames also allows the
IP address associated with a machine to change (e.g., if
the machine is moved to a different network), without
having to worry that others won't be able to "find" the
machine once the address changes. The DNS record for the
machine is simply updated with the new IP address, and all
references to the machine, by name, will continue to work.
DNS is an enormous, worldwide distributed database.
Each organization
maintains a piece of the database, listing the machines in the
organization. If you find yourself in the position of maintaining the
list for your organization, you can get help from the Linux
Network Administrator's Guide or
TCP/IP Network Administration.
If those aren't enough, you can really get the full scoop from the
book DNS and BIND.
For the purposes of most administration, all you need to know is that
a daemon called named (pronounced "name-dee") has to run
on your system. This daemon is your window onto DNS.
Now, we might ask ourselves how a packet gets from one
machine (office building) to another. This is the actual job of IP,
as well as a number of other protocols that aid IP in its task.
Besides managing IP datagrams on each host (as the mail room),
IP is also responsible for routing packets between hosts.
Before we can discuss how routing works, we must explain the
model upon which TCP/IP networks are built. A network is just
a set of machines that are connected together through some
physical network medium--such as Ethernet or serial lines.
In TCP/IP terms, each network has its own methods for handling
routing and packet transfer internally.
Networks are connected to each other via gateways
(also known as routers).
A gateway is a host that has direct connections to two or
more networks; the gateway can then exchange information
between the networks and route packets from one network
to another. For instance, a gateway might be a workstation with
more than one Ethernet interface. Each interface is connected
to a different network, and the operating system uses this
connectivity to allow the machine to act as a gateway.
In order to make our discussion more concrete, let's
introduce an imaginary network, made up of the machines
eggplant, papaya, apricot, and zucchini.
Figure 15-3 depicts the configuration of
these machines on the network. Note that papaya is
connected to another network as well, which includes the
machines pineapple and pear. These machines
have the respective IP addresses:
Hostname |
IP address |
eggplant |
128.17.75.20 |
apricot |
128.17.75.12 |
zucchini |
128.17.75.37 |
papaya |
128.17.75.98, 128.17.112.3 |
pear |
128.17.112.21 |
pineapple |
128.17.112.40, 128.17.30.1 |
As you can see, papaya has two IP addresses--one on the
128.17.75 subnetwork and another on the 128.17.112 subnetwork.
pineapple has
two IP addresses as well--one on 128.17.112 and another on 128.17.30.
IP uses the network portion of the IP address to determine how to
route packets between machines. In order to do this, each machine
on the network has a routing table, which contains a list
of networks and the gateway machine for that network. To route a
packet to a particular machine, IP looks at the network portion of
the destination address. If there is an entry for that network in the
routing table, IP routes the packet through the appropriate gateway.
Otherwise, IP routes the packet through the "default" gateway
given in the routing table.
Routing tables can contain entries for specific machines
as well as for networks. In addition, each machine has a
routing table entry for itself.
Let's examine the routing table for eggplant. Using the
command netstat -rn, we see the following:
eggplant:$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
128.17.75.0 128.17.75.20 255.255.255.0 UN 1500 0 0 eth0
default 128.17.75.98 0.0.0.0 UGN 1500 0 0 eth0
127.0.0.1 127.0.0.1 255.0.0.0 UH 3584 0 0 lo
128.17.75.20 127.0.0.1 255.255.255.0 UH 3584 0 0 lo
The first column displays the destination networks (and hosts) that the
routing table includes. The first entry is for the network 128.17.75
(note that the host address is 0 for network entries), which is the
network that eggplant lives on. Any packets sent to this network
should be routed through 128.17.75.20, which is the IP address of eggplant.
In general, a machine's route to its own network is through itself.
The Flags column of the routing table gives
information on the destination address for this entry;
U specifies that the route is "up,"
N that the destination is a network, and so on.
The MSS field shows how many bytes are transferred
at a time over the respective connection, Window
indicates how many frames may be sent ahead before a confirmation
must be made, irtt gives statistics on the use of
this route, and Iface lists the network device used
for the route. On Linux systems, Ethernet interfaces are named
eth0, eth1, and so
on. lo is the loopback device, which we'll
discuss shortly.
The second entry in the routing table is the default route, which
applies to all packets destined for networks or hosts for which there
is no entry in the table. In this case, the default route is through
papaya, which can be considered the door to the outside world.
Every machine on the 128.17.75 subnet must go through papaya to
talk to machines on any other network.
The third entry in the table is for the address 127.0.0.1, which is
the loopback address. This address is used when a
machine wants to make a TCP/IP connection to
itself. It uses the lo device as its interface,
which prevents loopback connections from using the Ethernet (via the
eth0 interface). In this way, network bandwidth
is not wasted when a machine wishes to talk to itself.
The last entry in the routing table is for the IP address
128.17.75.20, which is the eggplant host's own address. As we can see,
it uses 127.0.0.1 as its gateway. This way, any time eggplant makes a TCP/IP
connection to itself, the loopback address is used as the gateway, and
the lo network device is used.
Let's say that eggplant wants
to send a packet to zucchini. The IP datagram contains a source
address of 128.17.75.20 and a destination address of 128.17.75.37. IP
determines that the network portion of the destination address is
128.17.75 and uses the routing table entry for 128.17.75.0
accordingly. The packet is sent directly to the network, which
zucchini receives and is able
to process.
What happens if eggplant wants
to send packets to a machine not on the local network, such as
pear? In this case, the
destination address is 128.17.112.21. IP attempts to find a route for
the 128.17.112 network in the routing tables, but none exists, so it
selects the default route through papaya. papaya receives the packet and looks up the
destination address in its own routing tables. The routing table for
papaya might look like this:
Destination Gateway Genmask Flags MSS Window irtt Iface
128.17.75.0 128.17.75.98 255.255.255.0 UN 1500 0 0 eth0
128.17.112.0 128.17.112.3 255.255.255.0 UN 1500 0 0 eth1
default 128.17.112.40 0.0.0.0 UGN 1500 0 0 eth1
127.0.0.1 127.0.0.1 255.0.0.0 UH 3584 0 0 lo
128.17.75.98 127.0.0.1 255.255.255.0 UH 3584 0 0 lo
As you can see, papaya is connected to the 128.17.75 network
through its eth0 device and to 128.17.112 through eth1.
The default route is through pineapple, which is a gateway to
the Wild Blue Yonder (as far as papaya is concerned).
Once papaya receives a packet
destined for pear, it sees
that the destination address is on the network 128.17.112 and routes
that packet to the network using the second entry in the routing table.
Similarly, if eggplant wants to send packets to machines
outside the local organization, it would route packets through
papaya (its gateway). papaya would, in turn, route
outgoing packets through pineapple, and so forth. Packets
are handed from one gateway to the next until they reach the
intended destination network. This is the
basic structure upon which the Internet is based: a seemingly
infinite chain of networks, interconnected via gateways.
15.1.2. Hardware Requirements
You can use Linux TCP/IP without any networking
hardware at all; configuring
"loopback" mode allows you to talk to yourself. This is necessary for
some applications and games that use the loopback network device.
However, if
you want to use Linux with an Ethernet TCP/IP
network, obviously you'll need an Ethernet adapter card. Many Ethernet
adapters are supported by Linux for the ISA,
EISA, and PCI buses, as well as
pocket and PCMCIA adapters. In Chapter 1, "Introduction
to Linux", we provided a partial list of supported
Ethernet cards; see the Linux Ethernet HOWTO for a
complete discussion of Linux Ethernet hardware compatibility.
Linux also supports
SLIP and PPP, which allow you
to use a modem to access the Internet over the phone line. In this
case, you'll need a modem compatible with your SLIP
or PPP server; for example, many servers require a
56kbps V.90 modem (most also support K56flex). In this book, we
describe the configuration of PPP,
because it is what most Internet service providers offer. If you want to use
the older SLIP, please see the Linux Network
Administrator's Guide.
15.1.3. Configuring TCP/IP with Ethernet
In this section, we discuss how to
configure an Ethernet TCP/IP connection on a Linux
system. Presumably this system will be part of a local network of
machines that are already running TCP/IP; in which
case your gateway, name server, and so forth are already configured
and available.
The following information applies primarily to Ethernet connections.
If you're planning to use PPP, read this section to
understand the concepts, and follow the
PPP-specific instructions in the section
"Section 15.2, "Dial-up PPP"" later in this
chapter.
On the other hand, you may wish to set up an entire
LAN of Linux machines (or a mix of Linux machines
and other systems). In this case, you'll have to take care of a number
of other issues not discussed here. This includes setting up a name
server for yourself, as well as a gateway machine if
your network is to be connected to other networks. If your network is
to be connected to the Internet, you'll also have to obtain IP
addresses and related information from your access provider.
In short, the method described here should work for many Linux systems
configured for an existing LAN--but certainly not all. For
further details, we direct you to a book on TCP/IP
network administration, such as those mentioned at the beginning of
this chapter.
First of all, we assume that your Linux system has the necessary
TCP/IP software installed. This includes basic
clients such as Telnet and FTP,
system-administration commands, such as ifconfig and
route (usually found in /etc
or /sbin), and networking configuration files
(such as /etc/hosts). The other Linux-related
networking documents described earlier explain how to go about
installing the Linux networking software if you do not have it
already.
We also assume that your kernel has been configured and compiled with
TCP/IP support enabled. See the section
"Section 7.4, "Building a New Kernel"" in
Chapter 7, "Upgrading Software and the Kernel", for information
on compiling your kernel. To enable networking, you must answer yes to the
appropriate questions during the make config or
make menuconfig step, rebuild the
kernel, and boot from it.
Once this has been done, you must modify a number of configuration
files used by NET-4. For the most part this is a simple procedure.
Unfortunately, however, there is wide disagreement between Linux
distributions as to where the various TCP/IP configuration files
and support programs should go. Much of the time, they can be found
in /etc, but in other cases may be found in /usr/etc,
/usr/etc/inet, or other bizarre locations. In the worst case,
you'll have to use the find command to locate the files on your
system. Also note that not all distributions keep the NET-2 configuration
files and software in the same location; they may be spread across
several directories.
This section also assumes use of one Ethernet device on the system.
These instructions should be fairly easy to extrapolate
if your system has more than one network connection (and hence acts
as a gateway).
Here, we also discuss configuration for loopback-only systems
(systems with no Ethernet or PPP connection). If you have no network
access, you may wish to configure your system for loopback-only TCP/IP,
so that you can use applications that require it.
15.1.3.1. Your network configuration
Before you can configure TCP/IP, you need to determine the following
information about your network setup. In most cases, your local
network administrator or network-access provider can provide you with
this information:
- Your IP address
This is the unique machine address in dotted-decimal
format. An example is 128.17.75.98. Your network administrators will
provide you with this number.
If you're configuring loopback mode (i.e., no PPP, no Ethernet
card, just TCP/IP connections to your own machine), your
IP address is 127.0.0.1.
- Your subnetwork mask
This is a dotted quad, similar
to the IP address, which determines which portion of the IP address
specifies the subnetwork number and which portion specifies the host on
that subnet.
The subnetwork mask is a pattern of bits, which, when bitwise-ANDed with
an IP address on your network, will tell you which subnet that
address belongs to. For example, your subnet mask might be 255.255.255.0.
If your IP address is 128.17.75.20, the subnetwork portion of your
address is 128.17.75.
We distinguish here between "network address" and "subnetwork address."
Remember that for Class B addresses, the first two bytes (here, 128.17)
specify the network, while the second two bytes specify the host. With a subnet
mask of 255.255.255.0, however, 128.17.75 is considered the entire
subnet address (e.g., subnetwork 75 of network 128.17), and 20 the
host address.
Your network administrators choose the subnet mask and therefore
can provide you with this information.
This applies as well to the loopback device. Since the
loopback address is always 127.0.0.1, the netmask for
this device is always 255.0.0.0.
- Your subnetwork address
This is the subnet portion of your IP
address as determined by the subnet mask. For example, if your
subnet mask is 255.255.255.0 and your IP address 128.17.75.20, your
subnet address is 128.17.75.0.
Loopback-only systems don't have a subnet address.
- Your broadcast address
This address is used to broadcast packets
to every machine on your subnet. In general, this is equal to your
subnet address (see previous item) with 255 replaced as the host address. For subnet
address 128.17.75.0, the broadcast address is 128.17.75.255. Similarly,
for subnet address 128.17.0.0, the broadcast address is 128.17.255.255.
Note that some systems use the subnet address itself as the broadcast address.
If you have any doubt, check with your network administrators.
Loopback-only systems do not have a broadcast address.
- The IP address of your gateway
This is the address of the machine
that acts as the default route to the outside world. In fact, you may
have more than one gateway address--for example, if your network is
connected directly to several other networks. However, only one
of these will act as the default route.
(Recall the example
in the previous section, where the 128.17.112.0 network is connected both
to 128.17.75.0 through papaya, and to the outside world
through pineapple.)
Your network administrators will provide you with the IP addresses
of any gateways on your network, as well as the networks they
connect to. Later, you will use this information with the route
command to include entries in the routing table for each gateway.
Loopback-only systems do not have a gateway address. The same is true
for isolated networks.
- The IP address of your name server
This is the address of the
machine that handles hostname-to-address translations for your machine. Your network administrators will provide you with this information.
You may wish to run your own name server (by configuring and running
named). However, unless you absolutely must run your own
name server (for example, if there is no other name server available on
your local network), we suggest using the name-server address provided
by your network administrators. At any rate, most books on TCP/IP configuration
include information on running named.
Naturally, loopback-only systems have no name-server address.
15.1.3.2. The networking rc files
rc files are systemwide resource configuration scripts executed at boottime by init. They run basic system daemons
(such as sendmail, crond, and so on) and are used to configure network
parameters. rc files are usually found in the directory
/etc/rc.d.
Note that there are many ways to carry out the network
configuration described here. Every Linux distribution uses a slightly
different mechanism to help automate the process. What we describe here is
a generic method that allows you to create two rc
files that will run the appropriate commands to get your machine
talking to the network. Most distributions have their own scripts that
accomplish more or less the same thing. If in doubt, first attempt to
configure networking as suggested by the documentation for your distribution
and, as a last resort, use the methods described here. (As an example, the
Red Hat distribution uses the script
/etc/rc.d/init.d/network, which obtains network
information from files in
/etc/sysconfig. The
control-panel system administration program provided
with Red Hat configures networking automatically without
editing any of these files. The SuSE distribution, on the other hand, distributes the
configuration over several files, such as
/sbin/init.d/network and
/sbin/init.d/route, among others, and lets you configure
most networking aspects via the tool yast.)
Here, we're going to describe the rc files used
to configure TCP/IP:
- Red Hat
Networking is scattered among files for each
init level that includes networking. For instance,
the /etc/rc.d/rc1.d directory controls a level 1
(single-user) boot, so it doesn't have any networking commands, but
the /etc/rc.d/rc3.d controlling a level 3 boot
has files specifically to start networking.
- SuSE
All the startup files for all system services, including
networking, are grouped together in the
/sbin/init.d directory. They are actually
quite generic and get their actual values from the system-wide
configuration file /etc/rc.config. The
most important files here are
/sbin/init.d/network, which starts and
halts network interfaces,
/sbin/init.d/route, which configures
routing, and /sbin/init.d/ serial, which
configures serial ports. If you have ISDN hardware, the files
/sbin/init.d/i4l and
/sbin/init.d/i4l_hardware are
applicable, too. Note that in general, you do not need to (and should
not) edit those files; edit
/etc/rc.config instead.
- Debian
The network configuration (Ethernet
cards, IP addresses, and routing) is set up in the file
/etc/init.d/network. The base networking daemons
(portmap and inetd themselves
are initialized by the start-stop script
/etc/init.d/netbase).
- Slackware
Networking is started by files named
rc.inet1 and rc.inet2.
rc.inet1 is used to configure the basic network parameters
(such as IP addresses and routing information), and rc.inet2
fires up the TCP/IP daemons (telnetd, ftpd, and so forth).
init uses the file /etc/inittab to determine what
processes to run at boot time. In order to run the files
/etc/rc.d/rc.inet1 and /etc/rc.d/rc.inet2 from init,
/etc/inittab might include entries such as:
n1:34:wait:/etc/rc.d/rc.inet1
n2:34:wait:/etc/rc.d/rc.inet2
The inittab file is described in the section
"Section 5.3.2, "init, inittab, and rc files"" in Chapter 5, "Essential System Management".
The first field gives a unique two-character identifier for
each entry. The second field lists the runlevels in which the
scripts are run; on this system, we initialize networking in
runlevels 3 and 4. The word wait in the third field
tells init to wait until the script has finished execution
before continuing. The last field gives the name of the script
to run.
While you are first setting up your network configuration,
you may wish to run rc.inet1 and rc.inet2 by hand
(as root) in order to debug any problems. Later you can include
entries for them in another rc file or in /etc/inittab.
As mentioned earlier, rc.inet1 configures the basic network interface.
This includes your IP and network address and the routing table information
for your system. Two programs are used to configure these parameters:
ifconfig and route. Both of these are usually found in /sbin.
ifconfig is used for configuring the network device interface with
certain parameters, such as the IP address, subnetwork
mask, broadcast address, and the like.
route is used to create and modify entries in the routing table.
For most configurations, an rc.inet1 file similar to the following
should work. You will, of course, have to edit this for your own system.
Do not use the sample IP and network addresses listed here;
they may correspond to an actual machine on the Internet:
#!/bin/sh
# This is /etc/rc.d/rc.inet1 - Configure the TCP/IP interfaces
# First, configure the loopback device
HOSTNAME=`hostname`
/sbin/ifconfig lo 127.0.0.1 # uses default netmask 255.0.0.0
/sbin/route add 127.0.0.1 # a route to point to the loopback device
# Next, configure the ethernet device. If you're only using loopback or
# SLIP, comment out the rest of these lines.
# Edit for your setup.
IPADDR="128.17.75.20" # REPLACE with your IP address
NETMASK="255.255.255.0" # REPLACE with your subnet mask
NETWORK="128.17.75.0" # REPLACE with your network address
BROADCAST="128.17.75.255" # REPLACE with your broadcast address
GATEWAY="128.17.75.98" # REPLACE with your default gateway address
# Configure the eth0 device to use information above
/sbin/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
# Add a route for our own network
/sbin/route add ${NETWORK}
# Add a route to the default gateway
/sbin/route add default gw ${GATEWAY} metric 1
# End of Ethernet Configuration
As you can see, the format of the ifconfig command is:
ifconfig interface device options…
For example:
ifconfig lo 127.0.0.1
assigns the lo (loopback) device the IP address
127.0.0.1, and:
ifconfig eth0 127.17.75.20
assigns the eth0 (first Ethernet) device the address 127.17.75.20.
In addition to specifying the address, Ethernet devices usually
require that the subnetwork mask be set with the netmask
option and the broadcast address be set with
broadcast.
The format of the route command, as used here, is:
route add [ -net | -host ] destination [ gw gateway ]
[ metric metric ] options
where destination is the destination address for this
route (or the keyword default), gateway the IP address
of the gateway for this route, and metric the metric number
for the route (discussed later).
We use route to add entries to the routing table. You should
add a route for the loopback device (as seen earlier), for your local
network, and for your default gateway. For example, if our
default gateway is 128.17.75.98, we would use the command:
route add default gw 128.17.75.98
route takes several options. Using -net or -host
before destination will tell route that the
destination is a network or specific host, respectively. (In most
cases, routes point to networks, but in some situations you may
have an independent machine that requires its own route. You would
use -host for such a routing table entry.)
The metric option specifies a
metric value for
this route. Metric values are used when there is more than one
route to a specific location, and the system must make a decision about
which to use. Routes with lower metric values are preferred. In this
case, we set the metric value for our default route to 1, which
forces that route to be preferred over all others.
How could there possibly be more than one route to a particular
location? First of all, you may use multiple route commands
in rc.inet1 for a particular destination--if you have more
than one gateway to a particular network, for example. However,
your routing tables may dynamically acquire additional entries in
them if you run routed (discussed further below).
If you run routed, other systems may broadcast routing
information to machines on the network, causing extra routing
table entries to be created on your machine. By setting the
metric value for your default route to 1, you ensure
that any new routing table entries will not supersede the preference
of your default gateway.
You should read the manual pages for ifconfig and route,
which describe the syntax of these commands in detail. There
may be other options to ifconfig and route that are
pertinent to your configuration.
Let's move on.
rc.inet2 is used to run various daemons used by the TCP/IP suite.
These are not necessary in order for your system to talk to the
network, and are therefore relegated to a separate rc file.
In most cases you should attempt to configure rc.inet1,
and ensure that your system is able to send and receive packets
from the network, before bothering to configure rc.inet2.
Among the daemons executed by rc.inet2 are inetd,
syslogd, and routed. The version of rc.inet2
on your system may currently start a number of other servers, but
we suggest commenting these out while you are debugging your
network configuration.
The most important of these servers is inetd, which acts as
the "operator" for other system daemons. It sits in the background
and listens to certain network ports for incoming connections.
When a connection is made, inetd spawns off a copy of the
appropriate daemon for that port. For example, when an incoming
Telnet connection is made, inetd forks in.telnetd,
which handles the Telnet connection from there. This is simpler
and more efficient than running individual copies of each daemon.
This way, network daemons are executed on demand.
syslogd is the system logging daemon; it accumulates log messages
from various applications and stores them into log files based on
the configuration information in /etc/syslogd.conf.
routed is a server used to maintain dynamic routing information.
When your system attempts to send packets to another network, it may
require additional routing table entries in order to do so.
routed takes care of manipulating the routing table without
the need for user intervention.
Here is a sample rc.inet2 that starts up syslogd,
inetd, and routed:
#! /bin/sh
# Sample /etc/rc.d/rc.inet2
# Start syslogd
if [ -f /usr/sbin/syslogd ]
then
/usr/sbin/syslogd
fi
# Start inetd
if [ -f /usr/sbin/inetd ]
then
/usr/sbin/inetd
fi
# Start routed
if [ -f /usr/sbin/routed ]
then
/usr/sbin/routed -q
fi
Among the various additional servers you may want to start in
rc.inet2 is
named. named is a name server;
it is responsible for translating (local) IP addresses to names, and
vice versa. If you don't have a name server elsewhere on the network, or if
you want to provide local machine names to other machines in your
domain, it may be necessary to run
named. named configuration is
somewhat complex and requires planning; we refer interested readers to
DNS and BIND.
15.1.3.8. Trying out your network
Once you have the various networking configuration files modified
for your system, you should be able to reboot (using a TCP/IP-enabled
kernel) and attempt to use the network.
When first booting the system, you may wish to disable execution of
rc.inet1 and rc.inet2 and run them by hand once the
system is up. This allows you to catch any error messages, modify
the scripts, and retry. Once you have things working, you can enable
the scripts from /etc/inittab.
One good way of testing network connectivity is to simply
telnet to another host. You should first try to connect to
another host on your local network, and if this works, attempt
to connect to hosts on other networks. The former will test your
connection to the local subnet; the latter, your connection to
the rest of the world through your gateway.
You may be able to connect to remote machines, via the
gateway, whereas connecting to machines on the subnet fails.
This is a sign that there is a problem with your subnetwork mask
or the routing table entry for the local network.
When attempting to connect to other machines, you should first
try to connect using only the IP address of the remote host.
If this seems to work, but connecting via hostname does not,
there may be a problem with your name server configuration
(e.g., /etc/resolv.conf and /etc/host.conf )
or with your route to the name server.
The most common source of network trouble is an ill-configured
routing table. You can use the command:
netstat -rn
to display the routing table; in the previous section, we
described the format of the routing tables as displayed by
this command.
The netstat manual page provides additional
insight as well.
Using netstat without the -n option forces it
to display host and network entries by name instead of address.
To debug your routing tables, you can either edit
rc.inet1 and reboot, or use the route command by
hand to add or delete entries. The manual page for route
describes the full syntax of this command. Note that simply
editing rc.inet1 and re-executing it will not clear out
old entries in the routing table; you must either reboot or
use route del to delete the entries.
If absolutely nothing seems to work, there may be a problem
with your Ethernet device configuration. First, be sure that your
Ethernet card was detected at the appropriate address and/or
IRQ at boot time. The kernel boot messages will give you this
information; if you are using syslogd, kernel boot-time
messages are also saved in a file, such as /var/log/messages.
If detection of your Ethernet card is faulty, you may have to
modify kernel parameters to fix it. The Linux Ethernet HOWTO
includes much information on
debugging Ethernet card configurations. In many cases, the fix is
as simple as specifying the appropriate IRQ and port address at
the LILO boot prompt. For example, booting via LILO with the command:
lilo: linux ether=9,0x300,0,1,eth0
will select IRQ 9, base address 0x300, and the external transceiver
(the fourth value of 1) for the eth0 device. To use the
internal transceiver (if your card supports both types), change the
fourth value of the ether option to 0.
Also, don't overlook the possibility that your Ethernet card is
damaged or incorrectly connected to your machine or the network.
A bad Ethernet card or cable can cause no end of trouble, including
intermittent network failures, system crashes, and so forth. When
you're at the end of your rope, consider replacing the Ethernet
card and/or cable to determine if this is the source of the
problem.[59]
[59]One of the authors once spent three hours trying to
determine why the kernel wouldn't recognize an Ethernet card
at boot time. As it turned out, the 16-bit card was plugged into
an 8-bit slot--mea culpa.
If your Ethernet card is detected, but the system is still having problems
talking to the network, the device configuration with ifconfig may be
to blame. Be sure you have specified the appropriate IP address,
broadcast address, and subnet mask for your machine. Invoking ifconfig
with no arguments displays information on your Ethernet device
configuration.
 |  |  | 14.2. Programming Tools |  | 15.2. Dial-up PPP |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
|