Document History
The original NET-FAQ was written by Matt Welsh and Terry Dawson to
answer frequently asked questions about networking for Linux at a time
before the Linux Documentation Project had formally started. It
covered the very early development versions of the Linux Networking
Kernel. The NET-2-HOWTO superceded the NET-FAQ and was one of the
original LDP HOWTO documents, it covered what was called version 2 and
later version 3 of the Linux kernel Networking software. This document
in turn supercedes it and relates only to version 4 of the Linux
Networking Kernel or more specifically kernel releases 2.x and 2.2.x.
Previous versions of this document became quite large because of
the enormous amount of material that fell within its scope. To help
reduce this problem a number of HOWTO's dealing with specific
networking topics have been produced. This document will provide
pointers to them where relevant and cover those areas not yet covered
by other documents.
Feedback
We are always interested in feedback. Please contact us at:
.
Again, if you find anything erroneous or anything you would like to see
added, please contact us.
How to use this HOWTO.
This document is organized top-down. The first sections include
informative material and can be skipped if you are not interested;
what follows is a generic discussion of networking issues, and you
must ensure you understand this before proceeding to more specific
parts. The rest, ``technology specific'' information is grouped in
three main sections: Ethernet and IP-related information, technologies
pertaining to widespread PC hardware and seldom-used technologies.
The suggested path through the document is thus the following:
Read the generic sectionsThese sections apply to every, or
nearly every, technology described later and so are very
important for you to understand. On the other hand, I expect
many of the readers to be already confident with this material.
Consider your networkYou should know how your network is,
or will be, designed and exactly what hardware and technology
types you will be implementing.
Read the ``Ethernet and IP'' section if you are directly connected
a LAN or the InternetThis section describes basic
Ethernet configuration and the various features that Linux offers
for IP networks, like firewalling, advanced routing and so on.
Read the next section if you are interested in low-cost local
networks or dial-up connectionsThe section describes PLIP,
PPP, SLIP and ISDN, the widespread technologies used on personal
workstations.
Read the technology specific sections related to your
requirementsIf your needs differ from IP and/or common
hardware, the final section covers details specific to
non-IP protocols and peculiar communication hardware.
Do the configuration workYou should actually try to
configure your network and take careful note of any problems
you have.
Look for further help if neededIf you experience problems
that this document does not help you to resolve then read the
section related to where to get help or where to report bugs.
Have fun! Networking is fun, enjoy it.
Conventions used in this document
No special convention is used here, but you must be warned about
the way commands are shown. Following the classic Unix documentation,
any command you should type to your shell is prefixed by a
prompt. This howto shows "user%" as the prompt for commands
that do not require superuser privileges, and "root#" as the
prompt for commands that need to run as root. I chose to use
"root#" instead of a plain "#" to prevent confusion
with snapshots from shell scripts, where the hash mark is used to
define comment lines.
When ``Kernel Compile Options'' are shown, they are represented in
the format used by
General Information about Linux Networking.
Linux Networking Resources.
There are a number of places where you can find good information about
Linux networking.
There are a wealth of Consultants available. A searchable listing can be found at
Alan Cox, the current maintainer of the Linux kernel networking code maintains
a world wide web page that contains highlights of current and new developments
in linux Networking at:
.
There is a newsgroup in the Linux news hierarchy dedicated to networking
and related matters, it is:
There is a mailing list to which you can subscribe where you may ask questions
relating to Linux networking. To subscribe you should send a mail message:
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:
subscribe linux-net
Please remember when reporting any problem to include as much relevant detail
about the problem as you can. Specifically you should specify the versions of
software that you are using, especially the kernel version, the version of
tools such as pppd/ or dip and the exact nature of the problem
you are experiencing. This means taking note of the exact syntax of any error
messages you receive and of any commands that you are issuing.
Where to get some non-linux-specific network information.
If you are after some basic tutorial information on tcp/ip networking
generally, then I recommend you take a look at the following documents:
tcp/ip introduction this document comes as both a and a .
tcp/ip administration this document comes as both a
and a .
If you are after some more detailed information on tcp/ip networking then
I highly recommend:
Internetworking with TCP/IP, Volume 1: principles,
protocols and architecture, by Douglas E. Comer, ISBN
0-13-227836-7, Prentice Hall publications, Third Edition,
1995.
If you are wanting to learn about how to write network applications in
a Unix compatible environment then I also highly recommend:
Unix Network Programming, by W. Richard Stevens,
ISBN 0-13-949876-1, Prentice Hall publications, 1990.
A second edition of this book is appearing on the bookshelves; the new
book is made up of three volumes: check to probe further.
You might also try the newsgroup.
An important source of specific technical information relating to
the Internet and the tcp/ip suite of protocols are RFC's. RFC is an
acronym for `Request For Comment' and is the standard means of
submitting and documenting Internet protocol standards. There are many
RFC repositories. Many of these sites are ftp sites and other provide
World Wide Web access with an associated search engine that allows you
to search the RFC database for particular keywords.
One possible source for RFC's is at .
Generic Network Configuration Information.
The following subsections you will pretty much need to know and understand
before you actually try to configure your network. They are fundamental
principles that apply regardless of the exact nature of the network you
wish to deploy.
What do I need to start ?
Before you start building or configuring your network you will need some
things. The most important of these are:
Current Kernel source(Optional).
Please note:
The majority of current distributions come with networking enabled, therefore
it may not be required to recompile the kernel. If you are running well known
hardware you should be just fine. For example: 3COM NIC, NE2000 NIC, or a
Intel NIC. However if you find yourself in the position that you do need to
update the kernel, the following information is provided.
Because the kernel you are running now might not yet have support for the
network types or cards that you wish to use you will probably need the
kernel source so that you can recompile the kernel with the appropriate
options.
For users of the major distributions such as Redhat, Caldera, Debian, or
Suse this no longer holds true. As long as you stay within the mainstream of
hardware there should be no need to recompile your kernel unless there is a
very specific feature that you need.
You can always obtain the latest kernel source from .
This is not the official site but they have LOTS of bandwidth and capacity.
The official site is kernel.org but please use the above if
you can. Please remember that ftp.kernel.org is seriously overloaded. Use a
mirror.
Normally the kernel source will be untarred into the
/usr/src/linux directory. For information on how to apply
patches and build the kernel you should read the . For information on how
to configure kernel modules you should read the ``Modules
mini-HOWTO''. Also, the README file found in the kernel
sources and the Documentation directory are very informative
for the brave reader.
Unless specifically stated otherwise, I recommend you stick with
the standard kernel release (the one with the even number as the
second digit in the version number). Development release kernels (the
ones with the odd second digit) may have structural or other changes
that may cause problems working with the other software on your
system. If you are uncertain that you could resolve those sorts of
problems in addition to the potential for there being other software
errors, then don't use them.
IP Addresses, an Explanation.
Internet Protocol Addresses are composed of four bytes. The convention is
to write addresses in what is called `dotted decimal notation'. In this form
each byte is converted to a decimal number (0-255) dropping any leading
zero's unless the number is zero and written with each byte separated by a
`.' character. By convention each interface of a host or router has an IP
address. It is legal for the same IP address to be used on each interface of a
single machine in some circumstances but usually each interface will have its
own address.
Internet Protocol Networks are contiguous sequences of IP addresses. All
addresses within a network have a number of digits within the address in
common. The portion of the address that is common amongst all addresses
within the network is called the `network portion' of the address. The
remaining digits are called the `host portion'. The number of bits that
are shared by all addresses within a network is called the netmask and it
is role of the netmask to determine which addresses belong to the network it
is applied to and which don't. For example, consider the following:
----------------- ---------------
Host Address 192.168.110.23
Network Mask 255.255.255.0
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address 192.168.110.0
Broadcast Address 192.168.110.255
----------------- ---------------
Any address that is 'bitwise anded' with its netmask will reveal the address
of the network it belongs to. The network address is therefore always the
lowest numbered address within the range of addresses on the network and
always has the host portion of the address coded all zeroes.
The broadcast address is a special address that every host on the network
listens to in addition to its own unique address. This address is the one
that datagrams are sent to if every host on the network is meant to receive
it. Certain types of data like routing information and warning messages
are transmitted to the broadcast address so that every host on the network
can receive it simultaneously. There are two commonly used standards for
what the broadcast address should be. The most widely accepted one is to
use the highest possible address on the network as the broadcast address.
In the example above this would be 192.168.110.255. For some reason
other sites have adopted the convention of using the network address as the
broadcast address. In practice it doesn't matter very much which you use
but you must make sure that every host on the network is configured with the
same broadcast address.
For administrative reasons some time early in the development of the IP
protocol some arbitrary groups of addresses were formed into networks and
these networks were grouped into what are called classes. These classes
provide a number of standard size networks that could be allocated. The ranges
allocated are:
--------------------------------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
--------------------------------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
--------------------------------------------------------------------------------
What addresses you should use depends on exactly what it is that you
are doing. You may have to use a combination of the following activities
to get all the addresses you need:
Installing a linux machine on an existing IP networkIf
you wish to install a linux machine onto an existing IP network then
you should contact whoever administers the network and ask them for
the following information:
- Host IP Address
- IP network address
- IP broadcast address
- IP netmask
- Router address
- Domain Name Server Address
You should then configure your linux network device with those
details. You can not make them up and expect your configuration to
work.
Building a brand new network that will never connect to the
Internet If you are building a private network and you never
intend that network to be connected to the Internet then you can
choose whatever addresses you like. However, for safety and
consistency reasons there have been some IP network addresses that
have been reserved specifically for this purpose. These are
specified in RFC1597 and are as follows:
-----------------------------------------------------------
| RESERVED PRIVATE NETWORK ALLOCATIONS |
-----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
-----------------------------------------------------------
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
You should first decide how large you want your network to be and then
choose as many of the addresses as you require.
Where should I put the configuration commands ?
There are a few different approaches to Linux system boot
procedures. After the kernel boots, it always executes a program
called `/etc/inittab and commences the boot
process. There are a few different flavours of
Despite the fact that the
Usually the /etc/inittab file contains an entry looking something
like:
si::sysinit:/etc/init.d/boot
This line specifies the name of the shell script file that actually manages
the boot sequence. This file is somewhat equivalent to the
There are usually other scripts that are called by the boot script and often
the network is configured within one of many of these.
The following table may be used as a guide for your system:
---------------------------------------------------------------------------
Distrib. | Interface Config/Routing | Server Initialization
---------------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
---------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
---------------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
---------------------------------------------------------------------------
Note that Debian and Red Hat use a whole directory to host scripts
that fire up system services (and usually information does not lie
within these files, for example Red Hat systems store all of system
configuration in files under /etc/sysconfig, whence it is
retrieved by boot scripts). If you want to grasp the details of the
boot process, my suggestion is to check /etc/inittab and the
documentation that accompanies init. Linux Journal is also
going to publish an article about system initialization, and this
document will point to it as soon as it is available on the web.
Most modern distributions include a program that will allow you to
configure many of the common sorts of network interfaces. If you have
one of these then you should see if it will do what you want before
attempting a manual configuration.
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
Creating your network interfaces.
In many Unix operating systems the network devices have appearances in the
/dev directory. This is not so in Linux. In Linux the network devices
are created dynamically in software and do not require device files to
be present.
In the majority of cases the network device is automatically created by the
device driver while it is initializing and has located your hardware. For
example, the ethernet device driver creates
In some cases though, notably
Configuring a network interface. Kernels 2.0 and 2.2
When you have all of the programs you need and your address and network
information you can configure your network interfaces. When we talk about
configuring a network interface we are talking about the process of assigning
appropriate addresses to a network device and to setting appropriate values
for other configurable parameters of a network device. The program most
commonly used to do this is the
Typically you would use a command similar to the following:
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
In this case I'm configuring an ethernet interface `ifconfig eth0 down''.
The kernel assumes certain defaults when configuring interfaces. For example,
you may specify the network address and broadcast address for an interface,
but if you don't, as in my example above, then the kernel will make reasonable
guesses as to what they should be based on the netmask you supply and if you
don't supply a netmask then on the network class of the IP address configured.
In my example the kernel would assume that it is a class-C network
being configured on the interface and configure a network address of
`There are many other options to the
/this parameter allows you to set the network
mask of the network this device belongs to.
/this parameter only works on certain types of
hardware and allows you to set the IRQ of the hardware
of this device.
/this parameter allows you to set
the hardware address of certain types of network
devices. This is not often useful for ethernet, but is
useful for other network types such as AX.25.
With the release of Kernel 2.2 there are a number of options available
that are not listed above. Some of the most interesting are tunneling and
IPV6 options. The ifconfig paramaters for kernel 2.2 are listed below.
interface
The name of the interface. This is usually a
driver name followed by a unit number, for example
eth0 for the first Ethernet interface.
up
This flag causes the interface to be activated. It
is implicitly specified if an address is assigned
to the interface.
down
This flag causes the driver for this interface to
be shut down.
[-]arp Enable or disable the use of the ARP protocol on
this interface.
[-]promisc
Enable or disable the promiscuous mode of the
interface. If selected, all packets on the network
will be received by the interface.
[-]allmulti
Enable or disable all-multicast mode. If selected,
all multicast packets on the network will be
received by the interface.
metric N
This parameter sets the interface metric.
mtu N
This parameter sets the Maximum Transfer Unit (MTU)
of an interface.
dstaddr addr
Set the remote IP address for a point-to-point link
(such as PPP). This keyword is now obsolete; use
the pointopoint keyword instead.
netmask addr
Set the IP network mask for this interface. This
value defaults to the usual class A, B or C network
mask (as derived from the interface IP address),
but it can be set to any value.
add addr prefixlen
Add an IPv6 address to an interface.
del addr prefixlen
Remove an IPv6 address from an interface.
tunnel aa.bb.cc.dd
Create a new SIT (IPv6-in-IPv4) device, tunnelling
to the given destination.
irq addr
Set the interrupt line used by this device. Not
all devices can dynamically change their IRQ set-
ting.
io_addr addr
Set the start address in I/O space for this device.
mem_start addr
Set the start address for shared memory used by
this device. Only a few devices need this.
media type
Set the physical port or medium type to be used by
the device. Not all devices can change this set-
ting, and those that can vary in what values they
support. Typical values for type are 10base2 (thin
Ethernet), 10baseT (twisted-pair 10Mbps Ethernet),
AUI (external transceiver) and so on. The special
medium type of auto can be used to tell the driver
to auto-sense the media. Again, not all drivers
can do this.
[-]broadcast [addr]
If the address argument is given, set the protocol
broadcast address for this interface. Otherwise,
set (or clear) the IFF_BROADCAST flag for the
interface.
[-]pointopoint [addr]
This keyword enables the point-to-point mode of an
interface, meaning that it is a direct link between
two machines with nobody else listening on it.
If the address argument is also given, set the pro-
tocol address of the other side of the link, just
like the obsolete dstaddr keyword does. Otherwise,
set or clear the IFF_POINTOPOINT flag for the
interface.
hw class address
Set the hardware address of this interface, if the
device driver supports this operation. The keyword
must be followed by the name of the hardware class
and the printable ASCII equivalent of the hardware
address. Hardware classes currently supported
include ether (Ethernet), ax25 (AMPR AX.25), ARCnet
and netrom (AMPR NET/ROM).
multicast
Set the multicast flag on the interface. This
should not normally be needed as the drivers set
the flag correctly themselves.
address
The IP address to be assigned to this interface.
txqueuelen length
Set the length of the transmit queue of the device.
It is useful to set this to small values for slower
devices with a high latency (modem links, ISDN) to
prevent fast bulk transfers from disturbing inter-
active traffic like telnet too much.
You may use the ifconfig command on any network interface. Some user
programs such as pppd and dip automatically configure the network
devices as they create them, so manual use of ifconfig is unnecessary.
Configuring your Name Resolver.
The `
What's in a name ?
You will probably be familiar with the appearance of Internet host
names, but may not understand how they are constructed, or
deconstructed. Internet domain names are hierarchical in nature, that
is, they have a tree-like structure. A `
For historical reasons most domains belonging to one of the
non-country based top level domains were used by organizations within
the United States, although the United States also has its own country
code `Each of these top level domains has subdomains. The top level
domains based on country name are often next broken down into
subdomains based on the The next level of division usually represents the name of the
organization. Further subdomains vary in nature, often the next level
of subdomain is based on the departmental structure of the
organization but it may be based on any criterion considered
reasonable and meaningful by the network administrators for the
organization.
The very left-most portion of the name is always the unique name
assigned to the host machine and is called the `To use Terry's host as an example, the fully qualified domain name
is `Usually, the names are fairly shorter; for example, my ISP is
called ``
What information you will need.
You will need to know what domain your hosts name will belong to. The name
resolver software provides this name translation service by making
requests to a `
There are three files you need to edit, I'll cover each of these in turn.
/etc/resolv.conf
The /etc/resolv.conf is the main configuration file for
the name resolver code. Its format is quite simple. It is a text file
with one keyword per line. There are three keywords typically used,
they are:
An example /etc/resolv.conf might look something like:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
This example specifies that the default domain name to append to unqualified
names (ie hostnames supplied without a domain) is
/etc/host.conf
The /etc/host.conf file is where you configure some items that
govern the behaviour of the name resolver code. The format of this file
is described in detail in the `
order hosts,bind
multi on
This configuration tells the name resolver to check the /etc/hosts
file before attempting to query a nameserver and to return all valid addresses
for a host found in the /etc/hosts file instead of just the first.
/etc/hosts
The /etc/hosts file is where you put the name and IP
address of local hosts. If you place a host in this file then you do
not need to query the domain name server to get its IP Address. The
disadvantage of doing this is that you must keep this file up to date
yourself if the IP address for that host changes. In a well managed
system the only hostnames that usually appear in this file are an
entry for the loopback interface and the local hosts name.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
You may specify more than one host name per line as demonstrated by
the first entry, which is a standard entry for the loopback interface.
Running a name server
If you want to run a local nameserver, you can do it easily. Please
refer to the and to any
documents included in your version of
Configuring your loopback interface.
The `
Configuring the loopback interface is simple and you should ensure you do
(but note that this task is usually performed by the standard initialization
scripts).
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
We'll talk more about the
Routing.
Routing is a big topic. It is easily possible to write large
volumes of text about it. Most of you will have fairly simple routing
requirements, some of you will not. I will cover some basic
fundamentals of routing only. If you are interested in more detailed
information then I suggest you refer to the references provided at the
start of the document.
Let's start with a definition. What is IP routing ? Here is one
that I'm using:
IP Routing is the process by which a host with
multiple network connections decides where to deliver IP
datagrams it has received.
It might be useful to illustrate this with an example. Imagine a typical
office router, it might have a PPP link off the Internet, a number of
ethernet segments feeding the workstations and another PPP link off to
another office. When the router receives a datagram on any of its network
connections, routing is the mechanism that it uses to determine which interface
it should send the datagram to next. Simple hosts also need to route, all
Internet hosts have two network devices, one is the loopback interface
described above and the other is the one it uses to talk to the rest of
the network, perhaps an ethernet, perhaps a PPP or SLIP serial interface.
Ok, so how does routing work ? Each host keeps a special list of routing
rules, called a routing table. This table contains rows which typically
contain at least three fields, the first is a destination address,
the second is the name of the interface to which the datagram is to be routed
and the third is optionally the IP address of another machine which will
carry the datagram on its next step through the network. In linux you
can see this table by using the following command:
user% cat /proc/net/route
or by using either of the following commands:
user% /sbin/route -n
user% netstat -r
The routing process is fairly simple: an incoming datagram is received,
the destination address (who it is for) is examined and compared with
each entry in the table. The entry that best matches that address is
selected and the datagram is forwarded to the specified interface. If the
gateway field is filled then the datagram is forwarded to that host via
the specified interface, otherwise the destination address is assumed to
be on the network supported by the interface.
To manipulate this table a special command is used. This command takes
command line arguments and converts them into kernel system calls that
request the kernel to add, delete or modify entries in the routing table.
The command is called `
A simple example. Imagine you have an ethernet network. You've been told
it is a class-C network with an address of
The first step is to configure the interface as described earlier. You would
use a command like:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
You now need to add an entry into the routing table to tell the kernel that
datagrams for all hosts with addresses that match should
be sent to the ethernet device. You would use a command similar to:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Note the use of the `
This route will enable you to establish IP connections with all of the hosts
on your ethernet segment. But what about all of the IP hosts that aren't on
your ethernet segment ?
It would be a very difficult job to have to add routes to every possible
destination network, so there is a special trick that is used to simplify this
task. The trick is called the `
root# route add default gw 192.168.1.1 eth0
The `gw' argument tells the route command that the next argument is
the IP address, or name, of a gateway or router machine which all datagrams
matching this entry should be directed to for further routing.
So, your complete configuration would look like:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
If you take a close look at your network `
Let's now look at a slightly more complicated routing configuration. Let's
imagine we are configuring the router we looked at earlier, the one supporting
the PPP link to the Internet and the lan segments feeding the workstations in
the office. Lets imagine the router has three ethernet segments and one PPP
link. Our routing configuration would look something like:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
Each of the workstations would use the simpler form presented
above, only the router needs to specify each of the network routes
separately because for the workstations the
So what does the
The routing configuration described above is best suited to simple network
arrangements where there are only ever single possible paths to destinations.
When you have a more complex network arrangement things get a little more
complicated. Fortunately for most of you this won't be an issue.
The big problem with `manual routing' or `static routing' as described, is
that if a machine or link fails in your network then the only way you can
direct your datagrams another way, if another way exists, is by manually
intervening and executing the appropriate commands. Naturally this is
clumsy, slow, impractical and hazard prone. Various techniques have been
developed to automatically adjust routing tables in the event of network
failures where there are alternate routes, all of these techniques are
loosely grouped by the term `dynamic routing protocols'.
You may have heard of some of the more common dynamic routing protocols. The
most common are probably RIP (Routing Information Protocol) and OSPF (Open
Shortest Path First Protocol). The Routing Information Protocol is very common
on small networks such as small-medium sized corporate networks or building
networks. OSPF is more modern and more capable at handling large network
configurations and better suited to environments where there is a large number
of possible paths through the network. Common implementations of these
protocols are: `
An example of where and how you might use a dynamic routing protocol might
look something like the following:
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
We have three routers A, B and C. Each supports one ethernet segment with
a Class C IP network (netmask 255.255.255.0). Each router also has a PPP link
to each of the other routers. The network forms a triangle.
It should be clear that the routing table at router A could look like:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
This would work just fine until the link between router A and B should fail.
If that link failed then with the routing entry shown above hosts on the
ethernet segment of A could not reach hosts on the ethernet segment on B
because their datagram would be directed to router A's ppp0 link which is
broken. They could still continue to talk to hosts on the ethernet segment
of C and hosts on the C's ethernet segment could still talk to hosts on
B's ethernet segment because the link between B and C is still intact.
But wait, if A can talk to C and C can still talk to B, why shouldn't A
route its datagrams for B via C and let C send them to B ? This is exactly
the sort of problem that dynamic routing protocols like RIP were designed
to solve. If each of the routers A, B and C were running a routing daemon
then their routing tables would be automatically adjusted to reflect the
new state of the network should any one of the links in the network fail.
To configure such a network is simple, at each router you need only do
two things. In this case for Router A:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
The `
This has been a very brief explanation of dynamic routing and where you would
use it. If you want more information then you should refer to the suggested
references listed at the top of the document.
The important points relating to dynamic routing are:
- You only need to run a dynamic routing protocol daemon
when your Linux machine has the possibility of
selecting multiple possible routes to a destination.
An example of this would be if you plan to use
IP Masquerading.
- The dynamic routing daemon will automatically modify
your routing table to adjust to changes in your
network.
- RIP is suited to small to medium sized networks.
Configuring your network servers and services.
Network servers and services are those programs that allow a remote user to
make user of your Linux machine. Server programs listen on network ports.
Network ports are a means of addressing a particular service on any particular
host and are how a server knows the difference between an incoming telnet
connection and an incoming ftp connection. The remote user establishes a
network connection to your machine and the server program, the network daemon
program, listening on that port accepts the connection and executes. There are
two ways that network daemons may operate. Both are commonly employed in
practice. The two ways are:
standalonethe network daemon program listens on the
designated network port and when an incoming
connection is made it manages the network connection
itself to provide the service.
slave to the inetd serverthe inetd server
is a special network daemon program that specializes
in managing incoming network connections. It has a
configuration file which tells it what program needs
to be run when an incoming connection is received. Any
service port may be configured for either of the tcp
or udp protcols. The ports are described in another
file that we will talk about soon.
There are two important files that we need to configure. They are the
/etc/services file which assigns names to port numbers and the
/etc/inetd.conf file which is the configuration file for the
/etc/services
The /etc/services file is a simple database that associates a
human friendly name to a machine friendly service port. Its format is
quite simple. The file is a text file with each line representing and
entry in the database. Each entry is comprised of three fields separated by
any number of whitespace (tab or space) characters. The fields
are:
name port/protocol aliases # comment
namea single word name that represents the service
being described.
port/protocolthis field is split into two subfields.
porta number that specifies the port number
the named service will be available on. Most
of the common services have assigned service
numbers. These are described in
RFC-1340.
protocolthis subfield may be set to either
tcp or udp.
It is important to note that an entry of 18/tcp is
very different from an entry of 18/udp and that there
is no technical reason why the same service needs to exist on
both. Normally common sense prevails and it is only if a
particular service is available via both tcp and
udp that you will see an entry for both.
aliasesother names that may be used to refer to
this service entry.
Any text appearing in a line after a `
An example /etc/services file.
All modern linux distributions provide a good /etc/services file.
Just in case you happen to be building a machine from the ground up, here is
a copy of the /etc/services file supplied with an old
distribution:
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
In the real world, the actual file is always growing as new
services are being created. If you fear your own copy is incomplete,
I'd suggest to copy a new /etc/services from a recent distribution.
/etc/inetd.conf
The /etc/inetd.conf file is the configuration file for the
Its format is also fairly simple. It is a text file with each line describing
a service that you wish to provide. Any text in a line following a `
service socket_type proto flags user server_path server_args
serviceis the service relevant to this
configuration as taken from the /etc/services
file.
socket_typethis field describes the type of socket
that this entry will consider relevant, allowable
values are: protothe protocol to considered valid for this
entry. This should match the appropriate entry in the
/etc/services file and will typically be
either rpc/tcp or
rpc/udp.
flagsthere are really only two possible settings
for this field. This field setting tells userthis field describes which user account from
/etc/passwd will be set as the owner of the
network daemon when it is started. This is often
useful if you want to safeguard against security
risks. You can set the user of an entry to the
server_paththis field is pathname to the actual
server program to execute for this entry.
server_argsthis field comprises the rest of the
line and is optional. This field is where you place
any command line arguments that you wish to pass to
the server daemon program when it is launched.
An example /etc/inetd.conf
As for the /etc/services file all modern distributions will include
a good /etc/inetd.conf file for you to work with. Here, for
completeness is the /etc/inetd.conf file from the
distribution.
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias
#
#
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
Other miscellaneous network related configuration files.
There are a number of miscellaneous files relating to network configuration
under linux that you might be interested in. You may never have to modify
these files, but it is worth describing them so you know what they contain
and what they are for.
/etc/protocols
The /etc/protocols file is a database that maps protocol id numbers
against protocol names. This is used by programmers to allow them to
specify protocols by name in their programs and also by some programs
such as tcpdump to allow them to display names instead of numbers
in their output. The general syntax of the file is:
protocolname number aliases
The /etc/protocols file supplied with the
distribution is as follows:
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
/etc/networks
The /etc/networks file has a similar function to that of the
/etc/hosts file. It provides a simple database of network names
against network addresses. Its format differs in that there may be
only two fields per line and that the fields are coded as:
networkname networkaddress
An example might look like:
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
When you use commands like the route command, if a destination is
a network and that network has an entry in the /etc/networks file
then the route command will display that network name instead of its
address.
Network Security and access control.
Let me start this section by warning you that securing your machine and
network against malicious attack is a complex art. I do not consider myself
an expert in this field at all and while the following mechanisms I describe
will help, if you are serious about security then I recommend you do some
research of your own into the subject. There are many good references on the
Internet relating to the subject, including the
An important rule of thumb is:
`Don't run servers you don't intend to use'.
Many distributions come configured with all sorts of services configured and
automatically started. To ensure even a minimum level of safety you should go
through your /etc/inetd.conf file and comment out (place a `#' at
the start of the line) any entries for services you don't intend to use.
Good candidates are services such as:
There are all sorts of security and access control mechanisms, I'll describe
the most elementary of them.
/etc/ftpusers
The /etc/ftpusers file is a simple mechanism that allows you to
deny certain users from logging into your machine via ftp. The
/etc/ftpusers file is read by the ftp daemon program (ftpd) when
an incoming ftp connection is received. The file is a simple list of those
users who are disallowed from logging in. It might looks something like:
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
/etc/securetty
The /etc/securetty file allows you to specify which tty devices
root is allowed to login on. The /etc/securetty file is read
by the login program (usually /bin/login). Its format is a list of
the tty devices names allowed, on all others
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
The tcpd hosts access control mechanism.
The tcpd program you will have seen listed in the same
/etc/inetd.conf provides logging and access control mechanisms to
services it is configured to protect.
When it is invoked by the inetd program it reads two files containing
access rules and either allows or denies access to the server it is protecting
accordingly.
It will search the rules files until the first match is found. If no match is
found then it assumes that access should be allowed to anyone. The files it
searches in sequence are: /etc/hosts.allow, /etc/hosts.deny.
I'll describe each of these in turn. For a complete description of this
facility you should refer to the appropriate man pages
(hosts_access(5) is a good starting point).
/etc/hosts.allow
The /etc/hosts.allow file is a configuration file of the
/usr/sbin/tcpd program. The hosts.allow file contains
rules describing which hosts are allowed access to a service on
your machine.
The file format is quite simple:
# /etc/hosts.allow
#
# : [: command]
is a comma delimited list of
server names that this rule applies to. Example
server names are: is a comma delimited list of host
names. You may also use IP addresses here. You may
additionally specify hostnames or addresses using
wildcard characters to match groups of hosts. Examples
include: .uts.edu.au to match any hostname
ending in that string, 44. to match any IP
address commencing with those digits. There are some
special tokens to simplify configuration, some of
these are: is an optional parameter. This
parameter is the full pathname of a command that would
be executed everytime this rule is matched. It could
for example run a command that would attempt to
identify who is logged onto the connecting host, or to
generate a mail message or some other warning to a
system administrator that someone is attempting to
connect. There are a number of expansions that may be
included, some common examples are:
An example:
# /etc/hosts.allow
#
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
/etc/hosts.deny
The /etc/hosts.deny file is a configuration file of the
/usr/sbin/tcpd program. The hosts.deny file contains
rules describing which hosts are disallowed access to a service on
your machine.
A simple sample would look something like this:
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
The PARANOID entry is really redundant because the other entry traps
everything in any case. Either of these entry would make a reasonable default
depending on your particular requirement.
Having an ALL: ALL default in the /etc/hosts.deny and then
specifically enabling on those services and hosts that you want in the
/etc/hosts.allow file is the safest configuration.
/etc/hosts.equiv
The
Configure your
Many sites will be interested in running an anonymous ftpd(8) describe in some length how to go about this. You should
always ensure that you follow these instructions. An important tip is to
not use a copy of your /etc/passwd file in the anonymous account
/etc directory, make sure you strip out all account details except
those that you must have, otherwise you will be vulnerable to brute force
password cracking techniques.
Network Firewalling.
Not allowing datagrams to even reach your machine or servers is an
excellent means of security. This is covered in depth in the , and (more concisely)
in a later section of this document.
Other suggestions.
Here are some other, potentially religious suggestions for you to consider.
sendmaildespite its popularity the sendmail
daemon appears with frightening regularity on security
warning announcements. Its up to you, but I choose not
to run it.
NFS and other Sun RPC servicesbe wary of
these. There are all sorts of possible exploits for
these services. It is difficult finding an option to
services like NFS, but if you configure them, make
sure you are careful with who you allow mount rights
to.
Ethernet Information
This section covers information specific to Ethernet and the configuring
of Ethernet Cards.
Supported Ethernet Cards
3Com
- 3Com 3c501 - `avoid like the plague'' (3c501 driver)
- 3Com 3c503 (3c503 driver), 3c505 (3c505 driver), 3c507 (3c507 driver), 3c509/3c509B (ISA) / 3c579
(EISA)
- 3Com Etherlink III Vortex Ethercards (3c590, 3c592, 3c595, 3c597)
(PCI), 3Com Etherlink XL Boomerang (3c900, 3c905) (PCI) and Cyclone
(3c905B, 3c980) Ethercards (3c59x driver) and 3Com Fast EtherLink
Ethercard (3c515) (ISA) (3c515 driver)
- 3Com 3ccfe575 Cyclone Cardbus (3c59x driver)
- 3Com 3c575 series Cardbus (3c59x driver) (ALL PCMCIA ??)
AMD, ATT, Allied Telesis, Ansel, Apricot
- AMD LANCE (79C960) / PCnet-ISA/PCI (AT1500, HP J2405A,
NE1500/NE2100)
- ATT GIS WaveLAN
- Allied Telesis AT1700
- Allied Telesis LA100PCI-T
- Allied Telesyn AT2400T/BT ("ne" module)
- Ansel Communications AC3200 (EISA)
- Apricot Xen-II / 82596
Cabletron, Cogent, Crystal Lan
- Cabletron E21xx
- Cogent EM110
- Crystal Lan CS8920, Cs8900
Danpex, DEC, Digi, DLink
- Danpex EN-9400
- DEC DE425 (EISA) / DE434/DE435 (PCI) / DE450/DE500 (DE4x5 driver)
- DEC DE450/DE500-XA (dc21x4x) (Tulip driver)
- DEC DEPCA and EtherWORKS
- DEC EtherWORKS 3 (DE203, DE204, DE205)
- DECchip DC21x4x "Tulip"
- DEC QSilver's (Tulip driver)
- Digi International RightSwitch
- DLink DE-220P, DE-528CT, DE-530+, DFE-500TX, DFE-530TX
Fujitsu, HP, ICL, Intel
- Fujitsu FMV-181/182/183/184
- HP PCLAN (27245 and 27xxx series)
- HP PCLAN PLUS (27247B and 27252A)
- HP 10/100VG PCLAN (J2577, J2573, 27248B, J2585) (ISA/EISA/PCI)
- ICL EtherTeam 16i / 32 (EISA)
- Intel EtherExpress
- Intel EtherExpress Pro
KTI, Macromate, NCR NE2000/1000, Netgear, New Media
- KTI ET16/P-D2, ET16/P-DC ISA (work jumperless and with hardware-configuration options)
- Macromate MN-220P (PnP or NE2000 mode)
- NCR WaveLAN
- NE2000/NE1000 (be careful with clones)
- Netgear FA-310TX (Tulip chip)
- New Media Ethernet
PureData, SEEQ, SMC
- PureData PDUC8028, PDI8023
- SEEQ 8005
- SMC Ultra / EtherEZ (ISA)
- SMC 9000 series
- SMC PCI EtherPower 10/100 (DEC Tulip driver)
- SMC EtherPower II (epic100.c driver)
Sun Lance, Sun Intel, Schneider, WD, Zenith, IBM, Enyx
- Sun LANCE adapters (kernel 2.2 and newer)
- Sun Intel adapters (kernel 2.2 and newer)
- Schneider and Koch G16
- Western Digital WD80x3
- Zenith Z-Note / IBM ThinkPad 300 built-in adapter
- Znyx 312 etherarray (Tulip driver)
General Ethernet Information
Ethernet devices names are `
Once you have your kernel properly built to support your ethernet card then
configuration of the card is easy.
Typically you would use something like (which most distributions already
do for you, if you configured them to support your ethernet):
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
Most of the ethernet drivers were developed by
Using 2 or more Ethernet Cards in the same machine
If your driver is a module (Normal with newer distros)
The module will typically can detect all of the installed cards.
Information fromt he detection is stored in the file:
/etc/conf.modules.
Consider that a user has 3 NE2000 cards, one at 0x300
one at 0x240, and one at 0x220. You would add the following
lines to the /etc/conf.modules file:
alias eth0 ne
alias eth1 ne
alias eth2 ne
options ne io=0x220,0x240,0x300
What this does is tell the program modprobe to look for 3 NE based
cards at the following addresses. It also states in which order they should
be found and the device they should be assigned.
Most ISA modules can take multiple comma separated I/O values.
For example:
alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7
The -o option allows for a unique name to be assigned to each module. The
reason for this is that you can not have two copies of the same module
loaded.
The irq= option is used to specify the hardware IRQ and the io= to specify
the different io ports.
By default, the Linux kernel only probes for one Ethernet device, you
need to pass command line arguments to the kernel in order to force detection
of furter boards.
To learn how to make your ethernet card(s) working under Linux you
should refer to the .
IP Related Information
This section covers information specific to IP.