mirror of https://github.com/tLDP/LDP
1385 lines
57 KiB
Plaintext
1385 lines
57 KiB
Plaintext
<chapter id="X-087-2-hardware"><title>Configuring<?lb>the Networking<?lb>Hardware</title> <indexterm id="idx-configuringnetworkhardware-1"
|
|
class="startofrange"><primary>configuring</primary><secondary>networks</secondary><tertiary>hardware</tertiary></indexterm>
|
|
<indexterm id="idx-hardwarenetworking-1"
|
|
class="startofrange"><primary>hardware</primary><secondary>configuration
|
|
of networking</secondary></indexterm> <indexterm
|
|
id="ch03.net.hw.config"
|
|
class="startofrange"><primary>networks</primary><secondary>hardware,
|
|
configuring</secondary></indexterm>
|
|
|
|
<indexterm><primary>networks</primary><secondary>devices</secondary></indexterm>
|
|
<indexterm><primary>interfaces</primary></indexterm>
|
|
<para>
|
|
We've been talking quite a bit about network interfaces and general
|
|
TCP/IP issues, but we haven't really covered what happens when the
|
|
“networking code” in the kernel accesses a piece of
|
|
hardware. In order to describe this accurately, we have to talk a
|
|
little about the concept of interfaces and drivers.
|
|
</para>
|
|
|
|
<para>
|
|
First, of course, there's the hardware itself, for example an
|
|
Ethernet, FDDI or Token Ring card: this is a slice of Epoxy cluttered
|
|
with lots of tiny chips with strange numbers on them, sitting in a
|
|
slot of your PC. This is what we generally call a physical device.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Ethernet</primary><secondary>cards</secondary></indexterm>
|
|
<indexterm><primary>device drivers</primary></indexterm> For you to
|
|
use a network card, special functions have to be present in your Linux
|
|
kernel that understand the particular way this device is accessed. The
|
|
software that implements these functions is called a <emphasis>device
|
|
driver</emphasis>. Linux has device drivers for many different types
|
|
of network interface cards: ISA, PCI, MCA, EISA, Parallel port, PCMCIA,
|
|
and more recently, USB.
|
|
</para>
|
|
|
|
<para>
|
|
But what do we mean when we say a driver “handles” a device? Let's
|
|
consider an Ethernet card. The driver has to be able to communicate with the
|
|
peripheral's on-card logic somehow: it has to send commands and data to the
|
|
card, while the card should deliver any data received to the driver.
|
|
</para>
|
|
|
|
<para>
|
|
In IBM-style personal computers, this communication takes place through a
|
|
cluster of I/O addresses that are mapped to registers on the card and/or
|
|
through shared or direct memory transfers. All commands and data the kernel
|
|
sends to the card have to go to these addresses. I/O and memory addresses are
|
|
generally described by providing the starting or
|
|
<emphasis>base address</emphasis>. Typical base addresses for ISA bus Ethernet
|
|
cards are <literal>0x280</literal> or <literal>0x300</literal>. PCI bus
|
|
network cards generally have their I/O address automatically assigned.
|
|
</para>
|
|
|
|
<para>
|
|
Usually you don't have to worry about any hardware issues such as the
|
|
base address because the kernel makes an attempt at boot time to
|
|
detect a card's location. This is called <emphasis>auto
|
|
probing</emphasis>, which means that the kernel reads several memory
|
|
or I/O locations and compares the data it reads there with what it
|
|
would expect to see if a certain network card were installed at that
|
|
location. However, there may be network cards it cannot detect
|
|
automatically; this is sometimes the case with cheap network cards
|
|
that are not-quite clones of standard cards from other
|
|
manufacturers. Also, the kernel will normally attempt to detect only
|
|
one network device when booting. If you're using more than one card,
|
|
you have to tell the kernel about the other cards explicitly.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IRQ (Interrupt Request)</primary></indexterm>
|
|
Another parameter that you might have to tell the kernel about is the
|
|
interrupt request line. Hardware components usually interrupt the
|
|
kernel when they need to be taken care of—for example, when data
|
|
has arrived or a special condition occurs. In an ISA bus PC,
|
|
interrupts may occur on one of 15 interrupt channels numbered 0, 1,
|
|
and 3 through 15. The interrupt number assigned to a hardware
|
|
component is called its <emphasis>interrupt request
|
|
number</emphasis> (IRQ).<footnote id="X-087-2-FNHW01"><para> IRQs 2 and
|
|
9 are the same because the IBM PC design has two cascaded interrupt
|
|
processors with eight IRQs each; the secondary processor is connected
|
|
to IRQ 2 of the primary one.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>interface</secondary></indexterm>
|
|
<indexterm><primary>interfaces</primary></indexterm>
|
|
As described in <xref linkend="X-087-2-issues">, the kernel accesses a piece
|
|
of network hardware through a software construct called an
|
|
<emphasis>interface</emphasis>.
|
|
Interfaces offer an abstract set of functions that are the same across all
|
|
types of hardware, such as sending or receiving a datagram.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>device files</primary></indexterm>
|
|
<indexterm><primary>devices</primary><secondary>major/minor
|
|
numbers</secondary></indexterm> Interfaces are identified by means of
|
|
names. In many other Unix-like operating systems, the network
|
|
interface is implemented as a special device file in the
|
|
<filename>/dev/</filename> directory. If you type the <literal>ls -las
|
|
/dev/</literal> command, you will see what these device files look
|
|
like. In the file permissions (second) column you will see that device
|
|
files begin with a letter rather than the hyphen seen for normal
|
|
files. This character indicates the device type. The most common
|
|
device types are <literal>b</literal>, which indicates the device is a
|
|
<emphasis>block</emphasis> device and handles whole blocks of data
|
|
with each read and write, and <literal>c</literal>, which indicates
|
|
the device is a <emphasis>character</emphasis> device and handles data
|
|
one character at a time. Where you would normally see the file length
|
|
in the <command>ls</command> output, you instead see two numbers,
|
|
called the major and minor device numbers. These numbers indicate the
|
|
actual device with which the device file is associated.
|
|
</para>
|
|
|
|
<para>
|
|
Each device driver registers a unique major number with the kernel.
|
|
Each <emphasis>instance</emphasis> of that device registers a unique
|
|
minor number for that major device. The <literal>tty</literal>
|
|
interfaces, <filename>/dev/tty*</filename>, are a character
|
|
mode device indicated by the “<literal>c</literal>”, and
|
|
each have a major number of <literal>4</literal>, but
|
|
<filename>/dev/tty1</filename> has a minor number of
|
|
<literal>1</literal>, and <filename>/dev/tty2</filename> has a minor
|
|
number of <literal>2</literal>. Device files are very useful for
|
|
many types of devices, but can be clumsy to use when trying to find an
|
|
unused device to open.
|
|
</para>
|
|
|
|
<para>
|
|
Linux interface names are defined internally in the kernel and are not
|
|
device files in the <filename>/dev</filename> directory. Some typical
|
|
device names are listed later in <xref
|
|
linkend="X-087-2-hwconfig.tour">.” The assignment of interfaces to
|
|
devices usually depends on the order in which devices are
|
|
configured. For instance, the first Ethernet card installed will
|
|
become <filename>eth0</filename>, and the next will be
|
|
<filename>eth1</filename>. SLIP interfaces are handled differently
|
|
from others because they are assigned dynamically. Whenever a SLIP
|
|
connection is established, an interface is assigned to the serial
|
|
port.
|
|
</para>
|
|
|
|
<para>
|
|
<xref linkend="X-087-2-hardware.fig.drivers"> illustrates the relationship
|
|
between the hardware, device drivers, and interfaces.
|
|
</para>
|
|
|
|
<figure id="X-087-2-hardware.fig.drivers">
|
|
<title>The relationship between drivers, interfaces, and hardware</title>
|
|
<!-- <graphic fileref="lag2_0301.jpg"></graphic> -->
|
|
<!-- 2016-01-28; MAB, TLDP -->
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0301.jpg" format="jpg">
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0301.eps" format="eps">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para>
|
|
When booting, the kernel displays the devices it detects and the
|
|
interfaces it installs. The following is an excerpt from typical
|
|
boot messages:
|
|
<screen>
|
|
.
|
|
. This processor honors the WP bit even when in supervisor mode./
|
|
Good.
|
|
Swansea University Computer Society NET3.035 for Linux 2.0
|
|
NET3: Unix domain sockets 0.13 for Linux NET3.035.
|
|
Swansea University Computer Society TCP/IP for NET3.034
|
|
IP Protocols: IGMP,ICMP, UDP, TCP
|
|
Swansea University Computer Society IPX 0.34 for NET3.035
|
|
IPX Portions Copyright (c) 1995 Caldera, Inc.
|
|
Serial driver version 4.13 with no serial options enabled
|
|
tty00 at 0x03f8 (irq = 4) is a 16550A
|
|
tty01 at 0x02f8 (irq = 3) is a 16550A
|
|
CSLIP: code copyright 1989 Regents of the University of California
|
|
PPP: Version 2.2.0 (dynamic channel allocation)
|
|
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
|
|
PPP line discipline registered.
|
|
eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 0e e4 e0,/
|
|
IRQ 10.
|
|
3c509.c:1.12 6/4/97 becker@cesdis.gsfc.nasa.gov
|
|
Linux Version 2.0.32 (root@perf) (gcc Version 2.7.2.1)
|
|
#1 Tue Oct 21 15:30:44 EST 1997
|
|
.
|
|
.
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
This example shows that the kernel has been compiled with TCP/IP
|
|
enabled, and it includes drivers for SLIP, CSLIP, and PPP. The third
|
|
line from the bottom says that a 3C509 Ethernet card was detected and
|
|
installed as interface <filename>eth0</filename>. If you have some
|
|
other type of network card—perhaps a D-Link pocket adaptor, for
|
|
example—the kernel will usually print a line starting with its
|
|
device name—<filename>dl0</filename> in the D-Link
|
|
example—followed by the type of card detected. If you have a
|
|
network card installed but don't see any similar message, the kernel
|
|
is unable to detect your card properly. This situation will be
|
|
discussed later in the section “Ethernet Autoprobing.”
|
|
</para>
|
|
|
|
|
|
<sect1 id="X-087-2-hardware.kernel.config"><title>Kernel Configuration</title>
|
|
<indexterm id="ch03.kernel.config" class="startofrange"><primary>kernels</primary><secondary>configuration</secondary></indexterm>
|
|
<para>
|
|
Most Linux distributions are supplied with boot disks that work for
|
|
all common types of PC hardware. Generally, the supplied kernel is
|
|
highly modularized and includes nearly every possible driver. This is
|
|
a great idea for boot disks, but is probably not what you'd want for
|
|
long-term use. There isn't much point in having drivers cluttering up
|
|
your disk that you will never use. Therefore, you will generally roll
|
|
your own kernel and include only those drivers you actually need or
|
|
want; that way you save a little disk space and reduce the time it
|
|
takes to compile a new kernel.
|
|
</para>
|
|
|
|
<para>
|
|
In any case, when running a Linux system, you should be familiar with
|
|
building a kernel. Think of it as a right of passage, an affirmation of
|
|
the one thing that makes free software as powerful as it is—you have
|
|
the source. It isn't a case of, “I have to compile a kernel,”
|
|
rather it's a case of, “I <emphasis>can</emphasis> compile a
|
|
kernel.” The basics of compiling a Linux kernel are explained in Matt
|
|
Welsh's book, <emphasis>Running Linux</emphasis> (O'Reilly). Therefore, we
|
|
will discuss only configuration options that affect networking in this
|
|
section.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>kernel version numbering</primary></indexterm>
|
|
<indexterm><primary>Linux kernel</primary><secondary>version numbering
|
|
of</secondary></indexterm> One important point that does bear
|
|
repeating here is the way the kernel version numbering scheme
|
|
works. Linux kernels are numbered in the following format:
|
|
<literal>2.2.14</literal>. The first digit indicates the
|
|
<emphasis>major</emphasis> version number. This digit changes when
|
|
there are large and significant changes to the kernel design. For
|
|
example, the kernel changed from major 1 to 2 when the kernel obtained
|
|
support for machines other than Intel machines. The second number is
|
|
the <emphasis>minor</emphasis> version number. In many respects, this
|
|
number is the most important number to look at. The Linux development
|
|
community has adopted a standard at which <emphasis>even</emphasis> minor
|
|
version numbers indicate <emphasis>production</emphasis>, or
|
|
<emphasis>stable</emphasis>, kernels and <emphasis>odd</emphasis>
|
|
minor version numbers indicate <emphasis>development</emphasis>, or
|
|
<emphasis>unstable</emphasis>, kernels. The stable kernels are what
|
|
you should use on a machine that is important to you, as they have
|
|
been more thoroughly tested. The development kernels are what you
|
|
should use if you are interested in experimenting with the newest
|
|
features of Linux, but they may have problems that haven't yet been
|
|
found and fixed. The third number is simply incremented for each
|
|
release of a minor version.<footnote id="X-087-2-FNHW02"><para>
|
|
<?troff .hw REPORTING>
|
|
People should use development kernels and report bugs if they are
|
|
found; this is a very useful thing to do if you have a machine you can use
|
|
as a test machine. Instructions on how to report bugs are detailed in
|
|
<filename>/usr/src/linux/REPORTING-BUGS</filename> in the Linux kernel
|
|
source.
|
|
</para>
|
|
</footnote>
|
|
</para>
|
|
|
|
<para>
|
|
When running <command>make menuconfig</command>, you are presented with
|
|
a text-based menu that offers lists of configuration questions, such as
|
|
whether you want kernel math emulation. One of these queries asks you
|
|
whether you want TCP/IP networking support. You must answer this with
|
|
<literal>y</literal> to get a kernel capable of networking.
|
|
</para>
|
|
|
|
<sect2><title>Kernel Options in Linux 2.0 and Higher</title>
|
|
<indexterm><primary>configuring</primary><secondary>kernel</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>kernel options</secondary></indexterm>
|
|
<indexterm><primary>configuring</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>configuring</primary><secondary>SLIP</secondary></indexterm>
|
|
<indexterm><primary>configuring</primary><secondary>PLIP</secondary></indexterm>
|
|
<indexterm><primary>configuring</primary><secondary>PPP</secondary></indexterm>
|
|
<para>
|
|
|
|
After the general option section is complete, the configuration will
|
|
go on to ask whether you want to include support for various features,
|
|
such as SCSI drivers or sound cards. The prompt will indicate what
|
|
options are available. You can press <prompt>?</prompt> to obtain a
|
|
description of what the option is actually offering. You'll always
|
|
have the option of yes (<prompt>y</prompt>) to statically include the
|
|
component in the kernel, or no (<prompt>n</prompt>) to exclude the
|
|
component completely. You'll also see the module (<prompt>m</prompt>)
|
|
option for those components that may be compiled as a run-time
|
|
loadable module. Modules need to be loaded before they can be used,
|
|
and are useful for drivers of components that you use infrequently.
|
|
</para>
|
|
|
|
<para>
|
|
The subsequent list of questions deal with networking support.
|
|
The exact set of configuration options is in constant flux due to ongoing
|
|
development. A typical list of options offered by most kernel versions
|
|
around 2.0 and 2.1 looks like this:
|
|
|
|
<screen>
|
|
*
|
|
* Network device support
|
|
*
|
|
Network device support (CONFIG_NETDEVICES) [Y/n/?]
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
You must answer this question with <literal>y</literal> if you want to
|
|
use <emphasis>any</emphasis> type of networking devices, whether
|
|
they are Ethernet, SLIP, PPP, or whatever. When you answer the
|
|
question with <literal>y</literal>, support for Ethernet-type devices
|
|
is enabled automatically. You must answer additional questions if
|
|
you want to enable support for other types of network drivers:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
PLIP (parallel port) support (CONFIG_PLIP) [N/y/m/?] y
|
|
PPP (point-to-point) support (CONFIG_PPP) [N/y/m/?] y
|
|
*
|
|
* CCP compressors for PPP are only built as modules.
|
|
*
|
|
SLIP (serial line) support (CONFIG_SLIP) [N/y/m/?] m
|
|
CSLIP compressed headers (CONFIG_SLIP_COMPRESSED) [N/y/?] (NEW) y
|
|
Keepalive and linefill (CONFIG_SLIP_SMART) [N/y/?] (NEW) y
|
|
Six bit SLIP encapsulation (CONFIG_SLIP_MODE_SLIP6) [N/y/?] (NEW) y
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IPX (Internet Packet eXchange)</primary><secondary>PPP network protocol</secondary></indexterm>
|
|
<indexterm><primary>PPP (Point-to-Point Protocol)</primary><secondary>carrying IPX</secondary></indexterm>
|
|
These questions concern the various link layer protocols that Linux
|
|
supports. Both PPP and SLIP allow you to transport IP datagrams
|
|
across serial lines. PPP is actually a suite of protocols used to
|
|
send network traffic across serial lines. Some of the protocols that
|
|
form PPP manage the way that you authenticate yourself to the dial-in
|
|
server, while others manage the way certain protocols are carried
|
|
across the link—PPP is not limited to carrying TCP/IP datagrams;
|
|
it may also carry other protocol such as IPX.
|
|
</para>
|
|
|
|
<para>
|
|
If you answer <literal>y</literal> or <literal>m</literal> to SLIP
|
|
support, you will be prompted to answer the three questions that appear
|
|
below it. The compressed header option provides support for CSLIP, a
|
|
technique that compresses TCP/IP headers to as little as three bytes. Note
|
|
that this kernel option does not turn on CSLIP automatically; it merely
|
|
provides the necessary kernel functions for it. The <literal>Keepalive and
|
|
linefill</literal> option causes the SLIP support to periodically generate
|
|
activity on the SLIP line to avoid it being dropped by an inactivity timer. The
|
|
<literal>Six bit SLIP encapsulation</literal> option allows you to run
|
|
SLIP over lines and circuits that are not capable of transmitting the
|
|
whole 8-bit data set cleanly. This is similar to the uuencoding or binhex
|
|
technique used to send binary files by electronic mail.
|
|
</para>
|
|
|
|
<para>
|
|
PLIP provides a way to send IP datagrams across a parallel port connection.
|
|
It is mostly used to communicate with PCs running DOS. On typical PC hardware,
|
|
PLIP can be faster than PPP or SLIP, but it requires much more CPU overhead to
|
|
perform, so while the transfer rate might be good, other tasks on the machine
|
|
may be slow.
|
|
</para>
|
|
|
|
<para>
|
|
The following questions address network cards from various vendors.
|
|
As more drivers are being developed, you are likely to see questions added
|
|
to this section. If you want to build a kernel you can use on a number of
|
|
different machines, or if your machine has more than one type of network
|
|
card installed, you can enable more than one driver:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
.
|
|
.
|
|
Ethernet (10 or 100Mbit) (CONFIG_NET_ETHERNET) [Y/n/?]
|
|
3COM cards (CONFIG_NET_VENDOR_3COM) [Y/n/?]
|
|
3c501 support (CONFIG_EL1) [N/y/m/?]
|
|
3c503 support (CONFIG_EL2) [N/y/m/?]
|
|
3c509/3c579 support (CONFIG_EL3) [Y/m/n/?]
|
|
3c590/3c900 series (592/595/597/900/905) "Vortex/Boomerang" support/
|
|
(CONFIG_VORTEX) [N/y/m/?]
|
|
AMD LANCE and PCnet (AT1500 and NE2100) support (CONFIG_LANCE) [N/y/?]
|
|
AMD PCInet32 (VLB and PCI) support (CONFIG_LANCE32) [N/y/?] (NEW)
|
|
Western Digital/SMC cards (CONFIG_NET_VENDOR_SMC) [N/y/?]
|
|
WD80*3 support (CONFIG_WD80x3) [N/y/m/?] (NEW)
|
|
SMC Ultra support (CONFIG_ULTRA) [N/y/m/?] (NEW)
|
|
SMC Ultra32 support (CONFIG_ULTRA32) [N/y/m/?] (NEW)
|
|
SMC 9194 support (CONFIG_SMC9194) [N/y/m/?] (NEW)
|
|
Other ISA cards (CONFIG_NET_ISA) [N/y/?]
|
|
Cabletron E21xx support (CONFIG_E2100) [N/y/m/?] (NEW)
|
|
DEPCA, DE10x, DE200, DE201, DE202, DE422 support (CONFIG_DEPCA) [N/y/m/?]/
|
|
(NEW)
|
|
EtherWORKS 3 (DE203, DE204, DE205) support (CONFIG_EWRK3) [N/y/m/?] (NEW)
|
|
EtherExpress 16 support (CONFIG_EEXPRESS) [N/y/m/?] (NEW)
|
|
HP PCLAN+ (27247B and 27252A) support (CONFIG_HPLAN_PLUS) [N/y/m/?] (NEW)
|
|
HP PCLAN (27245 and other 27xxx series) support (CONFIG_HPLAN) [N/y/m/?]/
|
|
(NEW)
|
|
HP 10/100VG PCLAN (ISA, EISA, PCI) support (CONFIG_HP100) [N/y/m/?] (NEW)
|
|
NE2000/NE1000 support (CONFIG_NE2000) [N/y/m/?] (NEW)
|
|
SK_G16 support (CONFIG_SK_G16) [N/y/?] (NEW)
|
|
EISA, VLB, PCI and on card controllers (CONFIG_NET_EISA) [N/y/?]
|
|
Apricot Xen-II on card ethernet (CONFIG_APRICOT) [N/y/m/?] (NEW)
|
|
Intel EtherExpress/Pro 100B support (CONFIG_EEXPRESS_PRO100B) [N/y/m/?]/
|
|
(NEW)
|
|
DE425, DE434, DE435, DE450, DE500 support (CONFIG_DE4X5) [N/y/m/?] (NEW)
|
|
DECchip Tulip (dc21x4x) PCI support (CONFIG_DEC_ELCP) [N/y/m/?] (NEW)
|
|
Digi Intl. RightSwitch SE-X support (CONFIG_DGRS) [N/y/m/?] (NEW)
|
|
Pocket and portable adaptors (CONFIG_NET_POCKET) [N/y/?]
|
|
AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [N/y/?] (NEW)
|
|
D-Link DE600 pocket adaptor support (CONFIG_DE600) [N/y/m/?] (NEW)
|
|
D-Link DE620 pocket adaptor support (CONFIG_DE620) [N/y/m/?] (NEW)
|
|
Token Ring driver support (CONFIG_TR) [N/y/?]
|
|
IBM Tropic chipset based adaptor support (CONFIG_IBMTR) [N/y/m/?] (NEW)
|
|
FDDI driver support (CONFIG_FDDI) [N/y/?]
|
|
Digital DEFEA and DEFPA adapter support (CONFIG_DEFXX) [N/y/?] (NEW)
|
|
ARCnet support (CONFIG_ARCNET) [N/y/m/?]
|
|
Enable arc0e (ARCnet "Ether-Encap" packet format) (CONFIG_ARCNET_ETH)/
|
|
[N/y/?] (NEW)
|
|
Enable arc0s (ARCnet RFC1051 packet format) (CONFIG_ARCNET_1051)/
|
|
[N/y/?] (NEW)
|
|
.
|
|
.
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>configuring</primary><secondary>NFS</secondary></indexterm>
|
|
Finally, in the file system section, the configuration script will ask you
|
|
whether you want support for NFS, the networking file system. NFS lets you
|
|
export file systems to several hosts, which makes the files appear as if they
|
|
were on an ordinary hard disk attached to the host:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
NFS file system support (CONFIG_NFS_FS) [y]
|
|
</screen>
|
|
|
|
We describe NFS in detail in <xref linkend="X-087-2-nfs">.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2><title>Kernel Networking Options in Linux 2.0.0 <?lb>and Higher</title>
|
|
|
|
<para>
|
|
<indexterm><primary>Networking HOWTO</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>Networking</SECONDARY></INDEXTERM>
|
|
Linux 2.0.0 marked a significant change in Linux Networking. Many
|
|
features were made a standard part of the Kernel, such as support
|
|
for IPX. A number of options were also added and made
|
|
configurable. Many of these options are used only in very special
|
|
circumstances and we won't cover them in detail. The Networking HOWTO
|
|
probably addresses what is not covered here. We'll list a number of
|
|
useful options in this section, and explain when you'd want to use
|
|
each one:
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Basics</term>
|
|
<listitem><para> To use TCP/IP networking, you must answer this question with
|
|
<literal>y</literal>. If you answer with <literal>n</literal>, however, you
|
|
will still be able to compile the kernel with IPX support:
|
|
</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
Networking options --->
|
|
[*] TCP/IP networking
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Gateways</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>forwarding</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet
|
|
Protocol)</primary><secondary>forwarding</secondary></indexterm> You
|
|
have to enable this option if your system acts as a gateway between
|
|
two networks or between a LAN and a SLIP link, etc. It
|
|
doesn't hurt to enable this by default, but you may want to disable it to
|
|
configure a host as a so-called
|
|
<emphasis>firewall</emphasis>. Firewalls are hosts that are connected
|
|
to two or more networks, but don't route traffic between them. They're
|
|
commonly used to provide users with Internet access at minimal
|
|
risk to the internal network. Users are allowed to log in to the
|
|
firewall and use Internet services, but the company's machines are
|
|
protected from outside attacks because incoming connections can't
|
|
cross the firewall (firewalls are covered in detail in
|
|
<xref linkend="X-087-2-firewall"> ):
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
[*] IP: forwarding/gatewaying
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>Virtual hosting</term>
|
|
<listitem>
|
|
<para>
|
|
|
|
<INDEXTERM><PRIMARY>IP (Internet
|
|
Protocol)</PRIMARY><SECONDARY>aliasing</SECONDARY></INDEXTERM>
|
|
<indexterm><primary>aliasing, IP (Internet
|
|
Protocol)</primary></indexterm> These options together allow to you
|
|
configure more than one IP address onto an interface. This is
|
|
sometimes useful if you want to do “virtual hosting,”
|
|
through which a single machine can be configured to look and act as
|
|
though it were actually many separate machines, each with its own
|
|
network personality. We'll talk more about IP aliasing in a moment:
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
[*] Network aliasing
|
|
<*> IP: aliasing support
|
|
</screen>
|
|
</para>
|
|
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Accounting</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>IP accounting</primary></indexterm>
|
|
This option enables you to collect data on the volume of IP traffic leaving
|
|
and arriving at your machine (we cover this is detail in
|
|
<xref linkend="X-087-2-accounting"> ):
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
[*] IP: accounting
|
|
</screen>
|
|
</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>PC hug</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>PC/TCP compatibility</primary></indexterm>
|
|
This option works around an incompatibility with some versions of PC/TCP, a
|
|
commercial TCP/IP implementation for DOS-based PCs. If you enable this option,
|
|
you will still be able to communicate with normal Unix machines, but
|
|
performance may be hurt over slow links:
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
--- (it is safe to leave these untouched)
|
|
[*] IP: PC/TCP compatibility mode
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Diskless booting</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>RARP (Reverse Address Resolution Protocol)</primary></indexterm>
|
|
This function enables <emphasis>Reverse Address Resolution
|
|
Protocol</emphasis> (RARP). RARP is used by diskless clients and X terminals to
|
|
request their IP address when booting. You should enable RARP if you plan to
|
|
serve this sort of client. A small program called <command>rarp</command>,
|
|
included with the standard networking utilities, is used to add entries
|
|
to the kernel RARP table:
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
<*> IP: Reverse ARP
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>MTU</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>subnets</secondary></indexterm>
|
|
<indexterm><primary>subnets</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>Maximum Transmission Unit (MTU)</primary><secondary>IP</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>MTU</SECONDARY></INDEXTERM>
|
|
When sending data over TCP, the kernel has to break up the stream into blocks
|
|
of data to pass to IP. The size of the block is called the <emphasis>Maximum
|
|
Transmission Unit</emphasis>, or MTU. For hosts that can be reached over a
|
|
local network such as an
|
|
Ethernet, it is typical to use an MTU as large as the maximum length of an
|
|
Ethernet packet—1,500 bytes. When routing IP over a Wide Area Network
|
|
like the Internet, it is preferable to use smaller-sized datagrams to ensure
|
|
that they don't need to be further broken down along the route through a
|
|
process called <emphasis>IP fragmentation</emphasis>.<footnote id="X-087-2-FNHW03"><para>
|
|
Remember, the IP protocol can be carried over many different types of
|
|
network, and not all network types will support packet sizes as large
|
|
as Ethernet.
|
|
</para></footnote> The kernel is
|
|
able to automatically determine the smallest MTU of an IP route and to
|
|
automatically configure a TCP connection to use it. This behavior is on by
|
|
default. If you answer <literal>y</literal> to this option this feature
|
|
will be disabled.
|
|
</para>
|
|
|
|
<para>
|
|
If you do want to use smaller packet sizes for data sent to specific hosts
|
|
(because, for example, the data goes through a SLIP link), you can do so using
|
|
the <command>mss</command> option of the <command>route</command> command,
|
|
which is briefly discussed at the end of this chapter:
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
|
|
<para>
|
|
<screen>
|
|
[ ] IP: Disable Path MTU Discovery (normally enabled)
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Security feature</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>source routing</primary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>source routing</secondary></indexterm>
|
|
<indexterm><primary>RIP (Routing Information Protocol)</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>Routing Information Protocol (RIP)</PRIMARY></INDEXTERM>
|
|
<indexterm><primary>protocols</primary><secondary>Routing Information
|
|
Protocol (RIP)</secondary></indexterm>
|
|
<indexterm><primary>OSPF (Open Shortest Path First) protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>OSPF</secondary></indexterm>
|
|
The IP protocol supports a feature called <emphasis>Source
|
|
Routing</emphasis>. Source routing allows you to specify the route a
|
|
datagram should follow by coding the route into the datagram
|
|
itself. This was once probably useful before routing protocols such as
|
|
RIP and OSPF became commonplace. But today it's considered a security
|
|
threat because it can provide clever attackers with a way of
|
|
circumventing certain types of firewall protection by bypassing the
|
|
routing table of a router. You would normally want to filter out
|
|
source routed datagrams, so this option is normally enabled:
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
[*] IP: Drop source routed frames
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Novell support</term>
|
|
<listitem>
|
|
<para>
|
|
<indexterm><primary>configuring</primary><secondary>IPX</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>Internet Packet eXchange (IPX)</secondary></indexterm>
|
|
<indexterm><primary>IPX (Internet Packet eXchange)</primary><secondary>routing</secondary></indexterm>
|
|
This option enables support for IPX, the transport protocol Novell
|
|
Networking uses. Linux will function quite happily as an IPX router
|
|
and this support is useful in environments where you have Novell
|
|
fileservers. The NCP filesystem also requires IPX support enabled in
|
|
your kernel; if you wish to attach to and mount your Novell
|
|
filesystems you must have this option enabled (we'll dicuss IPX and
|
|
the NCP filesystem in <xref linkend="X-087-2-ipx">):
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>
|
|
<screen>
|
|
<*> The IPX protocol
|
|
</screen>
|
|
</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Amateur radio</term>
|
|
<listitem>
|
|
<para>
|
|
<INDEXTERM><PRIMARY>amateur radio protocols</PRIMARY></INDEXTERM>
|
|
<indexterm><primary>AX.25 protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
|
|
<indexterm><primary>NetRom protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>NetRom</secondary></indexterm>
|
|
<indexterm><primary>Rose protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>Rose</secondary></indexterm>
|
|
<indexterm><primary>AX25 HOWTO</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>AX25</SECONDARY></INDEXTERM>
|
|
These three options select support for the three Amateur Radio protocols
|
|
supported by Linux: AX.25, NetRom and Rose (we don't describe them in this
|
|
book, but they are covered in detail in the AX25 HOWTO):
|
|
|
|
<screen>
|
|
<*> Amateur Radio AX.25 Level 2
|
|
<*> Amateur Radio NET/ROM
|
|
<*> Amateur Radio X.25 PLP (Rose)
|
|
</screen>
|
|
</para>
|
|
|
|
<para> Linux supports another driver type: the dummy driver. The following
|
|
question appears toward the start of the device-driver section:
|
|
<screen>
|
|
<*> Dummy net driver support
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The dummy driver doesn't really do much, but it is quite useful on standalone
|
|
or PPP/SLIP hosts. It is basically a masqueraded loopback interface. On
|
|
hosts that offer PPP/SLIP but have no
|
|
other network interface, you want to have an interface that bears your IP
|
|
address all the time. This is discussed in a little more detail in
|
|
<xref linkend="X-087-2-iface.interface.dummy">" in
|
|
<xref linkend="X-087-2-iface">. Note that today you can achieve the same
|
|
result by using the IP alias feature and configuring your IP address as an
|
|
alias on the loopback interface.
|
|
<indexterm class="endofrange" startref="ch03.kernel.config">
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-hwconfig.tour"><title>A Tour of Linux Network Devices</title>
|
|
<indexterm><primary>devices</primary><secondary>Linux network</secondary></indexterm>
|
|
<indexterm><primary>networks</primary></indexterm>
|
|
<para>
|
|
The Linux kernel supports a number of hardware drivers for various
|
|
types of equipment. This section gives a short overview of the driver
|
|
families available and the interface names they use.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>interfaces</primary></indexterm> There is a number
|
|
of standard names for interfaces in Linux, which are listed here. Most
|
|
drivers support more than one interface, in which case the interfaces
|
|
are numbered, as in <filename>eth0</filename> and
|
|
<filename>eth1</filename>:
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
<varlistentry><term>
|
|
<filename>lo</filename></term>
|
|
<listitem><para>
|
|
<indexterm><primary>interfaces</primary><secondary>loopback</secondary></indexterm>
|
|
<indexterm><primary>loopback</primary><secondary>interface device</secondary></indexterm>
|
|
This is the local loopback interface. It is used for testing purposes, as
|
|
well as a couple of network applications. It works like a closed circuit in
|
|
that any datagram written to it will immediately be returned to the host's
|
|
networking layer. There's always one loopback device present in the kernel,
|
|
and there's little sense in having more.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>
|
|
<filename>eth0</filename>, <filename>eth1</filename>, …</term>
|
|
<listitem><para>
|
|
<indexterm><primary>eth1 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>Ethernet</secondary></indexterm>
|
|
These are the Ethernet card interfaces. They are used for most Ethernet cards,
|
|
including many of the parallel port Ethernet cards.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>
|
|
<filename>tr0</filename>, <filename>tr1</filename>, …</term>
|
|
<listitem><para>
|
|
<indexterm><primary>tr0 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>Token Ring</secondary></indexterm>
|
|
These are the Token Ring card interfaces. They are used for most Token Ring
|
|
cards, including non-IBM manufactured cards.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>
|
|
<filename>sl0</filename>, <filename>sl1</filename>, …</term>
|
|
<listitem><para>
|
|
<indexterm><primary>sl1 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>SLIP</secondary></indexterm>
|
|
These are the SLIP interfaces. SLIP interfaces are associated with serial
|
|
lines in the order in which they are allocated for SLIP.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>
|
|
<filename>ppp0</filename>, <filename>ppp1</filename>, …</term>
|
|
<listitem><para>
|
|
<indexterm><primary>ppp1 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>PPP</secondary></indexterm>
|
|
These are the PPP interfaces. Just like SLIP interfaces, a PPP interface is
|
|
associated with a serial line once it is converted to PPP mode.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term> <filename>plip0</filename>,
|
|
<filename>plip1</filename>, …</term> <listitem><para>
|
|
<indexterm><primary>plip1 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>PLIP</secondary></indexterm>
|
|
These are the PLIP interfaces. PLIP transports IP datagrams over
|
|
parallel lines. The interfaces are allocated by the PLIP driver at
|
|
system boot time and are mapped onto parallel ports. In the
|
|
<emphasis>2.0.x</emphasis> kernels there is a direct relationship
|
|
between the device name and the I/O port of the parallel port, but in
|
|
later kernels the device names are allocated sequentially, just as for
|
|
SLIP and PPP devices.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term> <filename>ax0</filename>,
|
|
<filename>ax1</filename>, …</term> <listitem><para>
|
|
<indexterm><primary>AX.25 device</primary></indexterm>
|
|
<indexterm><primary>interfaces</primary><secondary>AX.25</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
|
|
These are the AX.25 interfaces. AX.25 is the primary protocol used by
|
|
amateur radio operators. AX.25 interfaces are allocated and mapped in
|
|
a similar fashion to SLIP devices.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
There are many other types of interfaces available for other network
|
|
drivers. We've listed only the most common ones.
|
|
</para>
|
|
|
|
<para>
|
|
During the next few sections, we will discuss the details of using
|
|
the drivers described previously. The Networking HOWTO provides details on
|
|
how to configure most of the others, and the AX25 HOWTO explains how to
|
|
configure the Amateur Radio network devices.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-hardware.drivers.ethernet"><title>Ethernet Installation</title>
|
|
<indexterm id="idx-configuringEthernet-1" class="startofrange"><primary>configuring</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>Ethernet</primary><secondary>Becker drivers</secondary></indexterm>
|
|
<indexterm id="ch03.ethernet.install" class="startofrange"><primary>Ethernet</primary><secondary>installation</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>Becker, Donald</primary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>Ekwall, Bjørn</primary></indexterm>
|
|
<indexterm><primary>Davies, David C.</primary></indexterm>
|
|
<indexterm><primary>Ethernet</primary><secondary>through parallel port</secondary></indexterm>
|
|
<indexterm><primary>parallel port</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>D-Link pocket adaptor</primary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>D-Link</secondary></indexterm>
|
|
|
|
<para>
|
|
The current Linux network code supports a large variety of Ethernet
|
|
cards. Most drivers were written by Donald Becker, who authored a
|
|
family of drivers for cards based on the National Semiconductor 8390
|
|
chip; these have become known as the Becker Series Drivers. Many other
|
|
developers have contributed drivers, and today there are few common
|
|
Ethernet cards that aren't supported by Linux. The list of supported
|
|
Ethernet cards is growing all the time, so if your card isn't
|
|
supported yet, chances are it will be soon.
|
|
</para>
|
|
|
|
<para>
|
|
Sometime earlier in Linux's history we would have attempted to list
|
|
all supported Ethernet cards, but that would now take too much time
|
|
and space. Fortunately, Paul Gortmaker maintains the Ethernet HOWTO,
|
|
which lists each of the supported cards and provides useful
|
|
information about getting each of them running under Linux.<footnote
|
|
id="X-087-2-FNHW04"><para> Paul can be reached at <systemitem
|
|
role="emailaddr">gpg109@rsphy1.anu.edu.au</systemitem>.
|
|
</para>
|
|
</footnote> It is posted monthly to the <systemitem
|
|
role="newsgroup">comp.os.linux.answers</systemitem> newsgroup, and is
|
|
also available on any of the Linux Documentation Project mirror sites.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
Even if you are confident you know how to install a particular type of
|
|
Ethernet card in your machine, it is often worthwhile taking a look at
|
|
what the Ethernet HOWTO has to say about it. You will find information
|
|
that extends beyond simple configuration issues. For example, it could
|
|
save you a lot of headaches to know the
|
|
behavior of some DMA-based Ethernet cards that use the same DMA
|
|
channel as the Adaptec 1542 SCSI controller by default. Unless you move
|
|
one of them to a different DMA channel, you will wind up with the
|
|
Ethernet card writing packet data to arbitrary locations on your hard
|
|
disk.
|
|
</para>
|
|
|
|
<para>
|
|
To use any of the supported Ethernet cards with Linux, you may use a
|
|
precompiled kernel from one of the major Linux distributions. These generally
|
|
have modules available for all of the supported drivers, and the installation
|
|
process usually allows you to select which drivers you want loaded. In the
|
|
long term, however, it's better to build your own kernel and compile only
|
|
those drivers you actually need; this saves disk space and memory.
|
|
</para>
|
|
|
|
<sect2><title>Ethernet Autoprobing</title>
|
|
<indexterm id="idx-Ethernetautoprobing-1" class="startofrange"><primary>Ethernet</primary><secondary>autoprobing</secondary></indexterm>
|
|
<indexterm><primary>autoprobing</primary><secondary>Ethernet</secondary></indexterm>
|
|
|
|
<para>
|
|
Many of the Linux Ethernet drivers are smart enough to know how to
|
|
search for the location of your Ethernet card. This saves you having
|
|
to tell the kernel where it is manually. The Ethernet HOWTO lists
|
|
whether a particular driver uses autoprobing and in which order it
|
|
searches the I/O address for the card.
|
|
</para>
|
|
|
|
<para>
|
|
There are three limitations to the autoprobing code. First, it may not
|
|
recognize all cards properly. This is especially true for some of the cheaper
|
|
clones of common cards. Second, the kernel won't
|
|
autoprobe for more than one card unless specifically instructed. This was
|
|
a conscious design decision, as it is assumed you will want to have control
|
|
over which card is assigned to which interface. The best way to do this
|
|
reliably is to manually configure the Ethernet cards in your machine. Third,
|
|
the driver may not probe at the address that your card is configured for.
|
|
Generally speaking, the drivers will autoprobe at the addresses that the
|
|
particular device is capable of being configured for, but sometimes certain
|
|
addresses are ignored to avoid hardware conflicts with other types of cards
|
|
that commonly use that same address.
|
|
</para>
|
|
|
|
<para>
|
|
PCI network cards should be reliably detected. But if you are using more
|
|
than one card, or if the autoprobe should fail to detect your card, you
|
|
have a way to explicitly tell the kernel about the card's base address and
|
|
name.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>configuring</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>manual configuration</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>autoprobing</primary><secondary>failure</secondary></indexterm>
|
|
<indexterm><primary>lilo command</primary></indexterm>
|
|
At boot time you can supply arguments and information to the kernel that any
|
|
of the kernel components may read. This mechanism allows you
|
|
to pass information to the kernel that Ethernet drivers can use to locate your
|
|
Ethernet hardware without making the driver probe.
|
|
</para>
|
|
|
|
<para>
|
|
If you use lilo to boot your system, you can pass parameters
|
|
to the kernel by specifying them through the
|
|
<systemitem role="keyword">append</systemitem> option in the
|
|
<filename>lilo.conf</filename> file. To inform the kernel about an
|
|
Ethernet device, you can pass the following parameters:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
ether=<replaceable>irq</replaceable>,<replaceable>base_addr</replaceable>,[<replaceable>param1</replaceable>,][<replaceable>param2</replaceable>,]<replaceable>name</replaceable>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
The first four parameters are numeric, while the last is the device
|
|
name. The <replaceable>irq</replaceable>,
|
|
<replaceable>base_addr</replaceable>, and
|
|
<replaceable>name</replaceable> parameters are required, but the two
|
|
<replaceable>param</replaceable> parameters are optional. Any of the
|
|
numeric values may be set to zero, which causes the kernel to
|
|
determine the value by probing.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>auto-IRQ</primary></indexterm>
|
|
<indexterm><primary>IRQ (Interrupt Request)</primary></indexterm>
|
|
The first parameter sets the IRQ assigned to the device. By default, the
|
|
kernel will try to autodetect the device's IRQ channel. The 3c503 driver,
|
|
for example, has a special feature that selects a free IRQ from the list
|
|
5, 9, 3, 4 and configures the card to use this line.
|
|
The <replaceable>base_addr</replaceable> parameter gives the I/O base address
|
|
of the card; a value of zero tells the kernel to probe the addresses listed
|
|
above.
|
|
</para>
|
|
|
|
<para>
|
|
Different drivers use the next two parameters differently. For shared-memory cards, such as the WD80x3, they specify starting and ending
|
|
addresses of the shared memory area. Other cards commonly use
|
|
<replaceable>param1</replaceable> to set the level at which debugging
|
|
information is displayed. Values of 1 through 7 denote increasing levels of
|
|
verbosity, while 8 turns them off altogether; 0 denotes the default.
|
|
The 3c503 driver uses <replaceable>param2</replaceable> to choose between the
|
|
internal transceiver (default) or an external transceiver (a value of 1).
|
|
The former uses the card's BNC connector; the latter uses its AUI port.
|
|
The <replaceable>param</replaceable> arguments need not be included at all
|
|
if you don't have anything special to configure.
|
|
</para>
|
|
|
|
<para>The first non-numeric argument is interpreted by the kernel as the
|
|
device name. You must specify a device name for each Ethernet card you
|
|
describe.
|
|
</para>
|
|
|
|
<para>
|
|
If you have two Ethernet cards, you can have Linux autodetect one card
|
|
and pass the second card's parameters with <command>lilo</command>,
|
|
but you'll probably want to manually configure both cards. If you
|
|
decide to have the kernel probe for one and manually configure the
|
|
second, you must make sure the kernel doesn't accidentally find the
|
|
second card first, or else the other one won't be registered at
|
|
all. You do this by passing <command>lilo</command> a <systemitem
|
|
role="keyword">reserve</systemitem> option, which explicitly tells the
|
|
kernel to avoid probing the I/O space taken up by the second card. For
|
|
instance, to make Linux install a second Ethernet card at
|
|
<literal>0x300</literal> as <filename>eth1</filename>, you would pass
|
|
the following parameters to the kernel:
|
|
</para>
|
|
<?troff .wcon_off>
|
|
<para>
|
|
<screen>
|
|
reserve=0x300,32 ether=0,0x300,eth1
|
|
</screen>
|
|
</para>
|
|
<?troff .Nd 10>
|
|
<para>
|
|
The <emphasis>reserve</emphasis> option makes sure no driver
|
|
accesses the second card's I/O space when probing for some device. You may
|
|
also use the kernel parameters to override autoprobing for
|
|
<filename>eth0</filename> :
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
reserve=0x340,32 ether=0,0x340,eth0
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
You can turn off autoprobing altogether. You might do this, for example, to
|
|
stop a kernel probing for an Ethernet card you might have temporarily removed.
|
|
Disabling autoprobing is as simple as specifying a
|
|
<replaceable>base_addr</replaceable> argument of –1:
|
|
</para>
|
|
|
|
<para>
|
|
<screen>
|
|
ether=0,-1,eth0
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
To supply these parameters to the kernel at boot time, you enter the
|
|
parameters at the lilo "boot:" prompt. To have <command>lilo</command>
|
|
give you the "<prompt>boot:</prompt>" at the prompt, you must press
|
|
any one of the Control, Alt or Shift keys while
|
|
<command>lilo</command> is booting. If you press the Tab key at the
|
|
prompt, you will be presented with a list of kernels that you may
|
|
boot. To boot a kernel with parameters supplied, enter the name of the
|
|
kernel you wish to boot, followed by a space, then followed by the
|
|
parameters you wish to supply. When you press the Enter key,
|
|
<command>lilo</command> will load that kernel and boot it with the
|
|
parameters you've supplied.
|
|
</para>
|
|
|
|
<para>
|
|
To make this change occur automatically on each reboot, enter the parameters
|
|
into the <filename>/etc/lilo.conf</filename> using the
|
|
<literal>append=</literal> keyword. An example might look like this:
|
|
|
|
<screen>
|
|
boot=/dev/hda
|
|
root=/dev/hda2
|
|
install=/boot/boot.b
|
|
map=/boot/map
|
|
vga=normal
|
|
delay=20
|
|
append="ether=10,300,eth0"
|
|
|
|
image=/boot/vmlinuz-2.2.14
|
|
label=2.2.14
|
|
read-only
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
After you've edited <filename>lilo.conf</filename>, you must rerun
|
|
the <command>lilo</command> command to activate the change.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm class="endofrange" startref="idx-Ethernetautoprobing-1">
|
|
<indexterm class="endofrange" startref="idx-configuringEthernet-1">
|
|
<indexterm class="endofrange" startref="ch03.ethernet.install">
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-hardware.drivers.plip"><title>The PLIP Driver</title>
|
|
<indexterm><primary>configuring</primary><secondary>PLIP</secondary></indexterm>
|
|
<indexterm><primary>parallel port</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>PLIP</secondary></indexterm>
|
|
<indexterm><primary>PLIP (Parallel Line IP) protocol</primary><secondary>driver</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>PLIP</secondary></indexterm>
|
|
<para>
|
|
<emphasis>Parallel Line IP</emphasis> (PLIP) is a cheap way to
|
|
network when you want to connect only two machines. It uses a parallel port
|
|
and a special cable, achieving speeds of 10 kilobytes per second to 20 kilobytes per second.
|
|
</para>
|
|
|
|
<para>
|
|
PLIP was originally developed by Crynwr, Inc. Its design at the time was
|
|
rather ingenious (or, if you prefer, a
|
|
hack), because the original parallel ports on
|
|
IBM PCs were designed to spend their time being unidirectional printer ports;
|
|
the eight data lines could be used only to send data from the PC to the
|
|
peripheral device, but not the other way around.<footnote id="X-087-2-FNHW05">
|
|
<para>
|
|
Fight to clear the hacking name! Always use “cracker” when
|
|
you are referring to people who are consciously trying to defeat the
|
|
security of a system, and “hacker” when you are referring
|
|
to people who have found a clever way of solving a problem. Hackers
|
|
can be crackers, but the two should never be confused. Consult the New
|
|
Hackers Dictionary (popularly found as the Jargon file) for a more
|
|
complete understanding of the terms. </para></footnote> The Cyrnwr
|
|
PLIP design worked around this limitation by using the port's five
|
|
status lines for input, which limited it to transferring all data as
|
|
nibbles (half bytes) only, but allowed for bidirectional
|
|
transfer. This mode of operation was called PLIP “mode 0.”
|
|
Today, the parallel ports supplied on PC hardware cater to full
|
|
bidirectional 8-bit data transfer, and PLIP has been extended to
|
|
accomodate this with the addition of PLIP “mode 1.”
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NCSA telnet</primary></indexterm>
|
|
<?troff .ffn>
|
|
Linux kernels up to and including Version 2.0 support PLIP mode 0 only,
|
|
and an enhanced parallel port driver exists as a
|
|
patch against the 2.0 kernel and as a
|
|
standard part of the 2.2 kernel code to provide PLIP mode 1 operation, too.
|
|
<footnote id="X-087-2-FNHW06">
|
|
<para>
|
|
The enhanced parallel port adaptor patch for 2.0 kernel is available from
|
|
<systemitem role="url">http://www.cyberelk.demon.co.uk/parport.html</systemitem>.
|
|
</para>
|
|
</footnote>
|
|
Unlike earlier versions of the PLIP code, the driver now attempts to be
|
|
compatible with the PLIP implementations from Crynwr, as well as the PLIP
|
|
driver in NCSA <command>telnet</command>.<footnote id="X-087-2-FNHW07">
|
|
<para>
|
|
NCSA <command>telnet</command> is a popular program for DOS that runs TCP/IP
|
|
over Ethernet or PLIP, and supports <command>telnet</command> and FTP.
|
|
</para>
|
|
</footnote>
|
|
To connect two machines using PLIP, you need a special cable sold at some
|
|
shops as a Null Printer or Turbo Laplink cable.
|
|
You can, however, make one yourself fairly easily;
|
|
<xref linkend="X-087-2-appendix.cables"> shows you how.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Yutaka, Niibe</primary></indexterm>
|
|
The PLIP driver for Linux is the work of almost countless persons. It is
|
|
currently maintained by Niibe Yutaka.<footnote id="X-087-2-FNHW08"><para>
|
|
Niibe can be reached at
|
|
<systemitem role="emailaddr">gniibe@mri.co.jp</systemitem>.
|
|
</para>
|
|
</footnote>
|
|
If compiled into the kernel, it sets up a network interface for each of the
|
|
possible printer ports, with <filename>plip0</filename> corresponding to
|
|
parallel port <filename>lp0</filename>, <filename>plip1</filename>
|
|
<?troff .endwcd>
|
|
corresponding to <filename>lp1</filename>, etc. The mapping of interfaces to
|
|
ports differs in the 2.0 kernels and the 2.2
|
|
<?troff .hw hardwired>
|
|
kernels. In the 2.0 kernels, the mapping was hardwired in the
|
|
<filename>drivers/net/Spacd.c</filename> file in the kernel
|
|
<?troff .hw hard-wired>
|
|
<?troff .ne 10>
|
|
source. The default mappings in this file are:
|
|
</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols=3>
|
|
<thead>
|
|
<row>
|
|
<entry>Interface</entry>
|
|
<entry>I/O Port</entry>
|
|
<entry>IRQ</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><filename>plip0</filename></entry>
|
|
<entry><literal>0x3BC</literal></entry>
|
|
<entry>7</entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>plip1</filename></entry>
|
|
<entry><literal>0x378</literal></entry>
|
|
<entry>7</entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>plip2</filename></entry>
|
|
<entry><literal>0x278</literal></entry>
|
|
<entry>5</entry>
|
|
</row>
|
|
</tbody></tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
<indexterm><primary>manual configuration</primary><secondary>PLIP</secondary></indexterm>
|
|
If you configured your printer port in a different way, you
|
|
must change these values in <filename>drivers/net/Space.c</filename> in
|
|
the Linux kernel source and build a new kernel.
|
|
</para>
|
|
|
|
<para>
|
|
In the 2.2 kernels, the PLIP driver uses the “parport” parallel port
|
|
sharing driver developed by Philip Blundell.<footnote id="X-087-2-FNHW09"><para>
|
|
You can reach Philip at <emphasis><systemitem role="emailadd">Philip.Blundell@pobox.com</systemitem></emphasis>.
|
|
</para>
|
|
</footnote> The new driver allocates the PLIP network device names serially,
|
|
just as for the Ethernet or PPP drivers, so the first PLIP device created is
|
|
<filename>plip0</filename>, the second is <filename>plip1</filename>, and so on.
|
|
The physical parallel port hardware is also allocated serially. By default, the
|
|
parallel port driver will attempt to detect your parallel port hardware with an
|
|
autoprobe routine, recording the physical device information in the order found. It is better practice to explicitly tell the kernel the physical I/O
|
|
parameters. You can do this by supplying arguments to the
|
|
<filename>parport_pc.o</filename> module as you load it, or if you have
|
|
compiled the driver into your kernel, using lilo to supply
|
|
arguments to the kernel at boot time. The IRQ setting of any device may be
|
|
changed later by writing the new IRQ value to the related
|
|
<filename>/proc/parport/*/irq</filename> file.
|
|
</para>
|
|
|
|
<para>
|
|
Configuring the physical I/O parameters in a 2.2 kernel when loading the
|
|
module is straightforward. For instance, to tell the driver that you have
|
|
two PC-style parallel ports at I/O addresses <literal>0x278</literal> and
|
|
<literal>0c378</literal> and IRQs 5 and 7, respectively, you would load the
|
|
module with the following arguments:
|
|
|
|
<screen>
|
|
modprobe parport_ pc io=0x278,0x378 irq=5,7
|
|
</screen>
|
|
|
|
The corresponding arguments to pass to the kernel for a compiled-in driver are:
|
|
|
|
<screen>
|
|
parport=0x278,5 parport=0x378,7
|
|
</screen>
|
|
|
|
You would use the lilo <systemitem role="keyword">append</systemitem>
|
|
keyword to have these arguments
|
|
passed to the kernel automatically at boot time.
|
|
</para>
|
|
|
|
<para>
|
|
When the PLIP driver is initialized, either at boot time if it is
|
|
built-in, or when the <filename>plip.o</filename> module is loaded,
|
|
each of the parallel ports will have a <filename>plip</filename>
|
|
network device associated with it. <filename>plip0</filename> will be
|
|
assigned to the first parallel port device, <filename>plip1</filename>
|
|
the second, and so on. You can manually override this automatic
|
|
assignment using another set of kernel arguments. For instance, to
|
|
assign <literal>parport0</literal> to network device
|
|
<?troff .ne 10>
|
|
<literal>plip0</literal>, and <literal>parport1</literal> to network
|
|
device <literal>plip1</literal>, you would use kernel arguments of:
|
|
|
|
<screen>
|
|
plip=parport1 plip=parport0
|
|
</screen>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
This mapping does not mean, however, that you cannot use these parallel ports
|
|
for printing or other purposes. The physical parallel port devices are used
|
|
by the PLIP driver only when the corresponding interface is configured
|
|
<systemitem role="keyword">up</systemitem>.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-hardware.drivers.slip"><title>The PPP and SLIP Drivers</title>
|
|
<indexterm><primary>drivers</primary><secondary>SLIP</secondary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>PPP</secondary></indexterm>
|
|
<indexterm><primary>SLIP (Serial Line IP) protocol</primary><secondary>driver</secondary></indexterm>
|
|
<indexterm><primary>PLIP (Parallel Line IP) protocol</primary><secondary>driver</secondary></indexterm>
|
|
<para>
|
|
Point-to-Point Protocol (PPP) and Serial Line IP (SLIP) are widely used
|
|
protocols for carrying IP packets over a serial link. A number of institutions
|
|
offer dialup PPP and SLIP access to machines that are on the Internet, thus
|
|
providing IP connectivity to private persons (something that's otherwise
|
|
hardly affordable).
|
|
</para>
|
|
|
|
<para>
|
|
No hardware modifications are necessary to run PPP or SLIP; you can use
|
|
any serial port. Since serial port configuration is not specific to
|
|
TCP/IP networking, we have devoted a separate chapter to this. Please
|
|
refer to <xref linkend="X-087-2-serial">, for more information. We cover
|
|
PPP in detail in <xref linkend="X-087-2-ppp">, and SLIP in
|
|
<xref linkend="X-087-2-slip">.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-hardware.other"><title>Other Network Types</title>
|
|
<para>
|
|
<indexterm><primary>drivers</primary><secondary>Token Ring</secondary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>ArcNet</secondary></indexterm>
|
|
<indexterm><primary>drivers</primary><secondary>FDDI</secondary></indexterm>
|
|
<indexterm><primary>Token Ring</primary><secondary>driver</secondary></indexterm>
|
|
<indexterm><primary>ArcNet protocol driver</primary></indexterm>
|
|
<indexterm><primary>FDDI (Fiber Distributed Data Interface)</primary></indexterm>
|
|
<indexterm><primary>Fiber Distributed Data Interface (FDDI)</primary></indexterm>
|
|
Most other network types are configured similarly to Ethernet. The arguments
|
|
passed to the loadable modules will be different
|
|
and some drivers may not support more than one card, but just about everything
|
|
else is the same. Documentation for these cards is generally available in the
|
|
<filename>/usr/src/linux /Documentation/networking/</filename> directory of
|
|
the Linux kernel source.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm class="endofrange" startref="idx-configuringnetworkhardware-1">
|
|
<indexterm class="endofrange" startref="idx-hardwarenetworking-1">
|
|
<indexterm class="endofrange" startref="ch03.net.hw.config">
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|