Obtaining a NetBEUI Stack for Linux

Few Linux computers participate in NetBEUI communications because the standard kernel lacks a NetBEUI stack. In 2000, Procom Technologies (http://www.procom.com) released an open source NetBEUI stack for Linux, as well as patches to Samba (described in Chapter 7, File and Printer Sharing via Samba), to allow Samba to operate over NetBEUI rather than TCP/IP. These patches have not become commonplace, and in fact they aren't posted directly on Procom's Web site, although you can request the stack from their technical support department. The NetBEUI stack may not work properly with kernels beyond the 2.0.x series (I was unable to get the patches to compile with a 2.2.18 kernel, for instance). The NetBEUI stack was also designed for versions of Samba before 2.0.7, although there's been some talk of adding the NetBEUI support to Samba sometime before Samba 3.0 is released. The support also requires recompiling both your kernel and Samba. For these reasons, you're probably better off foregoing the use of NetBEUI unless you have a very compelling reason to use it, such as a network on which TCP/IP is forbidden. If you really must use NetBEUI, you may need to use it with an older 2.0.x kernel and Samba 2.0.6 or earlier.

In addition to patching the Linux kernel and Samba, the NetBEUI stack comes with a number of tools that let you configure and manipulate it. This configuration tends to be fairly simple, and in most cases you'll use new Samba options to control the computer's NetBEUI behavior, but the separate utilities can be useful for troubleshooting and for learning more about NetBEUI. One utility in particular, netb, is also required to start up the NetBIOS stack, as described shortly.

NetBEUI

NetBEUI is similar in many ways to AppleTalk and IPX, but it has historically been used primarily by IBM and Microsoft as the basis for networking in DOS, Windows, and OS/2. The Linux kernel does not, as of the 2.4.x series, include a standard NetBEUI stack. This omission is offset by two facts, though. First, the common uses of NetBEUI can be served by NetBIOS over TCP/IP (sometimes called NBT), which Linux does support. Second, a third-party NetBEUI stack is available, although it's of limited utility.

NetBEUI Features and Capabilities
Like AppleTalk and IPX, NetBEUI was designed with small networks in mind. In fact, NetBEUI is even more limited than its competing small-network protocols, because it's restricted to networks of just 256 computers. NetBEUI uses computer names similar to TCP/IP hostnames, but there is no underlying numeric addressing system, as is true of TCP/IP, AppleTalk, and IPX; NetBEUI uses the computer's name directly. These names are two-tiered in nature, much like AppleTalk's names (which include a computer name and a network zone name). NetBEUI calls its higher-order groupings workgroups or domains, depending upon whether a centralized computer exists to control logins (domains support this feature, but workgroups leave authentication to individual servers). When it starts up and periodically thereafter, a computer configured to use NetBEUI makes a broadcast to announce its presence.

NetBEUI can theoretically be used over just about any network medium, but it's most commonly used over Ethernet. Like AppleTalk and IPX, NetBEUI can coexist on Ethernet with TCP/IP or other network stacks.

NetBEUI is most frequently used in conjunction with the SMB/CIFS file- and printer-sharing protocols. These are comparable in scope to NFS/lpd for Unix and Linux, AppleTalk's equivalent protocols, or NCP. They can also be used over TCP/IP, and in fact this configuration is very common, even on networks that contain Windows computers exclusively. Because it's not easily routed, however, NetBEUI offers some security benefits—a distant attacker is unlikely to be able to launch a successful attack against a NetBEUI server.

Using Linux IPX/SPX Software

Like most Linux software, Linux's IPX/SPX software is largely open source. (Caldera once licensed NetWare from Novell and made it available for Linux, but Caldera has discontinued this official port of NetWare. A three-user version is still available from ftp://ftp.calderasystems.com/pub/old-products/netware/, but it requires an old 2.0.35 kernel.) Other IPX/SPX tools for Linux include the following:

• Kernel NCPFS support— The Linux kernel includes support for the NCP filesystem in the Network File Systems submenu of the File Systems menu. This support allows a Linux computer to mount NetWare file shares. You need the ncpmount program, which usually ships in a package called ncpfs, to accomplish this task.
• LinWare— This package provides limited NCP server support. At the time of this writing, however, the current version is 0.95 beta, which was designed for the 1.3.x kernels—in other words, the software hasn't been updated since 1996. This might change in the future, though. The package is housed under the name lwared at ftp://sunsite.unc.edu/pub/Linux/system/network/daemons/.
• Mars_nwe— This is another NetWare server package for Linux. This package is hosted at http://www.compu-art.de/mars_nwe/, which is largely in German. English documentation is in the Mars_nwe HOWTO document, http://www.redhat.com/support/docs/tips/Netware/netware.html. Mars_nwe supports both file and print services. Its primary configuration file is /etc/nwserv.conf or /etc/nwserv/nwserv.conf, and it can be started by typing nwserv, if it's not started automatically by a startup script.

All of these IPX/SPX packages require you to have IPX support compiled into your kernel, as described in Chapter 1. Some distributions also require a separate package, usually called ipxutils, which contains utilities for activating and controlling the IPX/SPX network stack. (Alternatively, some distributions include these tools in the ncpfs package.)

If you intend to run a server for NetWare clients, Mars_nwe configuration is usually not too difficult, because the default configuration works fairly well. The configuration file is also usually very well commented, so you can learn how to configure it by reading its comments. You should pay particular attention to a few details:

• Section 1 of the file defines the volumes that are to be shared. In Linux terms, these are directories. The configuration file that ships with your copy of the server may or may not define volumes that you'd want to share.
• Section 7 controls password encryption options. You may need to enable nonencrypted passwords if your network doesn't have a regular NetWare bindery server—a computer that handles authentication.
• Section 13 defines users who are to be allowed access to the server. You may need to add usernames and passwords to this section, duplicating the regular Linux username and password configuration. Passwords are stored in an unencrypted form, which is a potential security flaw. If the network has a bindery, though, you can remove these entries after starting Mars_nwe for the first time, so the security risk may not be as bad as it first appears. Instead of dealing with individual accounts, you can set up Section 15 to do this automatically, but the drawback is that all the accounts will have the same password.

The Mars_nwe package includes the means to automatically enable IPX support on your network interface. This convenience doesn't exist in the case of Linux's NetWare client support as implemented in ncpmount, however. Before you can use this command, you should enable auto-configuration with the ipx_configure command. You can then mount a NetWare volume with ncpmount. The entire procedure might resemble the following:

# ipx_configure —auto_interface=on —auto_primary=on

# ncpmount -S NW_SERV -U anne -P p4rtu3a /mnt/nwmount

This sequence enables auto-detection of the local network number and mounts volumes stored on NW_SERV associated with the user anne at /mnt/nwmount, using the password p4rtu3a

IPX/SPX Features and Capabilities

Like TCP/IP and AppleTalk, IPX/SPX supports a 32-bit address, which is usually expressed in hexadecimal, as in 0x23a91002. This address, however, isn't assigned to a single computer, but to an entire network—usually a network segment that's isolated from others by routers, or completely disconnected from the outside world. An IPX/SPX network is also identified by the underlying hardware's frame type, which is how the Ethernet frames are built at a very low level; all computers on a single IPX/SPX network must use the same frame type. To identify individual computers, IPX/SPX relies on the underlying hardware's addressing scheme, such as Ethernet's 48-bit (6-byte) addresses.

As you might guess from the name and addressing scheme, IPX/SPX is designed for internetworking—that is, linking networks together. This is accomplished via IPX routers, which work much like TCP/IP routers in broad detail. (In fact, a single system can function as both a TCP/IP and an IPX router.) A simple network may not require a router, but IPX/SPX does support the option.

IPX/SPX servers use a protocol known as the Service Advertisement Protocol (SAP) to periodically announce their names and the services they make available, such as shared directories or printers. Other systems on the local network segment will "hear" these announcements, and IPX routers should echo them to other network segments. This design can help make locating the right server easy, but it can also increase network traffic as the network size increases; with more servers, there will be more SAP broadcasts consuming network bandwidth.

The Role of the TCP/IP Stack

TCP/IP is the most popular network stack. The Internet is built upon TCP/IP, and the stack supports the most popular network protocols, including most of those discussed in this book. In most cases, you can't simply unlink a network application from one stack and tie it to another stack, although a few applications do support multiple network stacks. Part of the reason for TCP/IP's popularity is its flexibility. TCP/IP is a routable network stack, meaning that a computer with multiple network interfaces can partially process TCP/IP packets and pass those packets from one network to another. TCP/IP routing is flexible and allows for routing based on decentralized network maps; there's no need for a centralized database for network routing to occur. Furthermore, TCP/IP supports a large network address (32 bits, with 128-bit addresses coming with IPv6, as described in Chapter 2) and a hierarchical naming structure. All these features make TCP/IP well suited to function as a network stack for a globe-spanning network.

On an individual Linux computer, TCP/IP is a good choice because of its support for so many important network protocols. Although many non-Unix platforms developed proprietary protocol stacks in the 1980s, Unix systems helped pioneer TCP/IP, and most Unix network protocols use TCP/IP. Linux has inherited these protocols, and so a Linux-only or Linux/Unix network operates quite well using TCP/IP alone; chances are you won't need to use any other network stack in such an environment.

Common protocols supported by TCP/IP include HTTP, FTP, the Simple Mail Transfer Protocol (SMTP), the Network File System (NFS), Telnet, Secure Shell (SSH), the Network News Transfer Protocol (NNTP), the X Window System, and many others. Because of TCP/IP's popularity, tools that were originally written for other network stacks can also often use TCP/IP. In particular, the Server Message Block (SMB)/Common Internet File System (CIFS) file-sharing protocols used by Windows can link to TCP/IP via the Network Basic Input/Output System (NetBIOS), rather than tying to the NetBIOS Extended User Interface (NetBEUI), which is the native DOS and Windows protocol stack. (All versions of Windows since Windows 95 also support TCP/IP.) Similarly, Apple's file-sharing protocols now operate over TCP/IP as well as over AppleTalk.

Although it's very popular and can fill many network tasks, TCP/IP isn't completely adequate for all networking roles. For instance, your network might contain some systems that continue to use old OSs that don't fully support TCP/IP. An old Macintosh might only support file sharing over AppleTalk, for instance, or you might have DOS or Windows systems configured to use IPX or NetBEUI. In these situations, Linux's support for alternative network stacks can be a great boon.

Wrapping and Unwrapping Data

The network stack is a useful way to envision the passage of data through a computer's network software, but it doesn't clearly describe what happens to data along the way. This can be thought of as wrapping and unwrapping data. Each layer of the network stack does something to the data it receives. Actions performed during wrapping may include breaking data into chunks (usually called packets or frames, depending on the level of the stack under discussion), adding information to an existing chunk of data, or modifying existing data (data modification is rare, though). Unwrapping reverses these actions.

For instance, consider data transfer via the File Transfer Protocol (FTP), which uses the TCP/IP network stack, over an Ethernet network. The data being transferred might be a file, but that single file might be much larger than the data packets or frames that TCP/IP or Ethernet are designed to transfer. Therefore, the file will be broken down into many small chunks. Each of these chunks will have headers added to it by various portions of the network stack. (Some layers may add footers, as well.) Headers and footers begin or end a given chunk of data, and include information to help the system parse and deliver the rest of the data packet. The idealized result of this wrapping is shown in Figure 3.2. In fact, matters can become more complex, because the packets delivered by one layer of the network stack may be even further split by subsequent layers of the stack. For instance, the Ethernet drivers might break down an IP packet into two Ethernet frames. Routers might do the same thing. When this happens, the IP, TCP, and FTP headers of Figure 3.2 are all just part of the data payload; they aren't duplicated in both Ethernet packets, and could wind up in either Ethernet packet. All of this is transparent, though, because each layer of the network stack on the recipient computer reassembles the packets or frames that its counterpart on the sending computer created, even if those packets have been split up en route.

The details of Figure 3.2 vary from one network stack to another, and even with details of a single stack. For instance, the FTP Header of Figure 3.2 would be a Hypertext Transfer Protocol (HTTP) header for a Web browser data transfer. If the computers used network hardware other than Ethernet, the Ethernet header and footer would be replaced by headers and footers for the particular network hardware used. Indeed, a router that transfers data across network types would, as part of its processing, strip away these headers and footers and replace them with appropriate substitutes. This processing can occur several times during a packet's journey across the Internet, but the goal is to deliver the original data in its original form to the destination.

The headers and footers include critical addressing information, such as the sender's and recipient's IP addresses, the port numbers of the originating and destination programs, numbers identifying the place of a packet in a sequence, and so on. Intervening computers use this information to route individual packets, and the recipient uses it to direct the packet to the appropriate program. This program can then use the sender's address and port number to direct a reply to that system and program.

The OSI Network Stack Model

One common model of network stacks is the Open System Interconnection (OSI) model. This model consists of seven layers, each of which handles a specific networking task. When a computer sends data, the information originates from a program residing at the top layer of the OSI model (known as the Application layer). The program passes data to the next layer (the Presentation layer), and so on down the stack. Each layer processes the data in some way. At the bottom of the OSI model is the Physical layer, which corresponds to the network hardware, such as cables and hubs. Data pass over the Physical layer from the sending computer to the receiving computer. (This transfer may be simple when both computers are on the same network segment, but it can involve many other systems when the two computers are at disparate points on the Internet.) On the destination system, the data pass up the network stack, ultimately reaching the recipient program at the Application layer on that system. This system may then send a reply down its network stack, and that reply passes up the stack of the first system. Figure 3.1 illustrates this process.

Each layer of the OSI model communicates directly only with the layers immediately above and below it. (In the case of the Application and Physical layers, the chain ends. Applications communicate with users or perform automated network tasks, and the Physical layer links the two computers.) On any given computer, the layers of the network stack must be written to facilitate such communication, using clearly defined interfaces. Sometimes, the components at a given layer must be interchangeable. For instance, the Application layer consists of network applications, such as Web browsers and Web servers. You should be able to swap out one Web browser or Web server for another without causing problems with the network stack. (Any given Web browser or Web server may lack certain important features, such as the ability to handle Secure Sockets Layer [SSL] encryption; however, this isn't really an issue of network stack integration.) Similarly, you should be able to swap out network cables and hubs at the Physical layer, or even replace a network card and its driver, without impacting higher-up layers.

Each layer of the network stack corresponds to its counterpart on the opposite computer. In some sense, the recipient computer's network stack undoes whatever the sender computer's network stack did. The ultimate goal is to allow Application-layer programs to communicate. Therefore, any layer should receive from the layer below exactly the data sent by its counterpart layer on the sending system. In some sense, any given layer should work as if it were talking to its counterpart on the other system, not another layer of the local protocol stack. For this reason, network stacks must be very standardized across computers, even if those computers run radically different OSs. For instance, the network stacks of such diverse OSs as Linux, Windows XP, MacOS X, and BeOS must all work in almost precisely the same ways, even if they use entirely independent code bases.

Configuring a Static IP Address

Although DHCP is a common method of configuration on many networks, it's not used universally. It's awkward to configure some systems (such as DHCP servers) via DHCP, and some networks simply lack DHCP servers. In these situations, you'll need to configure your computer's IP address manually. This section describes how to do this, starting with the tools to do the job a single time. The section entitled "Making Your Changes Permanent" describes how to configure your system to use your settings automatically whenever it reboots.

Configuring Network Interfaces
Loading a driver, as described earlier in this chapter, is the first step in making a network interface available. To use the interface, you must assign it an IP address and associated information, such as its network mask (also called the subnet mask or netmask). This job is handled by the ifconfig utility, which displays information on an interface or changes its configuration, depending upon how it's called.

Basic ifconfig Syntax and Use

The ifconfig utility's syntax is deceptively simple:

ifconfig [interface] [options]

The program behaves differently depending upon what parameters it's given. On a broad level, ifconfig can do several different things:

• If used without any parameters, ifconfig returns the status of all currently active network interfaces. Used in this way, ifconfig is a helpful diagnostic tool.
• If given a single interface name (such as eth0 or tr1), ifconfig returns information on that interface only. Again, this is a useful diagnostic tool.
• If fed options in addition to an interface name, ifconfig modifies the interface's operation according to the options' specifications. Most commonly, this means activating or deactivating an interface.

Using a DHCP Client

If your local network has a DHCP server, you can configure Linux to obtain its IP address from this server automatically, by using a DHCP client. This client sends a broadcast message on its local network segment to search for a DHCP server. If a DHCP server responds, and if the ensuing negotiation is successful, the result should be a system with an IP address and associated information, fully configured to use the connection.



Most Linux distributions give you the option of using DHCP during installation. You should be able to select a DHCP option when configuring the network settings. If not, or if you need to reconfigure the computer after installation, the easiest way to enable this feature is usually to use a GUI configuration tool, such as Linuxconf (Red Hat or Mandrake), COAS (Caldera), or YaST or YaST2 (SuSE). For instance, Figure 2.1 shows the YaST2 configuration screen in which this option is set. Click Automatic Address Setup (via DHCP), and the system will obtain its IP address via DHCP.

GUI configuration tools make it easy to enable DHCP client operation.

Unfortunately, DHCP configuration isn't always quite this easy. Potential problems include the following:

• Incompatible DHCP clients— Four DHCP clients are common on Linux systems: pump, dhclient, dhcpxd, and dhcpcd (don't confuse either of the latter two with dhcpd, the DHCP server). Although all four work properly on many networks, some networks use DHCP servers that don't get along well with one or another Linux DHCP clients. You might therefore need to replace your DHCP client package with another one.
• Incompatible DHCP options— DHCP client options sometimes cause problems. In practice, this situation can be difficult to distinguish from an incompatible DHCP client, but the solution is less radical: You can edit the DHCP startup script to change its options. Unfortunately, you'll need to learn enough about your DHCP client to have some idea of what options to edit. Reading the man page may give you some ideas.
• Multi-NIC configurations— If your computer has two or more network interface cards (NICs), you may need to get the DHCP client to obtain an IP address for only some cards, or to disregard some information (such as the gateway address, described in more detail shortly in "Adjusting the Routing Table") for some NICs. Again, editing the DHCP client startup script may be necessary, or you may need to create a custom script to correct an automatic configuration after the fact.

Loading Network Drivers

The first step in configuring a network card is to load the appropriate drivers. As described in Chapter 1, Kernel Network Configuration, drivers may reside on your system in one of two forms: as an integral part of your Linux kernel, or as separate kernel module files. In the first case, the task of loading network drivers is easy, because it's done when the kernel loads. For some cards, though, you may need to pass parameters to the driver via kernel boot options. If you use LILO, these can be passed with an append option in /etc/lilo.conf. For instance, the following /etc/lilo.conf line, as part of a kernel definition, tells the kernel to look for the eth0 device (the first Ethernet card) at I/O port 0x240:

append="ether=0,0,0x240,eth0"

You can include several options within the quotes after append= by separating them with spaces. You can use this trick to force a particular Ethernet card to link itself to a particular network card on a multi-interface system by identifying the I/O port used by a specific card. In most cases, you won't need to pass any options to a driver built into the kernel; the driver should detect the network card and make it available without further intervention, although you must still activate it in some other way.

If your network card drivers are compiled as modules, you can pass them parameters via the /etc/modules.conf file (which is called /etc/conf.modules on some older distributions). For instance, this file might contain lines like the following:

alias eth0 ne
options ne io=0x240

This pair of lines tells the system to use the ne driver module for eth0, and to look for the board on I/O port 0x240. In most cases, such configurations will be unnecessary, but you may need to make the link explicit in some situations. This is especially true if your system has multiple network interfaces. The GUI configuration tools provided by many distributions can help automate this process; you need only select a particular model of card or driver from a list, and the GUI tools make the appropriate /etc/modules.conf entries.

When you've created an entry in /etc/modules.conf, Linux will attempt to load the network drivers automatically whenever it detects an attempt to start up a network interface. If you should need to do this manually for any reason, you may use the insmod command to do the job:

# insmod ne

This command will load the ne module, making it available for use. If kernel module auto-loading doesn't work reliably, you can force the issue by placing such a command in a startup script such as /etc/rc.d/rc.local or /etc/rc.d/boot.local.

If your connection uses PPP, SLIP, or some other software protocol for communicating over serial, parallel, or other traditionally nonnetwork ports, you must load the drivers for the port itself and for the software protocol in question. You do this in the same way you load drivers for a network card—by building the code into the kernel file proper or by placing it in a module and loading the module. In most cases, you'll need to attend to at least two drivers: one for the low-level hardware and another for the network protocol. Sometimes one or both of these will require additional drivers. For instance, a USB modem may require you to load two or three drivers to access the modem.

TCP/IP Network Configuration

Although the Linux kernel lies at the heart of any Linux system and controls all network access, the process of configuring a Linux computer to use a network involves more than the kernel. This chapter covers three popular methods of network connection: the Dynamic Host Configuration Protocol (DHCP), static IP addresses, and the Point-to-Point Protocol (PPP). DHCP and PPP are used to automatically assign an IP address and set other configuration information, but in different contexts. Static IP addresses, by contrast, require that you set up the details manually. In each of these cases, there are a handful of tools with which you must be familiar if you're to get your system working. Before using any of these methods of network configuration, you must load appropriate network drivers. This topic therefore begins this chapter.

Installing and Using a New Kernel

Once you've built a new kernel, you'll need to install and use it. As noted earlier, the fresh-built kernel normally resides in /usr/src/linux/arch/ i386/boot (or a similar directory with a name matched to your CPU type rather than i386). You normally copy or move the kernel file (such as bzImage) to the /boot directory. I recommend renaming the file to something that indicates its version and any customizations you may have made. For instance, you might call the file bzImage-2.4.17 or bzImage-2.4.17-xfs. You should also type make modules_install, if you haven't already, to install your kernel modules in /lib/modules/x.y.z, where x.y.z is the kernel version number.

Unfortunately, copying the kernel to /boot isn't enough to let you use the kernel. You must also modify your boot loader to boot the new kernel. Most Linux distributions use the Linux Loader (LILO) as a boot loader, and you configure LILO by editing /etc/lilo.conf. Listing 1.1 shows a short lilo.conf file that's configured to boot a single kernel.

Listing 1.1 A sample lilo.conf file

boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt
default=linux
timeout=50
image=/boot/vmlinuz
label=linux
root=/dev/sda6
read-only

To modify LILO to allow you to choose from the old kernel and the new one, follow these steps:

• Load /etc/lilo.conf in a text editor.
• Duplicate the lines identifying the current default kernel. These lines begin with an image= line, and typically continue until another image= line, an other= line, or the end of the file. In the case of Listing 1.1, the lines in question are the final four lines.
• Modify the copied image= line to point to your new kernel file. You might change it from image=/boot/vmlinuz to image=/boot/bzImage-2. 4.17, for instance. (Many Linux distributions call their default kernels vmlinuz.)
• Change the label= line for the new kernel to something unique, such as mykernel or 2417, so that you can differentiate it at boot time from the old kernel. Ultimately, you'll select the new kernel from a menu or type its name at boot time.
• Save your changes.
• Type lilo to install a modified boot loader on your hard disk.

The next time you boot the computer, LILO should present you with the option of booting your old kernel or the new one, in addition to any other options it may have given you in the past. Depending upon how it's configured, you may see the new name you entered in Step 4 in a menu, or you may be able to type it at a lilo: prompt.

If you can boot the computer and are satisfied with the functioning of your new kernel, you can make it the default by modifying the default= line in /etc/lilo.conf. Change the text after the equal sign to specify the label you gave the new kernel in Step 4, then type lilo again at a command prompt.

There are ways to boot a Linux kernel other than LILO. Some distributions use the Grand Unified Boot Loader (GRUB) instead of LILO. Consult the GRUB documentation for details on how to configure it. You can also use the DOS program LOADLIN to boot Linux. To do this, you need to place a copy of the kernel on a DOS-accessible disk—a DOS partition or a floppy disk. You can then boot Linux by typing a command like the following:

C:> LOADLIN BZIMAGE root=/dev/sda6 ro

In this example, BZIMAGE is the name of the kernel file, as accessed from DOS, and /dev/sda6 is the Linux identifier for the root partition. The ro option specifies that the kernel should initially mount this partition read-only, which is standard practice. (Linux later remounts it for read-write access.) LOADLIN can be a useful tool for testing new kernels, if you prefer not to adjust your LILO setup initially. It's also a good way to boot Linux in an emergency, should LILO become corrupt. If you don't have a copy of DOS, FreeDOS (http://www.freedos.org) is an open source version that should do the job. LOADLIN ships on most Linux distributions' installation CD-ROMs, usually in a directory called dosutils or something similar.

Common Kernel Compilation Problems

Kernel compilation usually proceeds smoothly if you configured the kernel correctly, but occasionally errors pop up. Common problems include the following:

• Buggy or incompatible code— Sometimes you'll find that drivers are buggy or incompatible with other features. This is most common when you try to use a development kernel or a non-standard driver you've added to the kernel. The usual symptom is a compilation that fails with one or more error messages. The usual solution is to upgrade the kernel, or at least the affected driver, or omit it entirely if you don't really need that feature.
• Unfulfilled dependencies— If a driver relies upon some other driver, the first driver should only be selectable after the second driver has been selected. Sometimes, though, the configuration scripts miss such a detail, so you can configure a system that won't work. The most common symptom is that the individual modules compile, but they won't combine into a complete kernel file. (If the driver is compiled as a module, it may return an error message when you try to load it.) With any luck, the error message will give you some clue about what you need to add to get a working kernel. Sometimes, typing make dep and then recompiling will fix the problem. Occasionally, compiling the feature as a module rather than directly into the kernel (or vice-versa) will overcome such problems.
• Old object files— If you compile a kernel, then change the configuration and compile again, the make utility that supervises the process should detect what files may be affected by your changes and recompile them. Sometimes this doesn't work correctly, though, with the result being an inability to build a complete kernel, or sometimes a failure when compiling individual files. Typing make clean should clear out preexisting object files (the compiled versions of individual source code files), thus fixing this problem.
• Compiler errors— The GNU C Compiler (GCC) is normally reliable, but there have been incidents in which it's caused problems. Red Hat 7.0 shipped with a version of GCC that could not compile a 2.2.x kernel, but this problem has been overcome with the 2.4.x kernel series. (Red Hat 7.0 actually shipped with two versions of GCC; to compile a kernel, you had to use the kgcc program rather than gcc.)
• Hardware problems— GCC stresses a computer's hardware more than many programs, so kernel compilations sometimes turn up hardware problems. These often manifest as signal 11 errors, so called because that's the error message returned by GCC. Defective or over heated CPUs and bad RAM are two common sources of these problems. http://www.bitwizard.nl/sig11/ has additional information on this problem.

If you can't resolve a kernel compilation problem yourself, try posting a query to a Linux newsgroup, such as comp.os.linux.misc. Be sure to include information on your distribution, the kernel version you're trying to compile, and any error messages you see. (You can omit all the nonerror compilation messages.)

A Typical Kernel Compilation

After you've configured your kernel with make xconfig or some other configuration command, you must issue four commands to compile the kernel and install the kernel modules:

# make dep
# make bzImage
# make modules
# make modules_install

The first of these commands performs some housekeeping tasks. Specifically, dep is short for dependency—make dep determines which source code files depend on others, given the options you've chosen. If you omit this step, it's possible that the compilation will go awry because you've added or omitted features, which requires adjusting the dependency information for the features you have.

The second of these commands builds the main kernel file, which will then reside in the /usr/src/linux/arch/i386/boot directory under the name bzImage. There are variants on this command. For instance, for particularly small kernels, make zImage works as well (the bzImage form allows a boot loader like LILO to handle larger kernels than does the zImage form). Both zImage and bzImage are compressed forms of the kernel. This is the standard for x86 systems, but on some non-x86 platforms, you should use make vmlinux instead. This command creates an uncompressed kernel. (On non-x86 platforms, the directory in which the kernel is built will use a name other than i386, such as ppc for PowerPC systems.)

The make modules command, as you might guess, compiles the kernel modules. The make modules_install command copies these module files to appropriate locations in /lib/modules. Specifically, a subdirectory named after the kernel version number is created, and holds subdirectories for specific classes of drivers.

The entire kernel compilation process takes anywhere from a few minutes to several hours, depending on the options you select and the speed of your computer. Typically, building the main kernel file takes more time than does building modules, but this might not be the case if you're building an unusually large number of modules. At each step, you'll see many lines reflecting the compilation of individual source code files. Some of these compilations may show warning messages, which you can usually safely ignore. Error messages, on the other hand, are more serious, and will halt the compilation process.

Drivers: Modules or Built-In

The preceding discussion made many references to enabling or disabling particular kernel features, such as drivers for your particular Ethernet adapter. If you check Figure 1.1, though, you'll find that many options can be set to more than two values. Consider the Packet Socket option in Figure 1.1. This option can be set to any of three values: Y, M, or N. The Y and N values, as you might expect, stand for yes and no, respectively, meaning that the code is compiled directly into the main kernel file or not compiled at all. The M option falls in-between these two extremes. If you select M, the feature will be compiled, but it won't be linked into the main kernel file; instead, the code will be available as a kernel module, which can be loaded and unloaded as required. Options that are suboptions of others, such as Packet Socket: Mmapped IO in Figure 1.1, often lack the M option because they're compiled into the kernel or as modules, depending on their parent options' settings. Thus, selecting Y for such an option may place it in the kernel or in a module.

A feature that's compiled into the kernel is always available, and is available early in the boot process. There's no chance that the feature will become unavailable because it's been unloaded. Some features must be compiled in this way, or not at all. For instance, the filesystem used for the root directory must be available in the kernel at boot time, and so must be compiled directly into the kernel. If you use the Root File System on NFS option, described earlier, you'll need to compile support for your network hardware into the kernel.

The down side to compiling a feature directly into the kernel is that it consumes RAM at all times. It also increases the size of the kernel on disk, which can complicate certain methods of booting Linux. For these reasons, Linux distributions ship most options that can be compiled as modules in this way. This allows the distribution maintainers to keep their default kernels manageable, while still providing support for a wide array of hardware. Because most network hardware can be compiled as modules, most distributions compile drivers for network cards in this way.

As somebody who's maintaining specific Linux computers, though, you might decide to do otherwise. If you compile a network card driver directly into the kernel, you won't need to configure the system to load the module before you attempt to start networking. (In truth, most distributions come preconfigured to handle this task correctly, so it's seldom a problem.) On the other hand, if you maintain a wide variety of Linux systems, you might want to create a single kernel and set of kernel modules that you can install on all the computers, in which case you might want to compile network drivers as modules.

Features such as network stacks can also be compiled as modules or directly into the kernel. (TCP/IP is an exception; it must be compiled directly into the kernel or not at all, although a few of its suboptions can be compiled as modules.) You might decide to compile, say, NFS client support as a module if the computer only occasionally mounts remote NFS exports. Doing this will save a small amount of RAM when NFS isn't being used, at the cost of greater opportunities for problems and a very small delay when mounting an NFS export.

As you might gather, there's no single correct answer to the question of whether to compile a feature or driver directly into the kernel or as a module, except of course when modular compilation isn't available. As a general rule of thumb, I recommend you consider how often the feature will be in use. If it will be used constantly, compile the feature as part of the kernel; if it will be used only part of the time, compile the feature as a module. You might want to favor modular compilation if your kernel becomes large enough that you can't boot it with LOADLIN (a DOS utility for booting Linux), though, because this can be an important way to boot Linux in some emergency situations.

Compiling and Installing a Kernel

The preceding discussion has covered the most important options you'll encounter in configuring a kernel to use the networking protocols on your network, and the hardware you use to connect a computer to that network. The process of compiling the kernel, however, is another matter, and one that's not, strictly speaking, a networking task. Nonetheless, this task is important if you need to recompile your kernel to add or delete support for specific network features, so this section provides an overview of some of the decisions and procedures involved.

Don't adjust only the options described earlier in this chapter and then compile your kernel. Although they're beyond the scope of this book, kernel options relating to features like EIDE controllers, SCSI host adapters, and disk filesystems are critically important for a functioning Linux computer. If you incorrectly configure these features, your computer may not boot at all, or it may perform in a substandard way (for instance, with very poor disk speed). These options are discussed in documents such as the Linux Kernel HOWTO at http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html (among many other places) and many general Linux books.

Dial-Up Devices

The final class of network devices is the dial-up device. Most typically, this is a conventional telephone modem used in conjunction with the Point-to-Point Protocol (PPP) to establish a connection to the Internet via an ISP. Such connections are established via command-line or GUI tools, as described in Chapter 2. In addition to these tools, though, the Linux kernel requires support for the dial-up connection.

To activate this support, you must select the PPP (Point-to-Point Protocol) Support option in the Network Device Support menu. When you select this option, several suboptions will become available, such as PPP Support for Async Serial Ports and PPP Deflate Compression. These options aren't usually strictly necessary, but sometimes they can improve a connection, such as by automatically compressing highly compressible data like text for higher net throughput. The experimental PPP over Ethernet option is required if you intend to use the kernel's PPPoE features for some DSL connections, but this option is not required with some add-on PPPoE packages, like Roaring Penguin.

PPP is sometimes used on connections that don't involve modems. For instance, you can use it to network two computers via their serial ports. Such configurations are seldom worthwhile with desktop systems, because Ethernet cards are inexpensive and provide much faster connections. You might want to use this type of link when connecting a desktop system to a palmtop computer, though, or for a temporary connection if you don't want to bother installing network cards.

PPP isn't the only type of dial-up connection that Linux supports. The kernel includes support for the older Serial Line Internet Protocol (SLIP), which serves much the same function as PPP. SLIP has been largely abandoned by ISPs, so it's unlikely you'll need to use it over a modem. A few Linux tools use it locally, though; for instance, some types of dial-on-demand utilities (which dial a PPP connection whenever network activity is detected) use SLIP to detect outgoing connection attempts.

Another protocol that's akin to PPP and SLIP is the Parallel Line Internet Protocol (PLIP). As you might guess by the name, this protocol lets you connect two Linux computers via their parallel (printer) ports. Because these ports are much faster than are RS-232 serial ports, PLIP offers a speed advantage over PPP or SLIP for two-computer local networks. Ethernet is still faster, though. To use PLIP, you must select the PLIP (Parallel Port) Support option in the Network Device Support menu. To do this, you must first activate the Parallel Port Support option in the menu of the same name, including the PC-Style Hardware option (if you're using an x86 computer). If you need to use PLIP networking, you should consult the PLIP Mini-HOWTO (http://www.linuxdoc.org/HOWTO/mini/PLIP.html) for further details, including wiring for the necessary cable, if you can't find a Turbo Laplink cable.

PC Card Devices

Most notebook computers come with at least one PC Card slot. (Much Linux documentation refers to PC Card technology by its old name, PCMCIA, which stands for the developer of the standards, the Personal Computer Memory Card International Association.) PC Card devices can be installed and removed from a computer while it's still running, and the OS has no say over this matter. Because Linux was designed with the assumption that network interfaces would not disappear without warning, a separate package, Card Services, helps manage these matters, cleanly starting and stopping kernel features related to PC Card devices when they're inserted or removed. You can find more information on Card Services at http://pcmcia-cs.sourceforge.net.

The 2.4.17 kernel includes support for many PC Card network devices in the PCMCIA Network Device Support submenu. Some wireless cards' drivers appear in the Wireless LAN (Non-Hamradio) submenu. When you select such a card and configure it, it functions much like a standard ISA or PCI card. For instance, an Ethernet PC Card appears as eth0 and is configured with the standard tools, as described in Chapter 2.

Kernels prior to the 2.4.x series required a separate package of drivers to use PC Card devices, and in fact many PC Card devices are still not supported in the standard kernel. You may therefore need to check out this package, which is part of the Card Services collection. You're unlikely to need to use special drivers for a PC Card network device if you use a 2.4.x or later kernel, but you might need this for a modem, SCSI host adapter, or something else.

Wireless Devices

Beginning in the late 1990s, wireless networking technologies rose rapidly in popularity. These technologies allow computers to network even without physical cabling connecting them. Such an arrangement is particularly helpful in existing homes and offices in which running conventional wired network cables would be troublesome, and for users of notebook computers and other portable devices, who might want or need to roam about without plugging the computer into a physical network.

Unfortunately, in 2001 the wireless world still suffers from some drawbacks compared to conventional Ethernet networks. Wireless networks are more expensive than are Ethernet networks, they're slower, and they aren't as well standardized. The most important standards for wireless in 2001 are 802.11 and 802.11b. The former supports speeds of 2Mbps, with a fallback to 1Mbps. (Fallback refers to a renegotiation of the connection when signal strength falls, as when there's interference or the computers are far apart from one another.) 802.11b supports speeds of 11Mbps, with fallback speeds of 5.5Mbps, 2Mbps, and 1Mbps. Another wireless technology that's received a lot of press is Bluetooth, which supports speeds of up to 1Mbps. Bluetooth-enabled printers, cell phones, and the like will probably begin shipping in volume in 2002. Future developments are likely to increase available speeds. For instance, plans are underway to develop a wireless version of ATM with speeds of up to 155Mbps.

Wireless LANs are typically implemented through wireless PC Cards in notebook computers. These cards may either communicate directly with one another or may require the use of a base station, which may also serve as an interface to a conventional wired network or to a broadband or conventional telephone modem connection to the Internet. There are also wireless ISA and PCI cards, so that desktop systems can participate in wireless networks, or serve as base stations for roaming devices. PC Cards, ISA cards, and PCI cards all require Linux drivers, but base stations require no special support.

Linux support for wireless devices appears under the Wireless LAN (Non-Hamradio) submenu. This menu lists specific drivers by the chipsets or cards for which they're written, not for the technology (such as 802.11b or Bluetooth) those cards use. In addition to kernel drivers, there are two packages known as the Wireless Extensions and Wireless Tools that help you manage a wireless network under Linux. Check http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html for information on these packages, and for additional links to information on wireless networking in Linux.

Broadband and WAN Devices

Broadband is a term that's commonly applied in a couple of different ways. First, it may refer to a networking technology that allows for the simultaneous transmission of multiple types of information, such as video, audio, and digital data. Second, it may refer to a substitute for ordinary dial-up telephone network connections that permits substantially higher speeds (typically 200Kbps or greater). Although 200Kbps doesn't sound like much compared to technologies like Ethernet, it's a substantial improvement over 56Kbps telephone dial-up speeds.

Residential and small business customers frequently use broadband technologies to link to the Internet through an Internet Service Provider (ISP), or occasionally to link multiple sites without running dedicated cables. Typically, broadband connections link a computer that you own to the Internet as a whole. This contrasts with the other network technologies described here, which normally link together a group of computers that you own or administer. Therefore, broadband connections frequently require that you conform to some requirements of the ISP that provides the connection. Many low-end broadband ISPs require that you not run servers, for instance.

In 2002, the most popular forms of broadband are Digital Subscriber Line (DSL) and cable modems. DSL comes in several varieties, such as Asymmetric DSL (ADSL) and Single-Line (or Symmetric) DSL (SDSL), and operates using high-frequency signals over ordinary telephone lines. Cable modems operate over cable TV networks by occupying the bandwidth of one TV channel (often with some additional bandwidth reserved, as well). Broadband through satellite systems, local radio-frequency transmissions, and fiber-optic cabling are also available in at least some areas.

Most broadband connections use an external modem that sports a broadband connector for linking to the broadband network and an Ethernet port for connecting to your computer. You therefore need a supported Ethernet adapter, and you configure that adapter with the standard Linux drivers. The broadband modem itself needs no special drivers, although some ISPs require you to use the Point-to-Point Protocol over Ethernet (PPPoE), which is implemented in Linux via the experimental PPP over Ethernet driver in the Network Device Support menu. (This option requires that you first enable the PPP Support option, discussed shortly in "Dial-Up Devices.") Another PPPoE option is to use the Roaring Penguin PPPoE package, available from http://www.roaringpenguin.com/pppoe/.

Some broadband modems come with USB interfaces rather than Ethernet interfaces. The 2.4.17 Linux kernel supports none of these devices, although Alcatel provides Linux drivers for its Speed Touch USB DSL modem at http://www.alcatel.com/consumer/dsl/supuser.htm. Check with the hardware manufacturer or at http://www.linux-usb.org for updated information on drivers for other USB products.

Some broadband modems, particularly for low-end ADSL accounts, come as internal PCI cards. As with USB devices, support for these is rare. The 2.4.17 kernel includes support for the General Instruments Surfboard 1000, an old one-way cable modem. (One-way means that it only receives data; you must use a conventional telephone modem to send data. One-way broadband services are undesirable and are becoming rare.) Drivers for the Diamond 1MM DSL modem are available from http://www.rodsbooks.com/network/network-dsl.html, but these drivers are an unsupported modification of existing Ethernet drivers and may not work on 2.4.x or later kernels.

If your broadband provider doesn't give you the option of an Ethernet- interfaced modem, buy one yourself and sell the modem your ISP provides on an auction site like eBay (http://www.ebay.com). Be sure you buy a compatible modem, though, and only sell the one your ISP provides if it's given to you or if you must buy it; don't sell a modem your ISP rents to you!

Another type of long-distance connection is a Wide-Area Network (WAN). This type of technology allows connections over dedicated long-distance circuits, often called leased lines because they may be ordinary telephone lines leased from the telephone company. (The phone company doesn't provide a signal on the other end, though; you do.) Such connections often use external devices, known as WAN routers, which link to a Linux computer or local network much as do broadband modems. Another option is to use a dedicated WAN interface card. Linux includes support for a range of such devices in the WAN Interfaces submenu of the Network Device Support menu. As with many other submenus, you must select the first option (WAN Interfaces Support), then select the option corresponding to the device you intend to use.

Alternative Local Network Devices

Although it's extremely popular, Ethernet isn't the only choice for local network hardware. The Linux kernel includes support for several other types of network, although there aren't as many drivers available for any of these as there are for Ethernet. (There are also fewer models of non-Ethernet network hardware available, so this restricted range of drivers doesn't necessarily mean poor support for the hardware that is available.) Options available in the 2.4.17 kernel's Network Device Support menu include the following:

• Token Ring— Historically, Ethernet's most important competitor has been IBM's Token Ring. Ethernet gained momentum in the 1990s, in part at the expense of Token Ring. Most Token Ring cards support a top speed of 16Mbps, although 100Mbps models have now become available. Maximum distances between Token Ring stations vary from 150–300m. Linux includes support for several Token Ring cards, in the Token Ring Devices submenu of the Network Device Support menu.

• LocalTalk— Apple developed its own networking technologies, including both hardware (LocalTalk) and software protocols (AppleTalk), for its Macintosh line of computers. A few x86 boards for interfacing x86 systems to LocalTalk networks were produced, and Linux supports some of these, from the AppleTalk Devices submenu. (Ironically, Linux on Macintosh hardware doesn't support that hardware's own LocalTalk interfaces.) LocalTalk is slow by the standards of 2002, reaching a maximum speed of 2Mbps.

• ARCnet— ARCnet is a network technology that's often used for specialized purposes like security cameras and scientific data acquisition systems. These devices support speeds ranging from 19Kbps to 10Mbps over coaxial, twisted-pair, or fiber-optic cabling. Linux's ARC net support is activated from items in the ARCnet Devices submenu. In addition to drivers for your specific chipset, you'll need to enable a driver for a specific ARCnet packet format (RFC 1051 or RFC 1201).

• FDDI and CDDI— Fiber Distributed Data Interface (FDDI) and Copper Distributed Data Interface (CDDI) are closely related 100Mbps local network technologies that use fiber-optic and copper wiring, respectively. FDDI's primary advantage over 100Mbps Ethernet is that it supports greater cable lengths—theoretically up to 2km, vs. 100m for twisted-pair Ethernet. Gigabit Ethernet with fiber-optic cabling supports distances of up to 5km, though. The 2.4.17 kernel includes support for two lines of FDDI/CDDI products, both selectable from the Network Device Support menu after selecting FDDI Driver Support.

• HIPPI— High-Performance Parallel Interface (HIPPI) supports speeds of 800Kbps or 1600Kbps, with distances of up to 25m over twisted-pair copper wiring, 300m on multi-mode fiber-optic cabling, or 10km on single-mode fiber-optic cabling. The 2.4.17 kernel supports one HIPPI card, the Essential RoadRunner, but the driver is considered experimental.

• Fibre Channel— This type of network interface supports both copper and fiber-optic network media, and provides speeds of 133–1062Mbps. When used over fiber-optic cables, Fibre Channel can be used over a 10km range. The 2.4.17 kernel includes support for one Fibre Channel chipset, the Interphase 5526 Tachyon.

Some of these network media, such as Token Ring, are most often used on local networks, typically contained within a single building or a small cluster of buildings. Others, like FDDI and HIPPI, are more often used to link clusters of computers across greater distances, such as between buildings on corporate or university campuses. Linux's support for these technologies means that Linux can function as a router, linking a local network with Ethernet to a broader network that uses a wider-ranging (and higher-speed) standard.

Throughout this book, the assumption is that a computer uses Ethernet. The main feature that changes if one or more interfaces use some other networking technology is the name for the network interface. For Ethernet, this is eth0 for the first device, eth1 for the second, and so on. Other devices use other names, such as tr0 for the first Token Ring device or fddi1 for the second FDDI device.

Ethernet Devices

Ethernet is the most common type of local network hardware in 2002, and it seems likely to retain that status for some time. (Wireless technologies, discussed shortly, are becoming popular in some environments, but they lag behind Ethernet and several other wired technologies in terms of speed.) From the point of view of an OS, the problem with Ethernet's popularity is that it's spawned literally hundreds, if not thousands, of specific Ethernet cards.

Fortunately, most Ethernet cards use one of just a few chipsets, so Linux can support the vast majority of Ethernet cards with about 60 drivers. These drivers are split across two submenus: the Ethernet (10 or 100 Mbit) and Ethernet (1000 Mbit) menus. By far the most drivers appear in the first menu, which as the name implies covers 10 and 100Mbps devices. (The most popular type of Ethernet in 2002 is 100Mbps, although 1000Mbps, or gigabit Ethernet, is gaining in popularity, and 10 gigabit Ethernet is being developed.)

In addition to three common Ethernet speeds, there are several different types of Ethernet cabling: coaxial (used only with some forms of 10Mbps Ethernet), twisted-pair (used by some types of 10Mbps, all types of 100Mbps, and some forms of gigabit Ethernet), and fiber-optic (used by some forms of gigabit Ethernet). Twisted-pair cabling supports distances of up to 100 meters (m) between devices (one of which is normally a central hub or switch), and fiber-optic cabling permits distances of up to 5 kilometers (km) between devices.

The organization of the 10 or 100Mbps driver menu is less than perfect. The menu begins with listings for several popular or once-popular devices from 3Com, SMC, Racal-Interlan, and a few other companies; proceeds with a grouping of Industry Standard Architecture (ISA) bus cards; continues with a grouping of Extended ISA (EISA), VESA Local Bus (VLB), and Peripheral Component Interconnect (PCI) cards; and concludes with a grouping of parallel-to-Ethernet adapters. You may need to search for your card in two or three places because of this organization.

A few Ethernet devices aren't activated through drivers in the Network Device Support menu or its submenus. Specifically, PC Card devices have their own drivers, as described shortly, and USB-to-Ethernet adapters are activated in the USB Support menu. To use a USB device, you must activate Support for USB; either UHCI Support or OHCI Support, depending upon which type of controller your motherboard uses; and an appropriate USB network driver option, such as USB ADMtek Pegasus-Based Ethernet Device Support.

Network Hardware Options

The Network Device Support kernel menu contains options related to network hardware. The most important of these options are drivers for specific network cards. The most common types of network cards today are Ethernet devices, but others include traditional local network hardware, long-distance devices, and wireless devices. PC Card devices (for notebook computers) have their own submenu off of the Network Device Support menu. You also select dial-up devices (used to establish connections over telephone modems and some other types of hardware) here.

Most of these devices require that you select the Network Device Support option at the top of the Network Device Support menu. If you fail to do this, other options won't be available.

Alternative Network Stack Options

Although TCP/IP is the most popular set of network protocols for Linux, and the one upon which the Internet is built, it's not the only choice of network protocol stack. The Networking Options menu includes several others. Most of the options in this menu are actually suboptions of TCP/IP Networking. If you scroll past these, you'll see the alternatives to TCP/IP:

• Asynchronous Transfer Mode (ATM) — This is an experimental set of options to support ATM hardware and protocols. ATM is really at least as much of a hardware definition as a network stack, but in the 2.4.x kernels, it's enabled in the Networking Options menu, along with other protocol stacks.

• The IPX Protocol — Novell's Internetwork Packet Exchange (IPX) is a protocol stack that's used on many local networks, particularly those running the Netware server OS. To use this stack, you'll need additional software, such as Mars_nwe (documented at http://www.redhat.com/support/docs/tips/Netware/netware.html). The NCP File System Support option in the Network File Systems submenu of the File Systems menu will let you mount Netware volumes, much as the equivalent NFS and SMB/CIFS options let you mount NFS exports or Windows file shares.

• AppleTalk Protocol Support — Apple developed the AppleTalk protocol stack to enable file and printer sharing on its Macintosh computers. Linux supports AppleTalk through a combination of the kernel and the Netatalk package (http://netatalk.sourceforge.net/).

• DECnet Support — Digital Equipment Corporation (DEC; since bought out by Compaq) developed a network technology known as DECnet for its computers. Linux includes support for DECnet, but you must have a package of programs to use this protocol stack. Check http://linux-decnet.sourceforge.net for more information.

Linux also includes support for a handful of more obscure network protocols, such as Acorn's Econet. On most systems, TCP/IP and possibly one or two other protocols will be quite sufficient. Because of the success of the Internet, vendors who had previously used proprietary protocol stacks have been converting their tools to use TCP/IP. For instance, although Apple has long used AppleTalk, its file-sharing tools now work both over plain AppleTalk and a TCP/IP-based variant.

The standard Linux kernel lacks support for one common network stack, NetBEUI. This stack was the default for Windows file sharing via SMB/CIFS in the past, but SMB/CIFS today works equally well over TCP/IP.

SMB/CIFS Options

NFS isn't the only network file-sharing protocol available. Macintoshes often use AppleTalk, for instance, and Novell's IPX/SPX is a popular protocol stack with associated file-sharing tools. Perhaps the most common file-sharing tool for Linux, aside from NFS, is Samba, which implements the Server Message Block (SMB) protocol, which is also known as the Common Internet Filesystem (CIFS). Chapter 7, File and Printer Sharing via Samba, covers Samba configuration and use.

Samba provides everything needed for Linux to function as an SMB/CIFS server, so there's no kernel configuration required for this function. If you want Linux to be able to mount SMB/CIFS shares, though, you must activate the SMB File System Support option, which is roughly equivalent to NFS File System Support for NFS. Two suboptions (Use a Default NLS and Default Remote NLS Option) let Linux perform filename translations based on National Language Support (NLS) character sets. These options may be important if you use non-Roman alphabets like Cyrillic, or even extensions to the Roman alphabet as used by English, like characters that contain umlauts.

It's possible to use Linux as an SMB/CIFS client using the smbclient program, even if you don't activate Linux's SMB/CIFS kernel options. smbclient doesn't actually mount an SMB/CIFS share, though; it gives you access to the share using an FTP-like interface.

NFS Options

Sun developed the Network Filesystem (NFS) as a way to share files among several computers as if those files were local. Linux includes support for NFS, as detailed in Chapter 8, File Sharing via NFS. To mount remote NFS exports, you must include NFS support in the kernel. Most Linux NFS servers also rely on support in the kernel. Both client and server NFS options reside in the Network File Systems submenu off of the File Systems menu, not in the Networking Options menu. Specifically, options you might want to activate include the following:

• NFS File System Support— This option enables basic NFS client support (that is, the ability to mount remote NFS exports as if they were local disk partitions). Enable it if you want to mount NFS directories exported by other computers.

• Provide NFSv3 Client Support— NFS has undergone various revisions, the latest of which is version 3 (NFSv3). This support must currently be explicitly enabled, because it's not as reliable as is support for older versions of NFS, as activated by NFS File System Support. The NFSv3 support relies on the basic NFS support.

• Root File System on NFS— If you select IP: Kernel Level Autoconfiguration in the Networking Options menu, you can select this option, which lets Linux mount its root filesystem from an NFS export. You'll normally only use this option on workstations that lack hard disks.

• NFS Server Support— To have Linux function as an NFS server (that is, to make some or all of its directories available to other computers), you need to run an NFS server. This option provides acceleration features for NFS servers that are written to take advantage of it. This option is not strictly required to run an NFS server, but it's generally a good idea to include it, since most Linux NFS servers are written to expect this support.

• Provide NFSv3 Server Support— If you want to run a kernel-aware NFS server for clients that understand NFSv3, activate this option. As with NFSv3 client support, this option relies upon the matching generic NFS support.

NFS is used mainly by Unix and Linux systems. File sharing between other platforms is usually handled by other tools, one of which is discussed next.

HTTP Acceleration

The Hypertext Transfer Protocol (HTTP) is at the core of the World Wide Web. Beginning with the 2.4.x kernels, Linux includes what is effectively a simple HTTP server in the kernel. This server is included with the Kernel HTTPd Acceleration option and configured and activated by writing specific values to pseudofiles in the /proc/sys/net/khttpd directory, as described in Chapter 20, Running Web Servers.

The kernel's HTTP server was created because the work of serving static Web pages (that is, those whose contents are fixed, as opposed to dynamic pages whose contents may be customized for individual users) is essentially just one of copying files from disk to a network address. This operation can be performed much more efficiently in the kernel than in a user-space program. For dynamic content and even some types of static content, the kernel's server falls back on a user-space Web server such as Apache. No special Apache configuration is required; Apache simply doesn't see requests for static Web pages.

High-Level Protocol Support

The Linux kernel includes explicit support for several high-level network protocols. Placing this support in the kernel has two principal advantages. First, this code can run more quickly than can an ordinary user-level program. Second, placement in the kernel permits a tighter integration of the features of that protocol with the rest of the system. For instance, kernel-level support for network file-sharing protocols allows Linux to mount remote file exports as if they were local filesystems. The 2.4.x kernel includes support for three particularly important high-level protocols: HTTP, NFS, and SMB/CIFS.

This list of protocols is not comprehensive. Several others (particularly for network file-sharing protocols) are supported.

QoS Options

Suppose your Linux system is a router for a busy domain, or is a major server that processes a lot of traffic. In situations like this, it's not uncommon for Linux to find that it has more packets to process than it can send over its network interfaces. Thus, Linux needs some system for scheduling the transmission of outgoing packets. Ordinarily, Linux uses a first-in/first-out (FIFO) strategy, in which each outgoing packet waits in line behind all the others that have already been queued. In some situations, however, you might not want to use this system. You might want to favor certain types of packets, such as those delivered to certain networks or those that involve certain protocols. For instance, you might want to favor packets that carry real-time data, such as Internet telephony protocols. Adjusting packet priorities is the job of the quality of service (QoS) options. These options are all available from the QoS and/or Fair Queueing menu off of the Networking Options menu.

In order to implement a QoS system, you must select the QoS and/or Fair Queueing option in the menu of the same name. This action enables many of the options on this menu. A few others rely upon your selection of one or more other specific options. The most basic features are enabled by the various packet scheduler and queue options, such as CBQ Packet Scheduler and SFQ Queue. These options allow the kernel to schedule packets in more complex ways than the default FIFO. The QoS Support and Packet Classifier API options, as well as their individual suboptions, enable the use of Differentiated Services and the Resource Reservation Protocol (RSVP). These both allow routers to communicate QoS priorities to other routers. If all the routers between two sites implement compatible QoS protocols, the end result can be greatly improved performance for time-critical protocols, at the expense of less time-critical protocols.

Most nonrouter systems don't need any QoS options. If you're configuring a Linux computer as a router, though—particularly a heavily used router—you may want to activate these options. If you activate one, it may make sense to activate them all, because without all options activated, the tools you use to specify QoS criteria won't be as flexible. For instance, if you omit the U32 Classifier option, you won't be able to prioritize traffic according to the destination address.

In practice, using QoS features requires the use of advanced routing tools, such as ip and tc. Chapter 24 touches upon these tools, but they can be extremely complex. The iproute2 + tc Notes (http://snafu.freedom.org/linux2.2/iproute-notes.html) and Differentiated Services on Linux (http://diffserv.sourceforge.net) Web sites contain additional documentation on these tools.

IPv6 Support Options

The Internet is built on TCP/IP protocols, and particularly on version 4 of the IP protocols (IPv4). Unfortunately, IPv4 is showing its age in many ways. For instance, it supports IP addresses that are four bytes (32 bits) in length, meaning that there is a theoretical maximum of 232, or 4,294,967,296, addresses. Because of inefficiencies in the way addresses are assigned, the number of Internet addresses is actually much lower than this. Consequently, the Internet is running out of addresses. IPv4 also has security limitations that allow miscreants to seriously disrupt Internet operation. These problems are not severe in 2002, but they're likely to become critical well before decade's end.

For these reasons, an upgrade to IPv4, known as IPv6, is under development. Among other things, IPv6 uses a 128-bit IP address for a theoretical maximum of 2128, or 3.4 x 1038 addresses—enough for 2.2 x 1018 addresses per square millimeter of land surface on the Earth. IPv6 also includes better hooks for certain types of security systems than does IPv4. In 2002, few networks allow the use of IPv6, but if yours is one, or if you want to experiment with IPv6 on a private internal network, you can activate experimental Linux IPv6 support via the IPv6 Protocol (Experimental) option in the Networking Options menu. Once you do this, another option or two may become available, including an entire submenu entitled IPv6: Netfilter Configuration. This submenu includes a subset of options similar to those described earlier, in "Network Filter Options," but geared towards IPv6 rather than IPv4.

TCP/IP Routing Options

A router (also referred to as a gateway) is a computer that transfers data between two or more networks. For instance, a department at a large company or university is likely to have a router to link its own subnetwork with the larger network that belongs to the company or university as a whole. The company or university will then have a router to link all of its computers to the Internet. This topic is important enough that Chapter 24, Advanced Router Options, is devoted to the subject. For now, know that the Linux kernel includes several options that can influence its router operation. These are clustered as suboptions of IP: Advanced Router. Chapter 24 discusses the configuration and use of these options in more detail.

Network Filter Options

Network filters are designed to allow the system to block or modify packets that come into or leave a computer. One of these options (packet filtering) is particularly important for constructing firewalls or performing IP masquerading, as discussed in Chapter 25, Configuring iptables. A firewall can block certain types of undesirable access to a computer or a network that it protects, and IP masquerading lets you share a single IP address among an entire network. Specific kernel network filter options include the following:

• Socket Filtering— Normally, the kernel passes all packets that it receives for a given socket on to the program that created the socket. This option allows the program to point the kernel to a small program (known as a filter) that will block some of the packets it receives. Few programs require this facility, but the Dynamic Host Configuration Protocol (DHCP) is an important exception—both recent

• Network Packet Filtering— This option is the 2.4.x kernel's most important type of filter, because it enables certain firewall and IP masquerading techniques. Because these are so important, it's generally a good idea to include this support. When you do so, the Network Packet Filtering Debugging option becomes available, which you can enable if you experience problems. A later submenu, IP: Netfilter Configuration, also becomes available. Subsequent items in this list appear on this submenu.

• Connection Tracking— Enabling this option allows the kernel to track network connections in greater detail than is normal. For instance, a router usually passes packets more-or-less blindly between two network interfaces, but when this option is enabled (both in the kernel and by user-level tools), Linux can match up the source and destination IP addresses and ports for future reference. This feature is required for IP masquerading, so it should be enabled on a computer that is to function in this way. It's not necessary for most other systems. If you enable it, the FTP protocol support option becomes available. FTP requires extra housekeeping, so enable this option if you want to use FTP on an IP masqueraded connection.

• IP Tables Support— This option includes kernel support routines for the iptables utility, which is used to set up packet filter firewalls and IP masquerading, as discussed in Chapter 25. Activating this option also allows you to select a number of suboptions that fine-tune the features available to you. Many of these options have names of the form Criterion Type Match Support, which enables the kernel to match on the specified Criterion Type. Of these, Connection State Match Support is particularly important, because it allows the system to perform stateful packet inspection, a useful form of firewall operation discussed in Chapter 25. The Packet Filtering, Full NAT, and LOG Target Support options are also very important, as are each of their suboptions. Enable all of these features if you want to use a computer as an IP masquerading router or firewall. You can omit Full NAT for a standalone workstation or server.

• ipchains (2.2-Style) Support— If you have an older firewall script that's based on the ipchains utility used by the 2.2.x kernels, you can activate support for this utility as long as you don't compile IP Tables Support directly into the kernel. (The ipchains and iptables tools are mutually incompatible methods of doing largely the same things, but iptables is more advanced.) If you're creating a firewall from scratch, you can safely omit ipchains support.

• ipfwadm (2.0-Style) Support— The 2.0.x kernels used a firewall tool called ipfwadm. If you have an ipfwadm-based firewall script, you can use it by compiling this feature, which is incompatible with both the iptables and ipchains support. Unless you have such a script and lack the inclination to modify it to use iptables, you can safely omit this option.

Between the 2.0.x and 2.4.x kernels, Linux's network filtering options have become more sophisticated. The 2.4.x kernel includes many optional features, and it's important that you activate all those you'll need for the type of firewall you intend to implement. When in doubt about a specific feature in the IP: Netfilter Configuration menu, I recommend you activate it. This will increase the kernel's size slightly, but it will also provide you with greater flexibility in designing firewall rules.

Network Protocol Support

The Networking Options kernel menu contains options related to network protocols. You can include or exclude support for entire protocol stacks, and for some (particularly TCP/IP), you can fine-tune the support to optimize the kernel for particular roles, such as router options or packet filtering.
Packet and Socket Options

At a fairly low level, Linux networking operates by allowing programs to send or receive chunks of data (known as packets) via data structures known as sockets. In most cases, a program opens a socket in a manner that's similar to the way a program opens a file. The program can then send and receive data via that socket. The network protocol stack (discussed shortly in "Alternative Network Stack Options") processes the data in ways that allow it to reach its destination or to be interpreted by the program after having been received from the sender.

In some cases, it's desirable or even necessary to process network data in some other way, or to modify or extend the standard packet and socket operations. Some of these options are important enough that they have their own sections. A few miscellaneous options include the following:

• Packet Socket— This option allows applications to bypass much of the normal protocol stack. Most programs don't need this feature, but some network diagnostic tools and other low-level utilities do need it. For instance, tcpdump, which displays low-level TCP/IP packet information, uses this kernel option. Including this option unnecessarily will slightly increase the size of the kernel and might allow an intruder to use low-level network diagnostics like tcpdump that you'd rather the intruder not be able to use. Omitting this feature will prevent you from running these utilities, though.

• Packet Socket: Mmapped IO— This is a packet socket suboption that, if enabled, can improve the performance of tools that use packet socket connections.

• Unix Domain Sockets— Several common and important Linux programs use networking protocols to communicate with each other when they run on a single computer. Examples include syslogd (which handles log files) and X (X programs use network protocols to communicate with the X server, which displays their windows). The Unix Domain Sockets option allows this within-computer communication even on systems that lack conventional network hardware. When computers have conventional hardware, the domain sockets approach is faster than using the more general-purpose TCP sockets. You should include this option on all normal Linux systems; only specialized embedded devices or the like might lack this option.

These options all have default settings that are reasonable for most installations. You might want to disable packet socket support on some systems, though.

Starting Kernel Configuration

To configure compile-time kernel options, you must begin with the kernel source code. All major distributions ship with this, but it may or may not be installed by default. Many distributions make changes to the standard kernel (say, to add new drivers that aren't yet standard). You may prefer to start with a standard kernel and add only those patches you need (it's possible you won't need any). Check http://www.kernel.org/ or a major Linux archive site like ftp://sunsite.unc.edu/ for the latest kernel source code. (You can also obtain kernel source code from your Linux distribution, but many distributions ship with kernels that have been patched to include non-standard drivers. Using a more standard kernel can be beneficial if you run into problems and need help solving them.)

Kernel source code normally resides in /usr/src/linux, or in a subdirectory of /usr/src that includes the kernel version number, like /usr/src/linux-2.4.17. In the latter case, it's common practice to create a symbolic link called /usr/src/linux and point it to the true Linux source directory. This allows other programs that assume the source is in /usr/src/linux to function correctly, even if you want to keep multiple versions of the kernel source code; you can simply change the symbolic link as required.

Once you've uncompressed the kernel source code into /usr/src/linux, you should change to that directory in a normal command shell. You can then issue a command to configure the kernel options. Possibilities include the following:

• make config— This is the basic configuration tool. It asks you about every kernel option in turn, which can be tedious. If you make a mistake, you must normally go back and redo everything. For this reason, it's seldom used today.

• makemenuconfig— This configuration procedure uses text-based menus for configuration options, which enables you to look through the options and adjust only those that require changes. This is a common method of configuration in text-mode environments.

• make xconfig— This method is similar to make menuconfig, except that make xconfig uses GUI configuration menus. You can click on a topic to see its options, then click your mouse to select how or if you want to compile any option. This is a popular means of kernel configuration when the X Window System (or X for short) is running.

All of these methods present the same options, which are organized into broad categories. (Some categories also include subcategories.) When you select one category with make menuconfig or make xconfig, a new menu appears showing the options within that category. (Figure 1.1 shows this for make xconfig.) Of particular interest for networking are the Networking Options and Network Device Support categories, which are the subject of the next two sections.

Linux kernel compilation options are organized into categories and subcategories, each with its own menu

Kernel Network Configuration

"All roads lead to Rome," the saying goes. Something similar is true of Linux networking, except that in this case, Rome is the Linux kernel. Sooner or later, all network traffic passes through the kernel. Given that not all computers or networks are identical, the Linux kernel includes several options you can set to optimize a system for your specific needs. You can set some of these options by passing parameters to the kernel, either during the boot process or after the system has booted, and many of these cases are covered in subsequent chapters of this book. In other cases you must recompile your kernel to activate a needed option or to deactivate one that might degrade your system's performance.

This chapter is devoted to discussing these kernel configuration options. First up is a discussion of kernel configuration procedures. Next is information on network protocol options, such as TCP/IP features, network filters, and support for non-TCP/IP protocol stacks. Next comes a discussion of Linux's drivers for various types of network hardware. The chapter concludes with a brief overview of the process of kernel compilation and use.