Running Linux, 5th Edition (2009)
Part II. System Administration
Chapter 13. Networking
So, you've staked out your homestead on the Linux frontier, and installed and configured your system. What's 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 mostly means TCP/IP these days, but other techniques such as serial communications and even communication via radio links are available. In this chapter, we discuss how to configure your system to communicate with the world.
The Linux Network Administrator's Guide (O'Reilly), also available from the Linux Documentation Project, is a wide-ranging guide to configuring TCP/IP and other networking protocols under Linux. For a detailed account of the information presented here, we refer you to that book.
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 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 anymore because nowadays most people use PPP.
Besides the Linux Network Administrator's Guide, the various HOWTOs at http://www.tldp.org/HOWTO/HOWTO-INDEX/networking.html contain lots of information about how to set up particular aspects of networking, including how to deal with unruly hardware like some modems. For example, Linux Ethernet HOWTO at http://www.tldp.org/HOWTO/Ethernet-HOWTO.html is a document that describes configuration of various Ethernet card drivers for Linux.
Also of interest is TCP/IP Network Administration (O'Reilly). 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 (O'Reilly). This book tells you all there is to know about nameservers in a refreshingly funny manner.
TCP/IP Concepts
In order to fully appreciate (and utilize) the power of TCP/IP, you should be familiar with its underlying principles. TCP/IP 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 (Prentice Hall) and the first volume of W. Richard Stevens' TCP/IP Illustrated (Addison Wesley).
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 that first Internet, 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 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.
Two special cases should be mentioned here: dynamic IP addresses and masqueraded IP addresses. Both were invented to overcome the current shortage of IP addresses (which will not be of concern any longer once everybody has adopted the new IPv6 standard that prescribes 6 bytes for the IP addresses—enough for every amoeba in the universe to have an IP address).[*]
Dynamic IP addresses are what most Internet service providers (ISPs) use. When you connect to your ISP's service, whether by dial-up, DSL, or otherwise, you are assigned an IP number out of a pool that the ISP has allocated for this service. The next time you log in, you might get a different IP number. The idea behind this is that only a small number of the customers of an ISP are logged in at the same time, so a smaller number of IP addresses are needed. Still, as long as your computer is connected to the Internet, it has a unique IP address that no other computer is using at that time.
Masquerading (also known as Network Address Translation, NAT ) allows several computers to share an IP address. All machines in a masqueraded network use so-called private IP numbers, numbers out of a range that is allocated for internal purposes and that can never serve as real addresses out there on the Internet. Any number of networks can use the same private IP numbers, as they are never visible outside of the LAN. One machine, the "masquerading server," will map these private IP numbers to one public IP number (either dynamic or static) and ensure through an ingenious mapping mechanism that incoming packets are routed to the right machine.
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 on 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 (Figure 13-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.
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 2 bytes of host information, up to 65,534 hosts on the network.[†] The organization may then wish to dole
Figure 13-1. IP address
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 (Figure 13-2). In this case, the IP address 128.17.75.20 identifies host number 20 on subnetwork 75 of network 128.17.
Figure 13-2. IP address with subnet
Processes (on either the same or 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 ssh program allows a user on one machine to start a login session on another, while encrypting all the data traffic between the two so that nobody can intercept the communication. On the remote machine, the sshdaemon, sshd, is listening to a specific port for incoming connections (in this case, the port number is 22).[*]
The user executing ssh specifies the address of the machine to log in to, and the ssh program attempts to open a connection to port 22 on the remote machine. If it is successful, ssh and sshd are able to communicate with each other to provide the remote login for the user in question.
Note that the ssh 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 sshd doesn't need to know the port number of the incoming ssh client beforehand. When the client initiates the connection, part of the information it sends to sshd is its port number. sshd can be thought of as a business with a well-known mailing address. Any customers who wish to correspond with the sshd running on a particular machine need to know not only the IP address of the machine to talk to (the address of the sshd office building), but also the port number where sshd can be found (the particular office within the building). The address and port number of the ssh 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.
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 System (DNS ) takes care of translating hostnames to IP addresses, and vice versa, as well as handling 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 DNSrecord 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 Guideor TCP/IP Network Administration, both from O'Reilly. If those aren't enough, you can really get the full scoop from the book DNS and BIND (O'Reilly).
For the purposes of most administration, all you need to know is that either a daemon called named (pronounced "name-dee") has to run on your system, or you need to configure your system to use somebody else's name service—typically your ISP's or one running in your local network. This daemon or name service 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 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 13-3 depicts the configuration of these machines on the network.
Figure 13-3. Network with two gateways
As you can see, papaya has two IP addresses—one on the 128.17.75 subnetwork and another on the 128.17.112 subnetwork. pear and pineapple are both on network 128.17.112, and pineapple is also on 128.17.30.
IP uses the network portion of the IP address to determine how to route packets between machines. 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? 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. papayareceives 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 wanted 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.
Hardware Requirements
You can use Linux TCP/IP without any networking hardware ; 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, you'll need an Ethernet adapter card. Many Ethernet adapters are supported by Linux for the ISA, EISA, and PCI buses, as well as USB and PCMCIA adapters. See the Linux Ethernet HOWTO for a complete discussion of Linux Ethernet hardware compatibility. For any reasonably new computer (that was sold in the last, say, two to three years), it is also quite likely that the computer has Ethernet built in, so you do not have install an Ethernet adapter card. You'll recognize this because there is an Ethernet connector socket (type RJ45) somewhere.
Over the last few years, support has been added for non-Ethernet high-speed networking, such as HIPPI. This topic is beyond the scope of this book, but if you are interested, you can get some information from the directory Documentation/networking in your kernel sources.
If you have an ADSL connection and use an ADSL router, this looks to Linux just like a normal Ethernet connection. As such, you need neither specific hardware (except an Ethernet card, of course) nor special drivers besides the Ethernet card driver itself. If you want to connect your Linux box directly to your ADSL modem, you still don't need to have any particular hardware or driver, but you do need to run a protocol called PPPoE (PPP over Ethernet); more about this later.
Linux also supports SLIP and PPP, which allow you to use a modem to access the Internet over a phone line. In this case, you'll need a modem compatible with your SLIP or PPP server; for example, many servers require a 56-kbps 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.
Finally, there is PLIP, which lets you connect two computers directly via parallel ports, requiring a special cable between the two.
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 this case, your gateway, nameserver, 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 "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 nameserver 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 ssh 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.
A new system administration interface has been developed that unifies the various networking tasks (configurating, routing, etc.) into a single command named ip, provided by the IPROUTE2 package. We won't cover it here, because its value lies mainly in advanced features that most administrators don't use, but once you understand the concepts in this chapter you can figure out how to use those commands if you want to use that package.
We also assume that your kernel has been configured and compiled with TCP/IP support enabled. See "Building a New Kernel" in Chapter 18 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. 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 or /etc/sysconfig, but in other cases they 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 network configuration files and software in the same location; they may be spread across several directories.
Here we cover how to set up and configure networking on a Linux box manually. This should help you get some insight into what goes on behind the scenes and enable you to help yourself if something goes wrong with automatic setup tools provided by your distribution. It can be a good idea, though, to first try setting up your network with the configuration programs that your distribution provides; many of these are quite advanced these days and detect many of the necessary settings automatically. They are usually available from the menus on your desktop. If you understand the concepts in this chapter, it is not hard to figure out how to use them, but we do not cover them here because they tend to change, and what you mainly need to know is the effects you're aiming to achieve.
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.
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 ISP can provide you with this information. If your network is using DHCP, things are going to be a bit different—for example, you do not need to know your IP address, since it will be assigned to you automatically. But it's often easier to test things one step at a time and start with a static IP address. Just make sure with your network administrator or Internet service provider that you are not using one that another computer on the network is already using—that could be very annoying both for you and the other user, because communication will be disturbed, to say the least.
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 and 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 subnetwork address 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 to both 128.17.75.0 through papaya and 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 nameserver
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 nameserver (by configuring and running named). However, unless you absolutely must run your own nameserver (for example, if no other nameserver is available on your local network), we suggest using the nameserver address provided by your network administrators (or your ISP). At any rate, most books on TCP/IP configuration include information on running named.
Naturally, loopback-only systems have no nameserver address.
The network configuration files
Network configuration files are system-wide resource configuration scripts executed at boot time 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/init.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 network configuration 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 uses /etc/init.d/network, and lets you configure most networking aspects via the tool YaST2. And of course, any new version of either distribution could change this again.)
Here, we're going to describe the network configuration files used to configure TCP/IP in some of the better-known distributions:
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 /etc/init.d directory. They are quite generic and get their actual values from the system-wide configuration file /etc/sysconfig. The most important files here are /etc/init.d/network, which starts and halts network interfaces and configures routing, and /etc/init.d/setserial, which configures serial ports. If you have ISDN hardware, the file /etc/init.d/isdn is applicable, too. Note that in general, you do not need to (and should not) edit those files; edit the files /etc/sysconfig instead (that's what YaST does).
Debian
The network configuration (Ethernet cards, IP addresses, and routing) and the base networking daemons (portman and inetd) are set up in the file /etc/init.d/networking.
We'll use two files here for illustrative purposes: /etc/init.d/rc.inet1 and /etc/init.d/rc.inet2. The former will set up the hardware and the basic networking, and the latter will configure the networking services. A number of distributions follow such a separation, even though the files might have other names.
init uses the file /etc/inittab to determine what processes to run at boot time. To run the files /etc/init.d/rc.inet1 and /etc/init.d/rc.inet2 from init, /etc/inittab might include entries such as:
n1:34:wait:/etc/init.d/rc.inet1
n2:34:wait:/etc/init.d/rc.inet2
The inittab file is described in "init, inittab, and rc Files" in Chapter 17. The first field gives a unique two-character identifier for each entry. The second field lists the run levels in which the scripts are run; on this system, we initialize networking in run levels 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/init.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 that 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 is the IP address of the gateway for this route, and metric is 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 later). 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 a copy of the appropriate daemon for that port. For example, when an incoming FTP connection is made, inetd forks in.ftpd, which handles the FTP 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 logfiles 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/init.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 nameserver: it is responsible for translating (local) IP addresses to names, and vice versa. If you don't have a nameserver 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 (O'Reilly).
/etc/hosts
/etc/hosts contains a list of IP addresses and the hostnames they correspond to. In general, /etc/hosts contains entries for your local machine and perhaps other "important" machines (such as your nameserver or gateway). Your local nameserver provides address-to-name mappings for other machines on the network transparently. It is in fact possible to only get your address-to-name mappings from the /etc/hosts file , without running a local nameserver at all. If you only have a few machines on your network, that may well be possible. But if you have more, then you would have to change the /etc/hosts file on each machine for each change, a task that grows quadratic in size with the number of machines and quickly becomes infeasible.
For example, if your machine is eggplant.veggie.com with the IP address 128.17.75.20, your /etc/hosts would look like this:
127.0.0.1 localhost
128.17.75.20 eggplant.veggie.com eggplant
If you're just using loopback, the only line in the /etc/hosts file should be for the address 127.0.0.1.
/etc/networks
The /etc/networks file lists the names and addresses of your own and other networks. It is used by the route command and allows you to specify a network by name instead of by address.
Every network you wish to add a route to using the route command (generally called from rc.inet1) should have an entry in /etc/networks for convenience; otherwise, you will have to specify the network's IP address instead of the name.
As an example:
default 0.0.0.0 # default route - mandatory
loopnet 127.0.0.0 # loopback network - mandatory
veggie-net 128.17.75.0 # Modify for your own network address
Now, instead of using the command:
route add 128.17.75.20
we can use:
route add veggie-net
/etc/host.conf
The /etc/host.conf file specifies how your system resolves hostnames. It should contain the following two lines:
order hosts,bind
multi on
These lines tell the resolver libraries to first check the /etc/hosts file and then ask the nameserver (if one is present) for any names it must look up. The multi entry allows you to have multiple IP addresses for a given machine name in /etc/hosts.
On systems that use glibc2 (which applies to most of the newer distributions), /etc/nsswitch.conf is used instead of /etc/host.conf. In this case, this file should contain the lines hosts: files dns and networks: files dns.
/etc/resolv.conf
The /etcresolv.conf file configures the name resolver, specifying the address of your nameserver (if any) and domains that you want to search by default if a specified hostname is not a fully specified hostname. For example, if this file contains the line:
search vpizza.com vpasta.com
using the hostname blurb will cause the name resolver to try to resolve the names blurb.vpizza.com and blurb.vpasta.com (in this order). This is convenient because it saves you typing in the full names of often-used domains. On the other hand, the more domains you specify here, the longer the DNS lookup will take.
For example, the machine eggplant.veggie.com with a nameserver at address 128.17.75.55 would have the following lines in /etc/resolv.conf:
domain veggie.com
nameserver 128.17.75.55
You can specify more than one nameserver; each must have a nameserver line of its own in resolv.conf.
Setting your hostname
You should set your system hostname with the hostname command. This is usually executed from a file called /etc/init.d/boot.localnet or similar; simply search your system rc files to determine where it is invoked. For example, if your (full) hostname is eggplant.veggie.com, edit the appropriate rc file to execute the command /bin/hostname eggplant.veggie.com. Note that the hostname executable may be found in a directory other than /bin on your system.
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 ssh 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 if 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 the hostname does not, there may be a problem with your nameserver configuration (e.g., /etc/resolv.conf and /etc/host.conf) or with your route to the nameserver.
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(8) 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 by 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(8) 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.
A good way to determine whether it was really the Ethernet card that created the trouble is to use the command ifconfig interface_name, as in the following example:
ifconfig eth0
This will output statistics about the interface. If it has received or sent any packets, it must have been recognized by the kernel, and there cannot be a general hardware problem. If your card is not listed when issuing:
ifconfig
it wasn't even recognized by the kernel.
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 theLILO (or Grub, or whichever bootloader you are using) 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 or cable, or both, to determine if this is the source of the problem.[*]
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.
[*] Linux supports IPv6, but since most local networks and ISPs do not use it yet, it is not very relevant at this time, unfortunately.
[†] Why not 65,536 instead? For reasons to be discussed later, a host address of 0 or 255 is invalid.
[*] On many systems, sshd is not always listening to port 22; the Internet services daemon inetd is listening on its behalf. For now, let's sweep that detail under the carpet.
[*] 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.
Dial-Up PPP
To communicate over TCP/IP using a modem (such as through a dial-up account to an Internet service provider) or through some other serial device (such as a "null modem" serial cable between two machines), Linux provides the Point-to-Point Protocol software suite, commonly known as PPP. PPP is a protocol that takes packets sent over a network (such as TCP/IP) and converts them to a format that can be easily sent over a modem or serial wire. Chances are, if you have an Internet account with an ISP, the ISP's server uses PPP to communicate with dial-up accounts. By configuring PPP under Linux, you can directly connect to your ISP account in this way.
SLIP is an earlier protocol that has the same basic features as PPP. However, it lacks certain important qualities, such as the ability to negotiate IP addresses and packet sizes. These days SLIP has more or less been supplanted entirely by PPP.
In this section, we cover configuration of a PPP client—that is, a system that will connect to an ISP (or other PPP server) in order to communicate with the Internet. Setting up a Linux machine as a PPP server is also possible but is somewhat more involved; this is covered in the Linux Network Administrator's Guide (O'Reilly).
Basic PPP Configuration for Modems
In the U.S. and many parts of the world, people use traditional dial-up modems to send digital data over telephone lines. So we'll cover configuration for modems first. Then we'll show how to configure PPP for the faster and more convenient type of line called Integrated Services Digital Network (ISDN ), which is especially popular in Europe and is available but not very well marketed in most of the U.S.
Requirements
Most Linux systems come preinstalled with all the software needed to run PPP. Essentially, you need a kernel compiled with PPP support and the pppd daemon and related tools, including the chat program.
Most Linux distributions include PPP support in the preconfigured kernel or as a kernel module that is loaded on demand. However, it may be necessary to compile kernel PPP support yourself; this is a simple matter of enabling the PPP options during the kernel configuration process and rebuilding the kernel. PPP is usually compiled as a separate module, so it is sufficient to recompile only the kernel modules if this is the case. See "Building the Kernel" in Chapter 18 for information on compiling the kernel and modules.
The pppd and chat utilities are user-level applications that control the use of PPP on your system; they are included with nearly every Linux distribution. On Red Hat systems, these utilities are installed in /usr/sbin and are found in the ppp RPM package.
Also required for PPP usage is a modem that is compatible with both Linux and the type of modems used by your ISP's server. Most 14.4, 28.8, 56 K, and other standard modem types fit into this category; very few modem types are not supported by Linux, and it would be unusual for an ISP to use anything so esoteric as to require you to buy something else.
One type of modem to watch out for is the so-called Winmodem. This was originally a product sold by US Robotics but has now been produced in several varieties by other vendors. Winmodems use the host CPU to convert digital signals into analog signals so that they can be sent over the phone line, unlike regular modems, which have a special chip to perform this function. The problem with Winmodems is that, as of this writing, the programming details for these devices are proprietary, meaning that it is very difficult to write Linux drivers for this class of devices. A lot of work has been done nevertheless on Winmodem drivers, but your mileage using them may vary considerably. Things have become a lot better over the last few years, but we would not advise you to buy a Winmodem if you intend to use it on Linux. If your computer happens to have one built in (as laptops often do), you do have a chance of getting it to work, though (even though some people scoff at the idea of wasting precious CPU cycles to generate modem signals, a job best left to specialized hardware). One perceived advantage of these so-called software modems is that upgrading their functionality is simply a matter of upgrading the operating system driver that controls them, rather than buying new hardware.
Serial device names
Under Windows 95/98/ME and MS-DOS, modems and other serial devices are named COM1 (for the first serial device), COM2 (for the second), and so forth, up to COM4. (Most systems support up to four serial devices, although multiport cards are available that can increase this number.) Under Linux, these same devices are referred to as /dev/ttyS0, /dev/ttyS1, on up to /dev/ttyS3.[*] On most systems, at installation time a symbolic link called /dev/modem will be created. This link points to the serial device on which the modem can be found, as shown in the following listing:
% ls -l /dev/modem
lrwxrwxrwx 1 root root 10 May 4 12:41 /dev/modem -> /dev/ttyS0
If this link is incorrect for your system (say, because you know that your modem is not on /dev/ttyS0 but on /dev/ttyS2), you can easily fix it as root by entering:
# ln -sf /dev/ttyS2 /dev/modem
Setting up PPP
Several steps are involved in PPP configuration, and you may want to check first whether your distribution provides some kind of wizard for setting up PPP for you—many do. On the other hand, you won't learn as much as you do when setting things up by hand. The first thing you need to do if you want to roll your own is to write a so-called chat script, which performs the handshaking necessary to set up a PPP connection between your machine and the ISP. During this handshaking phase, various pieces of information might be exchanged, such as your ISP username and password. The second step is to write a script that fires up the pppd daemon; running this script causes the modem to dial the ISP and start up PPP. The final step is to configure your system's /etc/resolv.conf file so that it knows where to find a domain nameserver. We'll go through each step in turn.
Before you start, you need to know the following pieces of information:
§ The ISP dial-in account phone number
§ Your ISP username and password
§ The IP address of the ISP's domain nameserver
Your ISP should have told you this information when you established the account.
In addition, you might need to know the following:
§ The IP address of the ISP's server
§ The IP address of your system (if not dynamically assigned by the ISP)
§ The subnet mask you should use
These last three items can usually be determined automatically during the PPP connection setup; however, occasionally this negotiation does not work properly. It can't hurt to have this information in case you need it.
Writing a chat script
chat is a program that can perform simple handshaking between a PPP client and server during connection setup, such as exchanging usernames and passwords. chat is also responsible for causing your modem to dial the ISP's phone number and other simple tasks.
chat is automatically invoked by pppd when started (this is discussed later). All you need to do is write a simple shell script that invokes chat to handle the negotiation. A simple chat script is shown in the following example. Edit the file /etc/ppp/my-chat-script (as root) and place in it the following lines:
#!/bin/sh
# my-chat-script: a program for dialing up your ISP
exec chat -v \
'' ATZ \
OK ATDT555-1212 \
CONNECT '' \
ogin: mdw \
assword: my-password
Specifying ogin and assword without the initial letters allows the prompts to be either Login or login, and Password or password.
Be sure that the file my-chat-script is executable; the command chmod 755 /etc/ppp/my-chat-script will accomplish this.
Note that each line ending in a backslash should not have any characters after the backslash; the backslash forces line-wrapping in the shell script.
The third line of this script runs chat with the options on the following lines. Each line contains two whitespace-delimited fields: an "expect" string and a "send" string. The idea is that the chat script will respond with the send string when it receives the expect string from the modem connection. For example, the last line of the script informs chat to respond with my-password when the prompt assword is given by the ISP's server.
The first line of the handshaking script instructs chat to send ATZ to the modem, which should cause the modem to reset itself. (Specifying an expect string as '' means that nothing is expected before ATZ is sent.) The second line waits for the modem to respond with OK, after which the number is dialed using the string ATDT555-1212. (If you use pulse dialing rather than tone dialing, change this to ATDP555-1212. The phone number, of course, should be that of the remote system's modem line.)
When the modem responds with CONNECT, a newline is sent (indicated by '' as the send string). After this, chat waits for the prompt ogin: before sending the username, and waits for assword: before sending the password.
The various send strings starting with AT in the previous example are simply Hayes-modem-standard modem control strings. The manual that came with your modem should explain their usage; this is not specific to Linux or any other operating system. As one example, using a comma in a phone number indicates that the modem should pause before sending the following digits; one might use ATDT9,,,555-1212 if a special digit (9 in this case) must be dialed to reach an outside line.
Note that this is a very simple chat script that doesn't deal with timeouts, errors, or any other extraordinary cases that might arise while you're attempting to dial into the ISP. See the chat manual pages for information on how to spruce up your script to deal with these cases. Also, note that you need to know in advance what prompts the ISP's server will use (we assumed login and password). There are several ways of finding out this information; possibly, the ISP has told you this information in advance, or supplied a handshaking script for another system such as Windows 95 (which uses a mechanism very similar to chat). Otherwise, you can dial into the ISP server "by hand," using a simple terminal emulator such as minicom or seyon. The manpages for those commands can help you do this.
Starting up pppd
Now, we're ready to configure the pppd daemon to initiate the PPP connection using the chat script we just wrote. Generally, you do this by writing another shell script that invokes pppd with a set of options.
The format of the pppd command is
pppd device-name baudrate options
Table 13-1 shows the options supported by pppd. You almost certainly won't need all of them.
Table 13-1. Common pppd options
|
Option |
Effect |
|
lock |
Locks the serial device to restrict access to pppd. |
|
crtscts |
Uses hardware flow control. |
|
noipdefault |
Doesn't try to determine the local IP address from the hostname. The IP is assigned by the remote system. |
|
user username |
Specifies the hostname or username for PAP or CHAP identification. |
|
netmask mask |
Specifies the netmask for the connection. |
|
defaultroute |
Adds a default route to the local system's routing table, using the remote IP address as the gateway. |
|
connect command |
Uses the given command to initiate the connection. pppd assumes this script is in /etc/ppp. If not, specify the full path of the script. |
|
local_IP_address: remote_IP_address |
Specifies the local and/or remote IP addresses. Either or both of these could be 0.0.0.0 to indicate that the address should be assigned by the remote system. |
|
debug |
Logs connection information through the syslog daemon. |
It is common to invoke the pppd command from a shell script. Edit the file /etc/ppp/ppp-on and add the following lines:
#!/bin/sh
# the ppp-on script
exec /usr/sbin/pppd /dev/modem 38400 lock crtscts noipdefault \
defaultroute 0.0.0.0:0.0.0.0 connect my-chat-script
As with the my-chat-script file in the earlier example, be sure this is executable and watch out for extra characters after a backslash at the end of a line.
With this script in place, it should be possible to connect to the ISP using the following command:
% /etc/ppp/ppp-on
You need not be root to execute this command. Upon running this script, you should hear your modem dialing, and if all goes well, after a minute PPP should be happily connected. The ifconfig command should report an entry for ppp0 if PPP is up and running:
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
ppp0 Link encap:Point-to-Point Protocol
inet addr:207.25.97.248 P-t-P:207.25.97.154 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:1500 Metric:1
RX packets:1862 errors:0 dropped:0 overruns:0 frame:0
TX packets:1288 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
Memory:73038-73c04
Here, we can see that PPP is up, the local IP address is 207.25.97.248, and the remote server IP address is 207.25.97.154.
If you wish to be notified when the PPP connection is established (the ppp-on script returns immediately), add the following line to /etc/ppp/ip-up:
/usr/bin/wall "PPP is up!"
/etc/ppp/ip-up is executed when PPP establishes an IP connection, so you can use this script to trigger the wall command when the connection is complete.
Another simple shell script can be used to kill the PPP session. Edit the file /etc/ppp/ppp-off as follows:
#!/bin/sh
# A simple ppp-off script
kill `cat /var/run/ppp0.pid`
Running /etc/ppp/ppp-off now kills the PPP daemon and shuts down the modem connection.
Configuring DNS
By itself, use of pppd along with chat only establishes a PPP connection and assigns you an IP address; in order to use domain names, you need to configure the system to be aware of the domain nameserver provided by your ISP. You do this by editing /etc/resolv.conf. The manpage forresolver describes this file in detail. However, for most purposes it suffices to simply include lines of two forms: one that specifies the list of domains to search whenever a domain name is used, and another that specifies the address of a DNS server.
A sample /etc/resolv.conf file might look like this:
# Sample /etc/resolv.conf
search cs.nowhere.edu nowhere.edu
nameserver 207.25.97.8
nameserver 204.148.41.1
The first line indicates that every time a domain name is used (such as orange or papaya), it should be searched for in the list of specified domains. In this case, resolver software would first expand a name like papaya to papaya.cs.nowhere.edu and try to find a system by that name, then expand it to papaya.nowhere.edu if necessary and try again.
The lines beginning with nameserver specify the IP address of domain nameservers (which should be provided by your ISP) that your system contacts to resolve domain names. If you specify more than one nameserver line, the given DNS servers will be contacted in order, until one returns a match; in this way, one DNS server is treated as a primary and the others as backups.
Troubleshooting PPP configuration
The PPP configuration described here is meant to be very simple and will certainly not cover all cases; the best sources for additional information are the manpages for pppd and chat as well as the Linux PPP HOWTO and related documents.
Happily, both chat and pppd log messages on their progress, as well as any errors, using the standard syslog daemon facility. By editing /etc/syslog.conf, you can cause these messages to be captured to a file. To do this, add the following lines:
# Save messages from chat
local2.* /var/log/chat-log
# Save messages from pppd
daemon.* /var/log/pppd-log
This will cause messages from chat to be logged to /var/log/chat-log, and messages from pppd to be logged to /var/log/pppd-log.
Note that these log messages will contain private information, such as ISP usernames and passwords! It is important that you leave this logging enabled only while you are debugging your PPP configuration; after things are working, remove these two logfiles and remove the lines from/etc/syslog.conf.
chat will also log certain errors to /etc/ppp/connect-errors, which is not controlled through the syslog daemon. (It should be safe to leave this log in place, however.)
PAP and CHAP
Some ISPs may require you to use a special authentication protocol, such as PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol) . These protocols rely on some form of "shared secret" known to both the client and the server; in most cases, this is just your ISP account password.
If PAP or CHAP is required by your ISP, they are configured by adding information to the files /etc/ppp/pap-secrets and /etc/ppp/chap-secrets, respectively. Each file has four fields separated by spaces or tabs. Here is an example of a pap-secrets file:
# Secrets for authentication using PAP
# client server secret IP or Domain
mdw * my-password
The first field is your system's name as expected by the remote system—usually your ISP username. The second field specifies the ISP's server name; an asterisk allows this entry to match all ISP servers to which you might connect. The third field specifies the shared secret provided by your ISP; as stated earlier, this is usually your ISP password. The fourth field is primarily used by PPP servers to limit the IP addresses to which users dialing in have access. These addresses can be specified as either IP addresses or domain names. For most PPP client configurations, however, this field is not required.
The chap-secrets file has the same four fields, but you need to include an entry other than * for the service provider's system; this is a secret the ISP shares with you when you establish the account.
If PAP or CHAP is being used, it's not necessary for the chat script to include handshaking information after CONNECT is received; pppd will take care of the rest. Therefore, you can edit /etc/ppp/my-chat-script to contain only the following lines:
#!/bin/sh
# my-chat-script: a program for dialing up your ISP
exec chat -v \
'' ATZ \
OK ATDT555-1212 \
CONNECT ''
You will also need to add the user option to the pppd command line in /etc/ppp/ppp-on, as so:
#!/bin/sh
# the ppp-on script
exec /usr/sbin/pppd /dev/modem 38400 lock crtscts noipdefault \
user mdw defaultroute 0.0.0.0:0.0.0.0 connect my-chat-script
[*] Older versions of Linux also used special "callout" devices, called /dev/cua0 through /dev/cua3. These are obsolete as of Linux kernel Version 2.2.
PPP over ISDN
ISDN has offered convenient, high-speed data communications—at a price—for many years; it is particularly popular in Europe, where rates and marketing have been more favorable to its use than in the U.S. ISDN, which integrates data and regular voice transmission over a single line, offers both a faster connection setup and much better throughput than traditional modems.
ISDN lines can transfer 64 kbits per second. And unlike analog lines, they can achieve this speed all the time because their transmission does not depend on the vagaries of analog transmission with interference by various kinds of noise. A newer protocol called ADSL (Asynchronous Digital Subscriber Line) is upping the ante for fast data access over phone lines and is taking over from ISDN in many regions of the world.
In this section, we describe how to configure dial-up access to your Internet provider over an ISDN line. We cover only the most common style of connection, synchronous PPP, not the special mode called raw IP. Furthermore, this section discusses just internal ISDN boards, which require a kind of setup that's different from the dial-up access covered in the previous section. To set up external ISDN devices, or the so-called ISDN modems (a term that is an oxymoron because there is no modulation and demodulation), you can use commands similar to those in the previous section because these devices present themselves to the computer and the operating system like a normal modem, albeit one that offers some additional commands, faster connection setup, and higher throughput.
If you want more information beyond what we present here, the source for all ISDN-related information for Linux is http://www.isdn4linux.de (despite this domain being registered in Germany, all the information here is in English).
In a way, setting up ISDN connections is much easier than setting up analog connections because many of the problems (bad lines, long connection setup times, and so on) simply cannot occur with digital lines. Once you dial the number, the connection is set up within milliseconds. But this can lead to problems. Because the connections are set up and shut down so fast, a misconfigured system that dials out again and again can cost you a fortune. This is even more problematic because with internal ISDN cards, you hear no clicking and whistling as you do with modems, and there are no lights that inform you that a connection has been made. You can check the status of your ISDN line with some simple programs, though.
Follow these two steps to set up dial-up PPP over ISDN:
1. Configure your ISDN hardware.
2. Configure and start the PPP daemon and change the routing table to use your ISDN line.
We cover those steps in the next sections.
Configuring Your ISDN Hardware
The first step involves making your ISDN board accessible to the kernel. As with any other hardware board, you need a device driver that is configured with the correct parameters for your board.
Linux supports a large number of ISDN hardware boards. We cannot cover every single board here, but the procedure is more or less the same for each one. Reading the documentation for your specific card in the directory Documentation/isdn in the Linux kernel sources will help you a lot if your board is not covered here.
We will concentrate here on boards that use the so-called HiSax driver. This device driver works with almost all cards that use the Siemens HSCX chipset (and thus with most passive cards available on the market today). That includes, for instance, the USR Sportster internal TA and the well-known Teles, ELSA, and Fritz boards. Other boards are similarly configured. Even some active cards are supported by Linux, including the well-known AVM B1 and the IBM Active 2000 ISDN card.
The first thing you need to do is configure the kernel so that it includes ISDN support. We advise you to compile everything ISDN-related as modules, especially while you are experimenting with setting it up. You will need the following modules:
§ ISDN support.
§ Support for synchronous PPP.
§ One device driver module for your hardware. If you pick the HiSax driver, you will also have to specify which specific brand of ISDN card you have and which ISDN protocol you want to use. The latter is almost certainly EURO/DSS1 in Europe—unless you live in Germany and have had your ISDN for a long time, in which case it might be 1TR6—and US NI1 in the U.S. If you live elsewhere, or are in doubt, ask your phone company.
Compile and install the modules as described in Chapter 18. Now you are ready to configure your ISDN hardware. Some distributions, such as SUSE, make setting up ISDN lines very easy and comfortable. We cover the hard way here in case your distribution is not so user-friendly, the automatic configuration does not work, or you simply want to know what is going on behind the scenes.
Now you need to load the device driver module using modprobe. This will automatically load the other modules as well. All the device driver modules accept a number of module parameters; the hisax module accepts, among others, the following:
id= boardid
Sets an identifier for the ISDN board. You can pick any name you like here, but you cannot have the same identifier for more than one board in your system.
type= boardtype
Specifies the exact board brand and type. For example, a value of 16 for boardtype selects the support for the USR Sportster internal TA. See Documentation/isdn/README.hisax in the kernel sources for the full list of board types.
protocol= protocoltype
Selects an ISDN subprotocol. Valid values for protocoltype are 1 for the old German 1TR6 protocol, 2 for the common EDSS1 (so-called Euro ISDN), and 3 for leased lines.
irq= irqno
Specifies the interrupt line to use. Not all boards need this.
io= addr
Specifies the I/O address to use. Not all boards need this. Some boards need two I/O addresses. In this case, the parameters to use are io0 and io1.
For example, the following command loads the HiSax driver for use with a Teles 16.3 board, Euro ISDN, IO address 0x280, and IRQ line 10 (a very common case):
tigger # modprobe hisax type=3 protocol=2 io=0x280 irq=10
Please see Documentation/isdn/README.HiSax or the equivalent file for your hardware for more information.
This module is not much of a talker; if there is no output from the modprobe command, it is likely that everything went well. You might also want to check your system log at /var/log/messages. You should see a few lines starting with HiSax: (or the name of the driver you are using); the final line should be
HiSax: module installed
If the module did not load, you will most likely also find the answer in /var/log/messages. The most common problem is that the IRQ or I/O address was wrong or that you selected the wrong card type. If all else fails, and you have Windows installed on the same machine, boot up Windows and check what it reports for the IRQ and I/O address lines. Sometimes, it helps to take a look in /proc/ioports and in /proc/interrupts to see if the HiSax chipset has the right I/O port and the right interrupt assigned.
You should do one more check before you jump to the next section, and this check involves calling yourself. This can work because, with ISDN, you always have two phone lines at your disposal. Thus, one line will be used for the outgoing "phone call," and the other line will be used for the incoming one.
In order to have the ISDN subsystem report what is going on with your phone lines, you will need to configure it to be more verbose than it is by default. You do this by means of three utility programs that are all part of the isdn4k-utils package that you can find at your friendly Linux FTPserver around the corner.
The isdn4k-utils package contains, among other things, the three utilities hisaxctrl for configuring the device driver, isdnctrl for configuring the higher levels of the ISDN subsystem, and isdnlog, a very useful tool that logs everything happening on your ISDN lines. Although you can usehisactrl and isdnctrl without any configuration, you will need to provide a small configuration file for isdnlog. For now, we will content ourselves with a quick solution, but once your ISDN connection is up and running, you will want to configure isdnlog to see where your money is going. So for now, copy one of the sample configuration files contained in the isdnlog package to /etc/isdn/isdn.conf. You will need to edit at least the following lines:
COUNTRYCODE=
Add your phone country code here—for example, 1 for the U.S. and Canada, 44 for the United Kingdom, 46 for Sweden, and so on.
AREAPREFIX=
If the area codes in your country are prefixed by a fixed digit, put this in here. The prefix is 0 for most European countries, 9 for Finland, and nothing for the U.S., Denmark, and Norway.
AREACODE=
Put your area code in here. If you have specified an AREAPREFIX in the last step, don't repeat that here. For example, Stockholm, Sweden, has the area code 08. You put 0 into AREAPREFIX and 8 into AREACODE.
Once you have set this up, execute the following commands to make your ISDN system more verbose:
tigger # /sbin/hisaxctrl boardid 1 4
tigger # /sbin/isdnctrl verbose 3
tigger #/sbin/lsdnlog /dev/isdnctrl0 &
If you are using a driver other than HiSax, you might need to use a different command. For example, for the PCBit driver, the command pcbitctl is available in the isdn4k-utils package.
Now you can go ahead and phone yourself. You should try all your MSNs (multiple subscriber numbers, which are your ISDN phone numbers) to see that the board can detect all of them. During or after each call, check /var/log/messages. You should see lines like the following:
Mar 16 18:34:22 tigger kernel: isdn_net: call from 4107123455,1,0 -> 123456
Mar 16 18:34:33 tigger kernel: isdn_net: Service-Indicator not 7, ignored
This shows that the kernel has detected a voice call (the service indicator is 0) from the phone number 123455 in the area with the area code (0)4107 to the MSN 123456.
Note how the number called is specified, because you will need this information later. The number is sent with the area code in some phone networks, but without the area code in others. Anyway, congratulations if you have come this far. Your ISDN hardware is now correctly configured.
Setting Up Synchronous PPP
Setting up the PPP daemon again involves several substeps. On Linux, the ISDN board is treated like a network interface that you have to configure with special commands. In addition, you need to specify the username and password that your ISP has assigned you. When everything is configured, you start up the ipppd daemon, which lurks in the background until a connection request is made.
First, let's configure the "network interface." This involves a number of commands that most system administrators simply put into a script that they store in a file, such as /sbin/pppon. Here is a sample file that you can modify to your needs:
/sbin/isdnctrl addif ippp0
/sbin/isdnctrl addphone ippp0 out 0123456789
/sbin/isdnctrl dialmax ippp0 2
/sbin/isdnctrl eaz ippp0 123456
/sbin/isdnctrl huptimeout ippp0 100
/sbin/isdnctrl l2_prot ippp0 hdlc
/sbin/isdnctrl l3_prot ippp0 trans
/sbin/isdnctrl encap ippp0 syncppp
/sbin/ifconfig ippp0 1.1.1.1 pointopoint 123.45.67.89 metric 1
Let's go through these commands one by one.
isdnctrl addif ippp0
Tells the kernel that a new ISDN interface with the name ippp0 will be used. Always use names starting with ippp.
isdnctrl addphone ippp0 out 0123456789
Tells the ISDN interface which phone number to use. This is the phone number that you use to dial up your provider. If you have used analog dial-up so far, check with your provider, because the phone number for ISDN access could be different.
isdnctrl dialmax ippp0 2
Specifies how many times the kernel should dial if the connection could not be established, before giving up.
isdnctrl eaz ippp0 123456
Specifies one of your own MSNs. This is very important—without this, not much will work. In case your provider verifies your access via your phone number, make sure you specify here the MSN that you have registered with your provider.
isdnctrl huptimeout ippp0 100
Specifies the number of seconds that the line can be idle before the kernel closes the connection (specified by the last number in this command). This is optional, but can save you a lot of money if you do not have a flat phone rate. Thus, if you forget to shut down the connection yourself, the kernel will do that for you.
isdnctrl l2_prot ippp0 hdlc
Specifies the layer 2 protocol to use. Possible values here are hdlc, x75i, x75ui, and x75bui. Most providers use hdlc. When in doubt, ask your provider.
isdnctrl l3_prot ippp0 trans
Specifies the layer 3 protocol to use (the l in the option is the letter L). Currently, only trans is available.
isdnctrl encap ippp0 syncppp
Specifies the encapsulation to use. A number of values are possible here, but if you want to use synchronous PPP (or your provider demands that), you have to specify syncppp here. Another not-so-uncommon value is rawip. But since this provides only very weak authentication facilities, few providers still use it, even though it gives slightly better throughput because it requires less overhead.
ifconfig ippp0 1.1.1.1 pointopoint 123.45.67.89 metric 1
Creates the new network interface. If your IP address is not assigned dynamically (as is the case with most dial-up connections), you need to specify your IP address instead of the 1.1.1.1 here. Also, you need to change the 123.45.67.89 to the IP address of your provider's dial-up server.
If you want, you can also reverse the setup by creating a script that shuts down the interfaces and so on. For example, it would use the isdnctrl delif command. But such a script is not strictly necessary, unless you want to disable all dialing at runtime.
Phew! But we are not finished yet. Next, you need to configure the ipppd daemon, which you do in the file /etc/ppp/ioptions. You can also have a configuration file specific to each ipppd daemon, but that is necessary only if you want to be able to use different ISDN connections—that is, if you have multiple dial-up accounts.
The following is an ioptions file that is generic enough to work with most providers. It does not give maximum throughput but is quite stable. If you want to optimize it, ask your provider about the possible settings and read the manual page for ipppd(8):
debug
/dev/ippp0
user yourusername
name yourusername
mru 1500
mtu 1500
ipcp-accept-local
ipcp-accept-remote
noipdefault
-vj -vjccomp -ac -pc -bsdcomp
defaultroute
You have to change only two things here: change yourusername in the third and fourth lines to the username that your provider has assigned you for connecting to its system. We won't go through all the options here; see the manual page when in doubt.
ISDN access requires the same security as an analog modem. See "PAP and CHAP," earlier in this chapter, for directions on setting up your pap-secrets or chap-secrets file as required by your service provider.
Now we have got our things together and can start having fun! First run the ipppd daemon:
tigger # /sbin/ipppd pidfile /var/run/ipppd.ippp0.pid file /etc/ppp/ioptions &
The ipppd daemon will now wait for connection requests. Since we have not configured it yet to automatically make a connection, we have to manually trigger the connection. You do this with the following command:
tigger # isdnctrl dial ippp0
You should now check /var/log/messages. There should be lots of messages that start with ipppd. The last of those messages should contain the words local IP address and remote IP address together with the IP addresses. Once you find those messages, you are done. Because we have used the defaultroute option previously, the kernel has set up the default route to use the ISDN connection, and you should now be able to access the wide, wide world of the Internet. Start by pinging your provider's IP address. Once you are done and want to shut down the connection, enter
tigger # isdnctrl hangup ippp0
If you have a flat rate with your ISP, then you can set the huptimeout to 0, and you will stay online all the time without ever hanging up. Of course, this is nice to have, but remember that most ISPs reset the connection after 24 hours, and if you have a dynamic IP address, you will possibly be assigned another IP address every 24 hours.
And If It Does Not Work?
If you have no connection even though your hardware was successfully recognized and you have set up everything as described here, /var/log/messages is again your friend. It is very likely that you will find the cause of the error there, even though it might be buried a bit.
The most common error is specifying the password or the username incorrectly. You know that you have a problem with the authentication if you see a line such as:
PAP authentication failed
or
CHAP authentication failed
in the logfile. Check your chap-secrects or pap-secrets file very carefully. Your provider might also be able to see from its logfiles where exactly the authentication went wrong.
Of course, your provider might not support synchronous PPP as described here, even though most providers do nowadays. If this is the case, ask your provider for exact settings.
If it still does not work, ask your provider. A good ISP has a phone support line and can help you connect your Linux box. If your provider tells you that it "only supports Windows," it's time to switch. Many Linux-friendly providers are out there. Often the support staff is using Linux and can help you even though the provider's official policy is not to support Linux.
If for some reason you are stuck with an uncooperative provider, try finding other customers of this provider who also use Linux. Setting up your connection in nonstandard cases means fiddling with the options and parameters of the ISDN subsystem in the kernel and the ipppd daemon, and if somebody else has already found out what to do, you don't have to.
Where to Go from Here?
Once your ISDN connection works and you can access the Internet, you might want to set up some conveniences or other customizations. Here are some suggestions:
§ Make ipppd dial your remote site automatically. You can do this by setting the default route to the ippp0 device like this:
/sbin/route add default netmask 0.0.0.0 ippp0
Now, whenever the kernel needs to send an IP packet to an IP address for which it has no specific route configured, it will trigger the ipppd daemon to build a connection. Use this only if you have also specified the huptimeout option of the ISDN subsystem; otherwise, you could pay a fortune to your telephone company (unless you have a flat rate).
Since some programs try to build up Internet connections from time to time (Netscape is one of those candidates), setting this up can be dangerous for your wallet. If you use this, make sure to check the state of the connection often (as described later in this section).
§ Try tools that monitor your ISDN connection. The isdn4k-utils package contains a number of those tools, including the command-line tools imon and imontty and X-based tools.
§ Configure isdnlog to log exactly what you need, and use isdnrep to get detailed reports about the usage of your ISDN line. This works not only for calls to and from computer systems, but also for calls to other ISDN-enabled devices such as phones and fax machines. There is only one caveat: your ISDN board cannot capture outgoing phone numbers for connections being set up by other devices. Most telephone companies provide a service, though, that echoes this phone number back to you and thus lets the ISDN subsystem pick it up. This service is often available for free or for a nominal fee. Ask your telephone company.
§ For the truly adventurous: experiment with Multilink-PPP. As you know, with ISDN you have at least two lines. If you need extra-high capacity, why not use both? That's what Multilink-PPP does. To use this, you need to turn on the Support generic MP option during kernel configuration, and read the files Documentation/isdn/README.syncppp and Documentation/isdn/syncppp.FAQ in the kernel sources for hints on how to do this. Of course, your provider has to support this, too.
ADSL
The 64-Kbps rate that ISDN supports is nice, but if you want to access multimedia files via the Internet or simply are using the Internet a lot, you may want even more bandwidth. Without drawing additional cables to your house or office, ADSL (Asynchronous Digital Subscriber Line), a variant of DSL (Digital Subscriber Line), is a convenient alternative that gives you up to 128 times (depending on your provider and your type of subscription) the bandwidth of standard dial-up access and is run via your ordinary telephone line. A drawback with ADSL is that it only works within a distance of about 5 to 8 kilometers (3 to 5 miles), depending on cable quality around the next switching station, which makes this service unavailable in rural areas. Typical bandwidths are 0.5 to 8 Mbps (megabits per second) downstream (to your computer—download operations, including viewing web pages and retrieving email) and 0.125 to 1 Mbps upstream (from your computer—upload operations, including sending email). Note that there are other technologies with similar-sounding names, such as SDSL. Although these are fundamentally different on the wire level, setting them up on your Linux box should be no different from ADSL.
ADSL is not dial-up access; once you have logged into your account, you are always connected. Some providers cut your connection after a while (often after 24 hours), upon which you have to log in again in order to regain access.[*]
As we have already mentioned, there are no such things as ADSL cards or ADSL drivers. As far as hardware is concerned, an ADSL connection is just a normal Ethernet connection, using the same cables.
How you connect your Linux box to your ADSL line depends a lot on your ISP. With some ISPs, you rent the necessary equipment, such as an ADSL modem and an ADSL router, as part of your subscription. With others, you have to purchase the necessary hardware yourself, either on the free market or from the ISP. Your ISP can give you all the information you need.
There are two ways to use ADSL: either connecting directly to an ADSL modem or with an intervening ADSL router. If you have an ADSL router (either with a built-in ADSL modem, or in addition to one), you plug your Ethernet cable in there and are ready for action. If you want to connect your Linux box directly to your ADSL modem, you still connect the computer and the modem with an Ethernet cable, but you need to run a special protocol, called PPPoE (PPP over Ethernet), on it. This protocol is handled by a special daemon called pppoed. How this is set up depends on your distribution and should be documented there. Some distributions also let you set up PPPoE from their respective configuration programs.
Finally, we should mention that a small number of weirdo ADSL modems are not connected with an Ethernet cable , but rather with a USB cable. This is technically a bad idea, so you should avoid these modems if possible, but if you are stuck with one, you can find more information, including drivers for some devices that run PPPoE on a USB connection (that would be PPP over Ethernet over USB, then!), at http://eciadsl.flashtux.org and http://speedtouch.sourceforge.net.
Whichever way you use ADSL (with or without an ADSL router), you need to set up the correct IP address. This can either be static (in which case you should find it in the information you have received from your ISP) or dynamic and assigned via DHCP (Dynamic Host Communication Protocol), in which case you can request a dynamic IP address with the following command:
dhclient eth0
Of course, if the Ethernet card you use has another name, you need to replace the eth0 with the correct name. Instead of dhclient, you can also use the utility pump. There is also a DHCP daemon called dhcpcd that runs in the background and assigns a dynamic IP address whenever necessary.
Finally, many ISPs require that you activate your line from time to time. How you do this depends on your ISP, but often the activation requires nothing more than browsing to a certain web site and entering the credentials there that your ISP has assigned to you. As mentioned before, you may have to repeat this step from time to time.
[*] The reason why the providers do this is that they want to prevent you from running a server, coercing you into upgrading to a more expensive "business" subscription if you wish to do that.
Cable Modems
When one wants Internet access enough, any wire will do. There are intensive experiments to use even the electricity grid to deliver Internet access. So it's not surprising that companies that built their business plans on delivering laser-crisp pictures of sporting events (the cable TV firms) would realize they could devote one of their channels to a local area network carrying digital data—hence the advent of cable Internet access.
The bandwidth on the cable infrastucture theoretically ranges up to 10 Mb (like an old Ethernet on coaxial cable), but some providers today achieve more throughput. Usually, they span a web of nodes, each of which offers 10 Mb or less. The neighbors who share the node have to share the bandwidth. So if there are two users on the node, each gets 5 Mb. Furthermore, some customers near the center (the central server, which is usually connected via the optical fiber cable to the rest of the Internet) have more bandwidth than those at the periphery. So check your cable network very carefully before you sign up for Internet access. Talk to the technical support first, and if they cannot answer your question, this might be a good indication about how good their support is going to be later.
ISPs that sell clients Internet access through cable modems will usually take responsibility for service all the way to your Ethernet card. They will give you a cable modem with a coaxial cable connected to their cable infrastructure, and an Ethernet (RJ45) connector on your side. To set up your Internet connection, you will need to know the IP address assigned to the cable modem, the network mask, and the gateway; your ISP should provide you with this information together with the cable modem. On your side, you need only start up your (carefully configured) Ethernet card with the data provided to you by your ISP:
/sbin/ifconfig eth0 IP_address netmask
Next, tell the kernel about the gateway:
/sbin/route add default gw gateway metric 1
This is the setup for a standalone Linux workstation. If you plan to run a small network behind the Linux machine, you will have to use masquerading, as described earlier in this chapter; you can find help for this in a book that covers Linux firewalling, such as the Linux Network Administrator's Guide and the Linux iptables Pocket Reference (O'Reilly). Some Linux distributions, such as Slackware, turn off IP forwarding by default, which means that masquerading will not work. If this is the case, add the following line to your startup script:
echo 1 >/proc/sys/net/ipv4/ip_forward
All cable modems can be configured remotely. If you are unlucky and have an ISP that does not configure the cable modem for you, you have to configure it from scratch; this will require more than average knowledge about how TCP/IP works, and you should probably seek assistance from your ISP (or switch to one that does configure the modem for you).
In some cases, the cable modem is configured such that it is works only with one particular Ethernet card, and you have to give the MAC address of your card to your ISP for configuration purposes. If this is the case, you need to ask your ISP to reconfigure the modem in case you should switch Ethernet cards (or computers).
Network Diagnostics Tools
There are a number of useful tools that can help you diagnose network problems. We discuss three of them here that are generally helpful; a host of others for diagnosing particular problems are available as well.
ping
The first tool we look at is called ping. ping sends so-called ICMP packets to the server that you specify, the server returns them, and the ping determines the time the round trip took. This is useful to get an idea of the quality of your Internet connection, but we most often use it to see whether we can get a connection somewhere at all. For example, to see whether you have an Internet connection, just ping any computer on the Internet. For example:
kalle@tigger:~> ping www.oreilly.com
PING www.oreilly.com (208.201.239.36) 56(84) bytes of data.
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=1 ttl=46 time=280 ms
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=2 ttl=46 time=250 ms
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=3 ttl=46 time=244 ms
--- www.oreilly.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 244.976/258.624/280.430/15.586 ms
Notice that we pressed Ctrl-C here after a few seconds—it is not very nice to use the opposite server for this purpose for too long. What can you see from this? Well, first of all, you can see that you are actually able to contact a computer on the Internet. Since you did not type in the numerical IP address, but rather the hostname, you can also see that DNS name resolution worked. The first line of the output shows you the IP address that belonged to www.oreilly.com. In the following lines, you can see for each packet sent how long the trip to the server and back took. Of course, the times reported here are going to differ greatly depending on how far that server is away from you network-wise. Also notice the icmp_seq information. Each packet gets a sequence number, and you should receive all of them back. If you don't, if there are gaps in the sequence, then your connection to that host is flakey, or maybe the host is overloaded and drops packets.
It should also be said that ping is not completely reliable for diagnosing network problems. Getting no ping response may also be due to the server not responding to the ICMP packets—no server is obliged to do so, and some actually don't, in order to reduce their server load and in order to increase security (if you cannot really know that somebody is there, it is difficult to attack that somebody). It is considered good networking practice, though, to answer ping requests.
ping is also interesting to see what does not work. If ping does not answer at all, or only answers with network not reachable or a similar output, you know that you have issues with your setup. If you know it, try to ping the IP address of your ISP to see whether the problem is between you and your ISP or further beyond.[*] If you are using a router that connects your home network with the Internet, ping the IP address of the router; if this already does not work, then it is either the setup of your local computer or the cabling that is faulty. If this works, but you do not get any further to your ISP, then the reason could be that you failed to connect with your ISP, for example, because you have specified the wrong credentials for connecting, or your ISP is down, or there is a problem with the phone line (your telephone company might be experiencing problems).
Finally, if specifying the hostname does not work, but you know its IP address (maybe from an earlier attempt), and specifying the hostname works:
kalle@tigger:~/projects/rl5> ping 208.201.239.36
PING 208.201.239.36 (208.201.239.36) 56(84) bytes of data.
64 bytes from 208.201.239.36: icmp_seq=1 ttl=46 time=249 ms
--- 208.201.239.36 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1001ms
rtt min/avg/max/mdev = 249.698/249.698/249.698/0.000 ms
then you know that you have a problem with DNS name resolution and can continue to look further in that area.
traceroute
The traceroute command goes a step further than ping. It not only shows you whether you can reach a host on the Internet (or in your own network), but also which route the packets take on their way to get there. That can be useful to diagnose problems that are beyond your reach, such as with central routers on the Internet—not that you could do much about that, but then at least you know that you do not need to debug your own setup.
Here is an example of using traceroute. Notice that here we specify the full path to the command. It is usually in a directory that only root has in its PATH. traceroute can be executed just fine as a normal user, however).
kalle@officespace:~> /usr/sbin/traceroute www.oreilly.com
traceroute to www.oreilly.com (208.201.239.36), 30 hops max, 40 byte packets
1 81.169.166.1 0.204 ms 0.174 ms 0.174 ms
2 81.169.160.157 0.247 ms 0.196 ms 0.195 ms
3 81.169.160.37 0.351 ms 0.263 ms 0.320 ms
4 PC1.bln2-g.mcbone.net (194.97.172.145) 0.256 ms 0.273 ms 0.217 ms
5 L0.bln2-g2.mcbone.net (62.104.191.140) 0.417 ms 0.315 ms 0.272 ms
6 lo0-0.hnv2-j2.mcbone.net (62.104.191.206) 4.092 ms 4.109 ms 4.048 ms
7 lo0-0.hnv2-j.mcbone.net (62.104.191.205) 4.145 ms 4.184 ms 4.266 ms
8 L0.dus1-g.mcbone.net (62.104.191.141) 8.206 ms 8.044 ms 8.015 ms
9 c00.ny2.g6-0.wvfiber.net (198.32.160.137) 92.477 ms 92.522 ms 92.488 ms
10 b0-00.nyc.pos1-35-1.wvfiber.net (63.223.28.9) 166.932 ms 167.323 ms 166.356
ms
11 b00.chi.pos1-6-1.wvfiber.net (63.223.0.214) 167.921 ms 166.610 ms 166.735 ms
12 63.223.20.53 166.543 ms 166.773 ms 166.429 ms
13 unknown63223030025.wvfiber.net (63.223.30.25) 166.182 ms 165.941 ms 166.042
ms
14 unknown63223030022.wvfiber.net (63.223.30.22) 165.873 ms 165.918 ms 165.919
ms
15 unknown63223030134.wvfiber.net (63.223.30.134) 165.909 ms 165.919 ms 165.832
ms
16 ge7-br02-200p-sfo.unitedlayer.com (209.237.224.17) 165.987 ms 165.881 ms
166.022 ms
17 pos-demarc.sf.sonic.net (209.237.229.26) 168.849 ms 168.753 ms 168.986 ms
18 0.at-0-0-0.gw4.200p-sf.sonic.net (64.142.0.182) 169.628 ms 0.at-1-0-0.
gw4.200p-sf.sonic.net (64.142.0.186) 169.632 ms 169.605 ms
19 0.ge-0-1-0.gw.sr.sonic.net (64.142.0.197) 173.582 ms 173.877 ms 174.144 ms
20 gig49.dist1-1.sr.sonic.net (209.204.191.30) 176.822 ms 177.680 ms 178.777 ms
21 www.oreillynet.com (208.201.239.36) 173.932 ms 174.439 ms 173.326 ms
Here, the trace was successful, and you can also see how much time the packets took from hop to hop. With some geographical knowledge and some fantasy, you can guess the route along which the packets went. For example, the computer on which this command was executed was located in Berlin, Germany,[*] so it stands to reason that bln2 in lines 4 and 5 is some host in Berlin that belongs to the ISP somehow. Looking at a map of Germany, you might be able to guess that hops 6 and 7 went via Hanover, and hop 8 was in Düsseldorf. That's apparently also where the cable across the big pond starts, because hops 9 and 10 were quite likely in New York City. 11 seems to be Chicago, and 16 to 18 could be San Francisco. That makes sense, given that O'Reilly's headquarters (and therefore the likely location of the machine www.oreilly.com/www.oreillynet.com) is in California.
dig
dig is the last diagnostic utility we cover in this section. dig is a utility that queries DNS servers and returns the information held about a particular domain. Let's start with an example right away:
kalle@tigger:~> dig oreilly.com
; <<>> DiG 9.3.1 <<>> oreilly.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52820
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;oreilly.com. IN A
;; ANSWER SECTION:
oreilly.com. 21600 IN A 208.201.239.36
oreilly.com. 21600 IN A 208.201.239.37
;; AUTHORITY SECTION:
oreilly.com. 21600 IN NS ns2.sonic.net.
oreilly.com. 21600 IN NS ns.oreilly.com.
oreilly.com. 21600 IN NS ns1.sonic.net.
;; Query time: 252 msec
;; SERVER: 195.67.199.9#53(195.67.199.9)
;; WHEN: Wed Jul 6 13:31:02 2005
;; MSG SIZE rcvd: 123
Now what does this tell you? Have a look at the ANSWER SECTION. It tells you the IP addresses in use by the domain name service serving the domain oreilly.com. If you have a problem resolving addresses in this domain, you could try to ping these addresses to see whether the problem is actually with O'Reilly's DNS and not your own. The AUTHORITY SECTION gives you information about the so-called authoritative nameservers for this domain—the ones that are supposed to always give you the correct answer. It is good network administration practice to have at least two, and preferably three, of them, and to have them in different networks, so that the DNS service still works when one of them is down.
The third line from the bottom tells you the nameserver that was used to perform the DNS query; this is taken from your own setup. You can use this information to see whether you have entered the correct information in your DNS setup.
You can also specify a particular nameserver to query. For example, if you wanted to use the nameserver running at 195.67.199.10 instead, you could use:
dig @195.67.199.10 oreilly.com
Normally, you should get exactly the same result, but if you get a result at all from one of them but not from the other, then it's likely that the one not responding is simply down, or, per your network configuration, not reachable.
[*] Computer users are using ping as a verb these days.
[*] While the author was remotely logged in via ssh from Sweden, thanks to the Internet.