LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/Net-HOWTO/Net-HOWTO.sgml

6922 lines
257 KiB
Plaintext
Raw Blame History

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<BOOK>
<BOOKINFO>
<Title><ULINK URL="http://www.linuxports.com/">Linux Networking HOWTO</ULINK></Title>
<AUTHOR><FirstName>Joshua</FirstName> <Surname>Drake</Surname></AUTHOR>
<PubDate>v1.7.0, 29 December 2000</PubDate>
<COPYRIGHT><YEAR>2000</YEAR><HOLDER>Commandprompt, Inc</HOLDER></COPYRIGHT>
<ABSTRACT>
<PARA>
This is a LinuxPorts.Com Document for the Linux Documentation Project. It has been sponsored in part
by the <ULink URL="http://www.opendocspublishing.com/">Open Source Documentation Fund.</ULink>
</PARA>
<PARA>
The current version is v1.7.0 is a minor update with some grammar fixes.
</PARA>
</ABSTRACT>
</BOOKINFO>
<CHAPTER><TITLE>How can I help?</TITLE>
<Para>
We will try to provide comprehensive coverage for all Linux Networking implementations. However,
time is of the essence, and this document is not a revenue maker. We provide this information
in the hope that it will be useful to both the Linux Community and to newly converted Linux users.
We are always interested in feedback! We will implement every relevant topic possible in
this HOWTO document.
</Para>
<Para>
</para>
<SECT1><TITLE>Assisting with the Net-HOWTO</TITLE>
<Para>
If you would like to assist with this document, there are two primary avenues that are extremely
helpful.
</Para>
<ItemizedList>
<ListItem>
<Para>
<Ulink URL="http://www.linuxports.com/cart/">Purchase an OpenBook!</Ulink> If you purchase
OpenDocs books, OpenDocs Publishing will donate a portion of the proceeds back to the
<Ulink URL="http://www.opendocspublishing.com/">Open Source Documentation Fund.</Ulink> This
fund assists authors financially while they continue to write documentation for Open Source
projects.
</Para>
</ListItem>
<ListItem>
<Para>
<EMPHASIS>Provide a monetary contribution to the document</EMPHASIS>. By contributing, you can even request what
you would like to have updated, written, or expanded within the document. To provide
a monetary contribution, please contact <Ulink URL="http://www.commandprompt.com/">Command Prompt, Inc.</Ulink>
You may also contact <ULink URL="mailto:poet@linuxports.com">Joshua Drake</Ulink>.
</Para>
</ListItem>
<ListItem>
<Para>
If you have written something that you would like to contribute, please email it to
<Ulink URL="mailto:poet@linuxports.com">poet@linuxports.com</Ulink>
</Para>
</ListItem>
</ItemizedList>
</Sect1>
</Chapter>
<Chapter>
<Title>Document History</Title>
<Para>
The original NET-FAQ was written by Matt Welsh and Terry Dawson. NET-FAQ
answered frequently asked questions about networking for Linux (at a time
before the Linux Documentation Project had formally started). This document
covered the very early development versions of the Linux Networking
Kernel. The NET-2-HOWTO superseded the NET-FAQ, and it was one of the
original LDP HOWTO documents. It covered what was called "version 2" (and
subsequently "version 3") of the Linux kernel Networking software. NET-2_HOWTO
in turn superseded it, and relates only to version 4 of the Linux
Networking Kernel (ie: kernel releases 2.x and 2.2.x. ).
</Para>
<Para>
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 HOWTOs dealing with specific
networking topics have been produced. This document will provide
pointers to them where relevant, and it will cover those areas not yet reviewed
by other documents.
</Para>
<Sect1>
<Title>Feedback</Title>
<Para>
We are always interested in feedback. Please contact us at:
<ULink URL="mailto:poet@linuxports.com">poet@linuxports.com</ULink>.
</Para>
<Para>
If you find anything erroneous, or if you feel that something should be
added, please <ULink URL="mailto:poet@linuxports.com">contact us</ULink>.
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>How to use this HOWTO.</Title>
<Para>
This document is organized top-down. The first sections include
informative material, and it 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 ``technology specific'' information is grouped into
three main sections: Ethernet and IP-related information, technologies
pertaining to widespread PC hardware, and seldom-used technologies.
</Para>
<Para>
The suggested path through this document is as follows:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>Read the generic sections:</Term>
<ListItem>
<Para>
These sections apply to almost every technology described in
subsequent sections, and they are very important for you to understand.
I expect many of the readers will be confident with this material.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Consider your network:</Term>
<ListItem>
<Para>
You should know how your network is (or will be)
designed, and you should also be familiar with
exactly what hardware and technology types you will be implementing.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>If you are directly connected to a LAN or the Internet,
please refer to the ``Ethernet and IP'' section:</Term>
<ListItem>
<Para>
This section describes basic Ethernet configurations, and it describes
the various features that Linux offers for IP networking (ie: firewalling,
advanced routing, etc).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term> If you are interested in low-cost local
networks or dial-up connections, please refer to the next section</Term>
<ListItem>
<Para>
This section describes the widespread technologies used on personal
workstations (ie: PLIP, PPP, SLIP, and ISDN).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Please refer to the technology-specific sections
that are related to your requirements:</Term>
<ListItem>
<Para>
Your needs may differ from IP and/or other common
hardware This final section covers details specific to both
non-IP protocols and to peculiar communication hardware.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Do the configuration work:</Term>
<ListItem>
<Para>
You should actually try to
configure your network. Take careful note of
any existing problems
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Look for further help:</Term>
<ListItem>
<Para>
If you experience problems that this document does not
help you to resolve, then you should refer to the sections
related to "Help" and "Where to report bugs".
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Have fun!</Term>
<ListItem>
<Para>
Networking is fun! Enjoy it!
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Sect1>
<Title>Conventions used in this document</Title>
<Para>
No special conventions are used here, but you must be warned about
the way commands are shown. This howto follows the classic Unix documentation:
any command you type to your shell is prefixed by a
prompt. It shows "<Literal remap="tt">user&percnt;</Literal>" as the prompt for commands
that do not require superuser privileges, and "<Literal remap="tt">root&num;</Literal>" as the
prompt for commands that need to run as root. I chose to use
"<Literal remap="tt">root&num;</Literal>" instead of a plain "<Literal remap="tt">&num;</Literal>" to prevent confusion
with snapshots from shell scripts (where the hash mark is used to
define comment lines).
</Para>
<Para>
When ``Kernel Compile Options'' are shown, they are represented in
the format used by <Emphasis>menuconfig</Emphasis>. They should be understandable even
if you (like me) are not used to <Emphasis>menuconfig</Emphasis>. If you are
in doubt about the options' nesting, then running the program once can
always help.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>General Information about Linux Networking.</Title>
<Sect1>
<Title>Linux Networking Resources.</Title>
<Para>
There are a number of places where you can find good information about
Linux networking.
</Para>
<Para>
There are a wealth of Consultants available to assist you. A search able
listing can be found at:
<ULink
URL="http://www.linuxports.com/">http://www.linuxports.com/.</ULink>
</Para>
<Para>
Alan Cox, the current maintainer of the Linux kernel networking code, maintains
a world wide web page containing highlights of current and new developments
in Linux Networking:
<ULink
URL="http://www.uk.linux.org/NetNews.html">www.uk.linux.org</ULink>.
</Para>
<Para>
There is a newsgroup in the Linux news hierarchy dedicated to networking
and related matters at this location:
<ULink
URL="news:comp.os.linux.networking">comp.os.linux.networking</ULink>
</Para>
<Para>
You can also subscribe to a mailing list where you may ask questions
relating to Linux networking. Send an email message for a subscription to:
<Screen>
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:
subscribe linux-net
</Screen>
</Para>
<Para>
Please remember to include as much relevant detail
about the problem as possible. You should specify the versions of
software that you are using (especially the kernel version), the version of
tools such as <Emphasis remap="bf">pppd/</Emphasis> or <Emphasis remap="bf">dip</Emphasis> ,
and the exact nature of the problem(s) that you are experiencing. This means you should take notes
of both the exact syntax of error message(s) you receive, and of any commands that you are issuing.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Sources of non-linux-specific network information.</Title>
<Para>
If you are after some basic tutorial information on tcp/ip networking,
then I recommend you take a look at the following documents:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>tcp/ip introduction:</Term>
<ListItem>
<Para>
This document comes as both a <ULink
URL="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc">text version</ULink> and a <ULink
URL="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps">postscript version</ULink>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>tcp/ip administration: </Term>
<ListItem>
<Para>
This document comes as both a
<ULink
URL="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc">text version</ULink> and a <ULink
URL="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps">postscript version</ULink>.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
If you are after some more detailed information on tcp/ip networking, then
I highly recommend:
</Para>
<Para>
<QUOTE><Emphasis>Inter networking with TCP/IP, Volume 1: Principles,
Protocols and Architecture</Emphasis>, by Douglas E. Comer, ISBN
0-13-227836-7, Prentice Hall publications, Third Edition,
1995.</QUOTE>
</Para>
<Para>
If you are wanting to learn about how to write network applications in
a Unix compatible environment, then I recommend:
</Para>
<Para>
<QUOTE><Emphasis>Unix Network Programming</Emphasis>, by W. Richard Stevens,
ISBN 0-13-949876-1, Prentice Hall Publications, 1990.</QUOTE>
</Para>
<Para>
A second edition of this book is appearing on the bookshelves. The new
book is made up of three volumes. Check <ULink
URL="http://www.phptr.com/">Prenice-Hall's web site</ULink> for further details.
</Para>
<Para>
You might also try the <ULink
URL="news:comp.protocols.tcp-ip">comp.protocols.tcp-ip</ULink> newsgroup.
</Para>
<Para>
RFCs are an important source of specific technical information relating to
the Internet and the tcp/ip suite of protocols. RFC is an
acronym for `Request For Comment' and it is the standard means of
submitting and documenting Internet protocol standards. There are many
RFC repositories. Many of these sites are ftp sites. Others provide
World Wide Web access (with an associated search engine) that allows you
to search the RFC database for particular keywords.
</Para>
<Para>
One possible source for RFCs is at <ULink
URL="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html">Nexor RFC database</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Generic Network Configuration Information.</Title>
<Para>
You will pretty much need to know and understand the following subsections
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.
</Para>
<Sect1>
<Title>What do I need to start ?</Title>
<Para>
Before you start building or configuring your network, you will need
certain items. The most important of these are:
</Para>
<Sect2>
<Title>Current Kernel source(Optional).</Title>
<Para>
Please note:
</Para>
<Para>
The majority of current distributions come with networking enabled.
It may not be required to recompile the kernel. If you are running well known
hardware you should be fine. For example: 3COM NIC, NE2000 NIC, or an
Intel NIC. However, if you find yourself in the position that you do need to
update the kernel, the following information is provided.
</Para>
<Para>
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 to recompile the kernel with the appropriate
options.
</Para>
<Para>
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).
</Para>
<Para>
You can always obtain the latest kernel source from <ULink
URL="ftp://ftp.cdrom.com/pub/linux/sunsite/kernel.org/pub/linux/kernel">ftp.cdrom.com</ULink>.
This is not the official site, but they have LOTS of bandwidth and capacity.
The official site is kernel.org, however, please use the above URL if
you can. Please remember that ftp.kernel.org is seriously overloaded. Use a
mirror.
</Para>
<Para>
Normally the kernel source will be untarred into the
<Literal remap="tt">/usr/src/linux</Literal> directory. For information on how to apply
patches and build the kernel, you should read the <ULink
URL="Kernel-HOWTO.html">Kernel-HOWTO</ULink>. For information on how
to configure kernel modules, you should read the ``Modules
mini-HOWTO''. The <Literal remap="tt">README</Literal> file found in the kernel
sources and the <Literal remap="tt">Documentation</Literal> directory are very informative:
for the brave reader!
</Para>
<Para>
Unless specifically stated, 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 other software on your
system. If you are uncertain that you could resolve those sorts of
problems, then don't use Development release kernels.
</Para>
</Sect2>
<Sect2>
<Title>IP Addresses: an Explanation.</Title>
<Para>
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). It drops any leading
zeros (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, but usually each interface will have its own address.
</Para>
<Para>
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. It
is the role of the netmask to determine which addresses belong to the network it
is applied to and which don't belong. For example, consider the following:
</Para>
<Para>
<Screen>
----------------- ---------------
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
----------------- ---------------
</Screen>
</Para>
<Para>
Any address that is 'bitwise anded' with its netmask will reveal the address
of the network that it belongs to. The network address is therefore always the
lowest numbered address within the range of addresses on the network, and
it always has the host portion of the address coded in all zeroes.
</Para>
<Para>
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
the broadcast address. The most widely accepted one is to
use the highest possible address on the network as the broadcast address.
In the above example, this would be <Literal remap="tt">192.168.110.255</Literal>.
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.
</Para>
<Para>
For administrative reasons (some time early in the development of the IP
protocol), some arbitrary groups of addresses were formed into networks.
These networks were grouped into what are called classes. Classes
provide a number of standard size networks that could be allocated. The ranges
allocated are:
</Para>
<Para>
<Screen>
--------------------------------------------------------------------------------
| 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 |
--------------------------------------------------------------------------------
</Screen>
</Para>
<Para>
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:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>Installing a Linux machine on an existing IP network</Term>
<ListItem>
<Para>
If you wish to install a Linux machine onto an existing IP network, then
you should contact the network administrator and ask them for
the following information:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
Host IP Address
</Para>
</ListItem>
<ListItem>
<Para>
IP network address
</Para>
</ListItem>
<ListItem>
<Para>
IP broadcast address
</Para>
</ListItem>
<ListItem>
<Para>
IP netmask
</Para>
</ListItem>
<ListItem>
<Para>
Router address
</Para>
</ListItem>
<ListItem>
<Para>
Domain Name Server Address
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
You should then configure your linux network device with those
details. You can not make them up and expect your configuration to
work.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Building a brand new network that will never connect to the
Internet</Term>
<ListItem>
<Para>
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:
</Para>
<Para>
<Screen>
-----------------------------------------------------------
| 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 |
-----------------------------------------------------------
</Screen>
</Para>
<Para>
You should first decide how large you want your network to be, then
choose as many of the addresses as you require.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Where should I put the configuration commands ?</Title>
<Para>
There are a few different approaches to Linux system boot
procedures. After the kernel boots, it always executes a program
called `<Emphasis>init</Emphasis>'. The <Emphasis>init</Emphasis> program then reads its configuration
file called <Literal remap="tt">/etc/inittab</Literal> and commences the boot
process. There are a few different flavors of <Emphasis>init</Emphasis>
Everyone now seems to be gravitating to the System V (Five) flavor,
developed by Miguel van Smoorenburg.
</Para>
<Para>
Despite the fact that the <Emphasis>init</Emphasis> program is always the same, the
setup of system boot is organized in a different way by each
distribution.
</Para>
<Para>
Usually the <Literal remap="tt">/etc/inittab</Literal> file contains an entry looking something
like:
</Para>
<Para>
<Screen>
si::sysinit:/etc/init.d/boot
</Screen>
</Para>
<Para>
This line specifies the name of the shell script file that actually manages
the boot sequence. This file is somewhat equivalent to the <Literal remap="tt">AUTOEXEC.BAT</Literal>
file in MS-DOS.
</Para>
<Para>
There are usually other scripts that are called by the boot script, and often
the network is configured within one of these scripts.
</Para>
<Para>
The following table may be used as a guide for your system:
</Para>
<Para>
<Screen>
---------------------------------------------------------------------------
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/*
---------------------------------------------------------------------------
</Screen>
</Para>
<Para>
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 <Literal remap="tt">/etc/sysconfig</Literal>, where it is
retrieved by boot scripts). If you want to grasp the details of the
boot process, my suggestion is to check <Emphasis>/etc/inittab</Emphasis> and the
documentation that accompanies <Emphasis>init</Emphasis>. 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.
</Para>
<Para>
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, you should see if it will do what you want before
attempting a manual configuration.
</Para>
<Para>
<Screen>
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
</Screen>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Creating your network interfaces.</Title>
<Para>
In many Unix operating systems, the network devices have appearances in the
<Emphasis>/dev</Emphasis> directory. This is not so in Linux. In Linux, the network devices
are created dynamically in software, and they do not require device files to
be present.
</Para>
<Para>
In the majority of cases, the network device is automatically created by the
device driver (while it is initializing and locating your hardware). For
example, the Ethernet device driver creates <Literal remap="tt">eth&lsqb;0..n]</Literal> interfaces
sequentially as it locates your Ethernet hardware. The first Ethernet card
found becomes <Literal remap="tt">eth0</Literal>, the second <Literal remap="tt">eth1</Literal> etc.
</Para>
<Para>
In some cases though, notably with <Emphasis>slip</Emphasis> and <Emphasis>ppp</Emphasis>, the network devices
are created through the action of some user program. The same sequential
device numbering applies, but the devices are not created automatically
at boot time. The reason for this is that unlike Ethernet devices, the number
of active <Emphasis>slip</Emphasis> or <Emphasis>ppp</Emphasis> devices may vary during the uptime of the
machine. These cases will be covered in more detail in later sections.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Configuring a network interface. Kernels 2.0 and 2.2</Title>
<Para>
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 two items. One is the process of assigning
appropriate addresses to a network device. The second is setting the appropriate values
for other configurable parameters of a network device. The program most
commonly used to do this is the <Emphasis>ifconfig</Emphasis> (interface configure) command.
</Para>
<Para>
Typically you would use a command similar to the following:
</Para>
<Para>
<Screen>
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
</Screen>
</Para>
<Para>
In this example, I'm configuring an Ethernet interface `<Literal remap="tt">eth0</Literal>' with the
IP address `<Literal remap="tt">192.168.0.1</Literal>' and a network mask of `<Literal remap="tt">255.255.255.0</Literal>'.
The `<Emphasis>up</Emphasis>' that trails the command tells the interface that it should
become active (but can usually be omitted) since it is the default. To
shutdown an interface, you can just call ``<Literal remap="tt">ifconfig eth0 down</Literal>''.
</Para>
<Para>
The kernel assumes certain defaults when you are configuring interfaces. For example,
you may specify the network address and broadcast address for an interface.
If you don't (as in my example above), then the kernel will make reasonable
guesses as to what these addresses should be. If you don't supply a netmask
then on the network class of the IP address is auto-configured.
In my example, the kernel would assume that it is a class-C network that is
being configured on the interface. It would thus configure a network address of
`<Literal remap="tt">192.168.0.0</Literal>' ,and a broadcast address of
`<Literal remap="tt">192.168.0.255</Literal>' for the interface.
</Para>
<Para>
There are many other options to the <Emphasis>ifconfig</Emphasis> command. The most
important of these are:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>up</Term>
<ListItem>
<Para>
This option activates an interface (and it is the default).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>down</Term>
<ListItem>
<Para>
This option deactivates an interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;arp</Term>
<ListItem>
<Para>
This option enables or disables use of the
address resolution protocol on this interface .
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;allmulti</Term>
<ListItem>
<Para>
This option enables or disables the
reception of all hardware multicast packets. Hardware
multicast enables groups of hosts to receive packets
addressed to special destinations. This may be of
importance if you are using applications like desktop
video conferencing. This option is normally not used.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>mtu N</Term>
<ListItem>
<Para>
This parameter allows you to set the <Emphasis>MTU</Emphasis> of
this device.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>netmask &lt;addr&#62;</Term>
<ListItem>
<Para>
This parameter allows you to set the network
mask of the network. This device belongs to:
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>irq &lt;addr&#62;</Term>
<ListItem>
<Para>
This parameter only works on certain types of
hardware. It allows you to set the hardware IRQ
of this device.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;broadcast &lsqb;addr&rsqb;</Term>
<ListItem>
<Para>
This parameter allows you
to enable and set the accepting of datagrams destined
to the broadcast address.It also allows you to disable reception
of these datagrams.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;pointopoint &lsqb;addr&rsqb;</Term>
<ListItem>
<Para>
This parameter allows you
to set the address of the machine at the remote end of
a Point-to-Point link (ie; for <Emphasis>slip</Emphasis> or
<Emphasis>ppp</Emphasis>).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>hw &lt;type &lt;addr&#62;</Term>
<ListItem>
<Para>
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 like AX.25.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
With the release of Kernel 2.2, there are a number of options available
that are not listed above. Some of the most interesting ones are tunneling and
IPV6. The ifconfig parameters for kernel 2.2 are listed below.
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>interface</Term>
<ListItem>
<Para>
The name of the interface. This is usually a
driver name followed by a unit number. For example,
eth0 for the first Ethernet interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>up</Term>
<ListItem>
<Para>
This flag causes the interface to be activated. It
is implicitly specified if an address is assigned
to the interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>down</Term>
<ListItem>
<Para>
This flag causes the driver for this interface to
be shut down.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;arp</Term>
<ListItem>
<Para>
Enables or disables the use of the ARP protocol on
this interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;promisc</Term>
<ListItem>
<Para>
Enables or disables the promiscuous mode of the
interface. If selected, all packets on the network
will be received by the interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;allmulti</Term>
<ListItem>
<Para>
Enables or disables all-multicast mode. If selected,
all multicast packets on the network will be
received by the interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>metric N</Term>
<ListItem>
<Para>
This parameter sets the interface metric.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>mtu N</Term>
<ListItem>
<Para>
This parameter sets the Maximum Transfer Unit (MTU)
of an interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>dstaddr addr</Term>
<ListItem>
<Para>
Sets the remote IP address for a point-to-point link
(such as PPP). This keyword is now obsolete; you should
now use the pointopoint keyword.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>netmask addr</Term>
<ListItem>
<Para>
Sets 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).
It can, however, be set to any value.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>add addr prefixlen</Term>
<ListItem>
<Para>
Adds an IPv6 address to an interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>del addr prefixlen</Term>
<ListItem>
<Para>
Removes an IPv6 address from an interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>tunnel aa.bb.cc.dd</Term>
<ListItem>
<Para>
Creates a new SIT (IPv6-in-IPv4) device that tunnels
to the given destination.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>irq addr</Term>
<ListItem>
<Para>
Sets the interrupt line used by this device. Not
all devices can dynamically change their IRQ set-
ting.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>io&lowbar;addr addr</Term>
<ListItem>
<Para>
Sets the start address in I/O space for this device.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>mem&lowbar;start addr</Term>
<ListItem>
<Para>
Set the start address for shared memory used by
this device. Only a few devices need this parameter.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>media type</Term>
<ListItem>
<Para>
Sets the physical port (or medium type) to be used by
the device. Not all devices can change this set-
ting. Those that can change the setting 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.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;broadcast &lsqb;addr&rsqb;</Term>
<ListItem>
<Para>
If the address argument is given, set the protocol
broadcast address for this interface. Otherwise,
set (or clear) the IFF&lowbar;BROADCAST flag for the
interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>&lsqb;-&rsqb;pointopoint &lsqb;addr&rsqb;</Term>
<ListItem>
<Para>
This keyword enables the point-to-point mode of an
interface. This means that it is a direct link between
two machines, and that nobody else is listening on it.
If the address argument is also given, set the pro-
tocol address of the other side of the link ( just
as the obsolete dstaddr keyword does). Otherwise,
set or clear the IFF&lowbar;POINTOPOINT flag for the
interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>hw class address</Term>
<ListItem>
<Para>
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).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>multicast</Term>
<ListItem>
<Para>
Set the multicast flag on the interface. This
should not normally be needed because the drivers set
the flag correctly themselves.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>address</Term>
<ListItem>
<Para>
The IP address to be assigned to this interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>txqueuelen length</Term>
<ListItem>
<Para>
Sets 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). This
prevents fast bulk transfers from disturbing inter-
active traffic (like telnet) too much.
</Para>
<Para>
You may use the <Emphasis>ifconfig</Emphasis> command on any network interface. Some user
programs such as <Emphasis>pppd</Emphasis> and <Emphasis>dip</Emphasis> automatically configure the network
devices as they create them, so manual use of <Emphasis>ifconfig</Emphasis> is unnecessary.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Configuring your Name Resolver.</Title>
<Para>
The `<Emphasis>Name Resolver</Emphasis>' is a part of the linux standard library. Its prime
function is to provide a service to convert human-friendly hostnames (like
`<Literal remap="tt">ftp.funet.fi</Literal>' ) into machine friendly IP addresses (such as
<Literal remap="tt">128.214.248.6</Literal>).
</Para>
<Sect2>
<Title>What's in a name ?</Title>
<Para>
You will probably be familiar with the appearance of Internet host
names, but you may not understand how they are constructed or
de-constructed. Internet domain names are hierarchical in nature.
In other words, they have a tree-like structure. A `<Emphasis>domain</Emphasis>' is a family, or
group, of names. A `<Emphasis>domain</Emphasis>' may be broken down into a
`<Emphasis>subdomain</Emphasis>'. A `<Emphasis>top level domain</Emphasis>' is a domain that is not a
subdomain. The Top Level Domains are specified in RFC-920. Some
examples of the most common top level domains are:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>COM</Term>
<ListItem>
<Para>
Commercial Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>EDU</Term>
<ListItem>
<Para>
Educational Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>GOV</Term>
<ListItem>
<Para>
Government Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>MIL</Term>
<ListItem>
<Para>
Military Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>ORG</Term>
<ListItem>
<Para>
Other Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NET</Term>
<ListItem>
<Para>
Internet-Related Organizations
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Country Designator</Term>
<ListItem>
<Para>
These are two- letter codes that
represent a particular country.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
For historical reasons, most domains belonging to one of the
non-country based top level domains were used by organizations within
the United States (even though the United States also has its own country
code `<Literal remap="tt">.us</Literal>'). This is not true any more for <Literal remap="tt">.com</Literal> and <Literal remap="tt">.org</Literal>
domains, which are commonly used by non-us companies.
</Para>
<Para>
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 <Literal remap="tt">com</Literal>, <Literal remap="tt">edu</Literal>, <Literal remap="tt">gov</Literal>, <Literal remap="tt">mil</Literal> and
<Literal remap="tt">org</Literal> domains. So for example you end up with: <Literal remap="tt">com.au</Literal> and
<Literal remap="tt">gov.au</Literal> for commercial and government organizations in Australia;
note that this is not a general rule, as actual policies depend on the
naming authority for each domain.
</Para>
<Para>
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. It can, however, be based on any criterion considered
reasonable and meaningful by the network administrators of the
organization.
</Para>
<Para>
The very left-most portion of the name is always the unique name
assigned to the host machine. It is called the `<Emphasis>hostname</Emphasis>'. The
portion of the name to the right of the hostname is called the
`<Emphasis>domainname</Emphasis>' and the complete name is called the `<Emphasis>Fully
Qualified Domain Name</Emphasis>'.
</Para>
<Para>
To use Terrys host as an example, the fully qualified domain name
is `<Literal remap="tt">perf.no.itg.telstra.com.au</Literal>'. This means that the host name is
`<Literal remap="tt">perf</Literal>' and the domain name is `<Literal remap="tt">no.itg.telstra.com.au</Literal>'. The
domain name is based on a top level domain (based on his country Australia).
And since his email address belongs to a commercial
organization, `<Literal remap="tt">.com</Literal>' is positioned as the next level domain. The name
of the company is (was) `<Literal remap="tt">Telstra</Literal>' . Their internal naming
structure is based on organizational structure. In this case, the
machine belongs to the Information Technology Group (Network
Operations section).
</Para>
<Para>
Usually, the names are much shorter. For example, my ISP is
called ``<Literal remap="tt">systemy.it</Literal>'' . My non-profit organization is called
``<Literal remap="tt">linux.it</Literal>'', without any <Literal remap="tt">com</Literal> and <Literal remap="tt">org</Literal> subdomain.
My own host is just called ``<Literal remap="tt">morgana.systemy.it</Literal>'' :
<Literal remap="tt">rubini@linux.it</Literal> is a valid email address. Note that the owner
of a domain has the rights to register hostnames as well as subdomains.
For example, the LUG I belongs to uses the domain <Literal remap="tt">pluto.linux.it</Literal>,
because the owners of <Literal remap="tt">linux.it</Literal> agreed to open a subdomain for the LUG.
</Para>
</Sect2>
<Sect2>
<Title>What information you will need.</Title>
<Para>
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 `<Emphasis>Domain Name Server</Emphasis>'. You will need to know the IP
address of a local name server that you can use.
</Para>
<Para>
There are three files you need to edit. I'll cover each of these in turn.
</Para>
</Sect2>
<Sect2>
<Title>/etc/resolv.conf</Title>
<Para>
The <Literal remap="tt">/etc/resolv.conf</Literal> is the main configuration file for
the name resolver code. Its format is quite simple. It is a text file that
has one keyword per line. There are three keywords typically used by the file.
These keywords are:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>domain</Term>
<ListItem>
<Para>
This keyword specifies the local domain name.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>search</Term>
<ListItem>
<Para>
This keyword specifies a list of alternate domain
names to search for a hostname
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>name server</Term>
<ListItem>
<Para>
This keyword, which may be used many times,
specifies an IP address of a domain name server to
query when resolving names
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
An example <Literal remap="tt">/etc/resolv.conf</Literal> might look something like:
</Para>
<Para>
<Screen>
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
name server 192.168.10.1
name server 192.168.12.1
</Screen>
</Para>
<Para>
This example specifies that the default domain name to append to unqualified
names (ie hostnames supplied without a domain) is <Literal remap="tt">maths.wu.edu.au</Literal> .
If the host is not found in that domain, it will also try the <Literal remap="tt">wu.edu.au</Literal>
domain directly. Two name server entries are supplied. These entries may be
called upon by the name resolver code to resolve the name.
</Para>
</Sect2>
<Sect2>
<Title>/etc/host.conf</Title>
<Para>
The <Literal remap="tt">/etc/host.conf</Literal> file is where you configure some items that
govern the behavior of the name resolver code. The format of this file
is described in detail in the `<Literal remap="tt">resolv+</Literal>' man page. In nearly all
circumstances, the following example will work for you:
</Para>
<Para>
<Screen>
order hosts,bind
multi on
</Screen>
</Para>
<Para>
This configuration tells the name resolver to check the <Literal remap="tt">/etc/hosts</Literal>
file before attempting to query a name server. It also tells the resolver to return all valid addresses
for a host found in the <Literal remap="tt">/etc/hosts</Literal> file (instead of just the first address).
</Para>
</Sect2>
<Sect2>
<Title>/etc/hosts</Title>
<Para>
The <Literal remap="tt">/etc/hosts</Literal> 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 if the IP address for that host changes, you must
keep this file up to date yourself . In a well managed
system, the only hostnames that usually appear in this file are an
entry for the loopback interface, and also the local hosts name.
</Para>
<Para>
<Screen>
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
</Screen>
</Para>
<Para>
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.
</Para>
</Sect2>
<Sect2>
<Title>Running a name server</Title>
<Para>
If you want to run a local name server, you can do it easily. Please
refer to the <ULink
URL="DNS-HOWTO.html">DNS-HOWTO</ULink> and to any
documents included in your version of <Emphasis>BIND</Emphasis> (Berkeley Internet
Name Domain).
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Configuring your loopback interface.</Title>
<Para>
The `<Literal remap="tt">loopback</Literal>' interface is a special type of interface that allows you
to make connections to yourself. There are various reasons why you might want
to do this. For example, you may wish to test some network software without
interfering with anybody else on your network. By convention, the IP address
`<Literal remap="tt">127.0.0.1</Literal>' has been assigned specifically for loopback. No matter
what machine you go to, if you open a telnet connection to <Literal remap="tt">127.0.0.1</Literal>
you will always reach the local host.
</Para>
<Para>
Configuring the loopback interface is simple, and it must be done
(but note that this task is usually performed by the standard initialization
scripts).
</Para>
<Para>
<Screen>
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
</Screen>
</Para>
<Para>
We'll talk more about the <Emphasis>route</Emphasis> command in the next section.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Routing.</Title>
<Para>
Routing is a big topic. It is easily possible to write large
volumes of text about the subject. 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 this document.
</Para>
<Para>
Let's start with a definition. What is IP routing? Here is one
that I'm using:
</Para>
<Para>
<QUOTE>IP Routing is the process by which a host with
multiple network connections decides where to deliver the IP
datagrams that it has received.</QUOTE>
</Para>
<Para>
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, it uses the routing mechanism 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 an SLIP serial interface).
</Para>
<Para>
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 where the datagram is to be routed,
and the third is optionally the IP address of another machine that
carries the datagram on its next step through the network. You can see this table
in linux by using the following command:
</Para>
<Para>
<Screen>
user% cat /proc/net/route
</Screen>
</Para>
<Para>
or by using either of the following commands:
</Para>
<Para>
<Screen>
user% /sbin/route -n
user% netstat -r
</Screen>
</Para>
<Para>
The routing process is fairly simple. The incoming datagram is received,
the destination address (who it is for) is examined, and then it is 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. The destination address is otherwise assumed to
be on the network supported by the interface.
</Para>
<Para>
To manipulate this table, a special command is used. This command takes
command line arguments and converts them into kernel system calls. These
calls request the kernel to add, delete, or modify entries in the routing table.
The command is called `<Emphasis>route</Emphasis>'.
</Para>
<Para>
Here is a simple example. Imagine you have an Ethernet network. You've been told
it is a class-C network with an address of <Literal remap="tt">192.168.1.0</Literal>. You've been
supplied with an IP address of <Literal remap="tt">192.168.1.10</Literal> for your use, and you have
been told that <Literal remap="tt">192.168.1.1</Literal> is a router connected to the Internet.
</Para>
<Para>
The first step is to configure the interface as described earlier. You would
use a command similar to the following:
</Para>
<Para>
<Screen>
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
</Screen>
</Para>
<Para>
You now need to add an entry into the routing table to tell the kernel that
datagrams for all hosts with addresses that match <Literal remap="tt">192.168.1.*</Literal> should
be sent to the ethernet device. You would use a command similar to:
</Para>
<Para>
<Screen>
root# route add -net 192.1Ethernetetmask 255.255.255.0 eth0
</Screen>
</Para>
<Para>
Note the use of the `<Literal remap="tt">-net</Literal>' argument to tell the route program that this
entry is a network route. Your other choice here is a `<Literal remap="tt">-host</Literal>' route, which
is a route that is specific to one IP address.
</Para>
<Para>
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?
</Para>
<Para>
It would be a very difficult job to have to add routes to every possible
destination network. There is a special trick that is used to simplify this
task. The trick is called the `<Literal remap="tt">default</Literal>' route. The <Literal remap="tt">default</Literal> route
matches every possible destination (but poorly). If any other entry
exists that matches the required address, it will be used instead of the
<Literal remap="tt">default</Literal> route. The idea of the <Literal remap="tt">default</Literal> route is simply to enable
you to say in effect: "and everything else should go here". In this example
you would use an entry like:
</Para>
<Para>
<Screen>
root# route add default gw 192.168.1.1 eth0 on them
</Screen>
</Para>
<Para>
The `<Literal remap="tt">gw</Literal>' argument tells the route command that the next argument is
the IP address, or name, of a gateway or router machine. This machine is where all datagrams
matching the entry should be directed to for further routing. on them
</Para>
<Para>
So, your complete configuration would look like:
</Para>
<Para>
<Screen>
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 on them
</Screen> is
</Para>
<Para>
If you take a close look at your network `<Literal remap="tt">rc</Literal>' files, you will find
that at least one of them looks very similar to this configuration (a very common
one).
</Para>
<Para>
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 it also has
one PPP link. Our routing configuration would look something like the fEthernet:
</Para>
<Para>
<Screen>
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
</Screen>
</Para>
<Para>
Each of the workstations would use the simpler form presented
above. Only the router needs to specify each of the network routes
separately. The <Literal remap="tt">default</Literal> route for the workstations
mechanism will capture all of them, letting the router worry about
splitting them up appropriately. You may be wondering why the default
route presented doesn't specify a `<Literal remap="tt">gw</Literal>'. The reason for this is
simple: serial link protocols such as PPP and SLIP only have two
hosts on their network (one at each end). To specify the host at the
other end of the link as the gateway is both pointless and redundant.
You do not need to specify a gateway for these types of network connections as there is
no other choice. Other network types, such as
ethernet, arcnet, or token ring, do actually require the gateway to be specified
(as these networks support Ethernetmbers of hosts ).
</Para>
<Sect2>
<Title>So what does the <Emphasis>routed</Emphasis> program do ?</Title>
<Para>
The routing configuration described above is best suited for simple network
arrangements where there are only 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.
</Para>
<Para>
The big problem with `manual routing' or `static routing' is
that if a machine or link fails in your network, the only way to
re-direct your datagrams (if another way in fact 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'.
</Para>
<Para>
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. It is more capable at handling large network
configurations, and it is better suited to environments where there is a large number
of possible paths through the network. Common implementations of these
protocols are: `<Emphasis>routed</Emphasis>' - RIP and `<Emphasis>gated</Emphasis>' - RIP, OSPF and others.
The `<Emphasis>routed</Emphasis>' program is normally supplied with your Linux distribution,
or it is included in the `NetKit' package detailed above.
</Para>
<Para>
An example of where and how you might use a dynamic routing protocol might
look something like the following:
</Para>
<Para>
<Screen>
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
</Screen>
</Para>
<Para>
We have three routers A, B and C. Each router supports one ethernet segment with
a Class C IP network (netmask 255.255.255.0). Each one also has a PPP link
to each of tEthernet routers. The network ultimately forms a triangle.
</Para>
<Para>
It should be clear that the routing table at router A could look like the following:
</Para>
<Para>
<Screen>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eandth0
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
</Screen>
</Para>
<Para>
This would work just fine until the link between router A and B fails.
Hosts on the ethernet segment of A (see above diagram) could not reach hosts on the
ethernet segment on B: their datagramEthernete directed to router As ppp0 link
(which in this example is broEthernetey could still continue to talk to hosts on the ethernet segment
of C. And hosts on CCsethernet segment could still talk to hosts on
BBsethernet segment. TheEthernetnications can still occur because the link between B
and C is still intact.
</Para>
<Para>
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:
</Para>
<Para>
<Screen>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
</Screen>
</Para>
<Para>
The `<Emphasis>routed</Emphasis>' routing daemon automatically finds all active network
ports (when it sends and listens for messages on each of the
network devices) to allow it to both determine and update the routing table
on the host.
</Para>
<Para>
This has been a very brief explanation of dynamic routing.
If you would like more information, please refer to the suggested
references listed at the top of this document.
</Para>
<Para>
The important points relating to dynamic routing are:
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
You only need to run a dynamic routing protocol daemon
when your Linux machine has the possibility of
selecting multiple route alternatives to a destination.
An example of this would be if you plan to use
IP Masquerading.
</Para>
</ListItem>
<ListItem>
<Para>
The dynamic routing daemon will automatically modify
your routing table to adjust to changes in your
network.
</Para>
</ListItem>
<ListItem>
<Para>
RIP is suitable for small to medium sized networks.
</Para>
</ListItem>
</OrderedList>
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Configuring your network servers and services.</Title>
<Para>
Network servers and services are programs that allow a remote user to
make use of your Linux machine. Server programs listen on network ports.
Network ports are a means of addressing a particular service on any particular
host. They 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. The server program (the network daemon
program) listening on that port accepts the connection and then executes. There are
two ways that network daemons may operate. Both are commonly employed in
practice. The two ways are:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>sstand-alone</Term>
<ListItem>
<Para>
The network daemon program listens on the
designated network port. When an incoming
connection is made, the daemon manages the network connection
itself to provide the service.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>slave to the <Emphasis>inetd</Emphasis> server</Term>
<ListItem>
<Para>
The <Emphasis>inetd</Emphasis> 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 upon receiving an incoming connection. Any
service port may be configured for either of the tcp
or udp protocols. The ports are described in another
file that we will soon review..
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
There are two important files that need to be configured. They are the
<Literal remap="tt">/etc/services</Literal> file (which assigns names to port numbers), and the
<Literal remap="tt">/etc/inetd.conf</Literal> file (the configuration file for the
<Emphasis>inetd</Emphasis> network daemon).
</Para>
<Sect2>
<Title><Literal remap="tt">/etc/services</Literal></Title>
<Para>
The <Literal remap="tt">/etc/services</Literal> 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 where each line represents 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:
</Para>
<Para>
name port/protocol aliases # comment
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>name</Term>
<ListItem>
<Para>
A single word name that represents the service
being described.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>port/protocol</Term>
<ListItem>
<Para>
This field is split into two subfields.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>port</Term>
<ListItem>
<Para>
A number that specifies the port number where
the named service will be available. Most
of the common services have assigned service
numbers. These are described in
<Literal remap="tt">RFC-1340</Literal>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>protocol</Term>
<ListItem>
<Para>
This subfield may be set to either
<Literal remap="tt">tcp</Literal> or <Literal remap="tt">udp</Literal>.
</Para>
<Para>
It is important to note that an entry of <Literal remap="tt">18/tcp</Literal> is
very different from an entry of <Literal remap="tt">18/udp</Literal> There
is no technical reason why the same service needs to exist on
both. Normally common sense prevails. It is only if a
particular service is available via both <Literal remap="tt">tcp</Literal> and
<Literal remap="tt">udp</Literal> that you will see an entry for both.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>aliases</Term>
<ListItem>
<Para>
Other names that may be used to refer to
this service entry.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
Any text appearing in a line after a `<Literal remap="tt">&num;</Literal>' character is ignored, and
it is treated as a comment.
</Para>
<Sect3>
<Title>An example <Literal remap="tt">/etc/services</Literal> file.</Title>
<Para>
All modern linux distributions provide a good <Literal remap="tt">/etc/services</Literal> file.
Just in case you happen to be building a machine from the ground up, here is
a copy of the <Literal remap="tt">/etc/services</Literal> file supplied with an old
<ULink
URL="http://www.debian.org/">Debian</ULink> distribution:
</Para>
<Para>
<Screen>
# /etc/services:
# $Id$
#
# 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 Protoconame server
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/tcname serverTP server
bootps 67/udp
bootpc 68/tcname serverTP 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'':
#
#&#62; The Registered Ports are not controlled by the IANA and on most systems
#&#62; can be used by ordinary user processes or programs executed by ordinary
#&#62; users.
#
#&#62; Ports are used in the TCP [45,106] to name the ends of logical
#&#62; connections which carry long term conversations. For the purpose of
#&#62; providing services to unknown callers, a service contact port is
#&#62; defined. This list specifies the port used by the server process as its
#&#62; contact port. While the IANA can not control uses of these ports it
#&#62; does register or list uses of these ports as a convenience to the
#&#62; 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
</Screen>
</Para>
<Para>
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 <Literal remap="tt">/etc/services</Literal> from a recent distribution.
</Para>
</Sect3>
</Sect2>
<Sect2>
<Title><Literal remap="tt">/etc/inetd.conf</Literal></Title>
<Para>
The <Literal remap="tt">/etc/inetd.conf</Literal> file is the configuration file for the
<Emphasis>inetd</Emphasis> server daemon. Its function is to tell <Emphasis>inetd</Emphasis> what to do
when it receives a connection request for a particular service. For each
service that you wish to accept connections, you must tell <Emphasis>inetd</Emphasis>
what network server daemon to run (and how to run it).
</Para>
<Para>
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 `<Literal remap="tt">&num;</Literal>'
is both ignored, and it is considered a comment. Each line contains seven fields separated
by any number of whitespace (tab or space) characters. The general format
is as follows:
</Para>
<Para>
<Screen>
service socket_type proto flags user server_path server_args
</Screen>
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>service</Term>
<ListItem>
<Para>
Is the service relevant to this
configuration as taken from the <Literal remap="tt">/etc/services</Literal>
file.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>socket&lowbar;type</Term>
<ListItem>
<Para>
This field describes the type of socket
that this entry will consider relevant. Allowable
values are: <Literal remap="tt">stream</Literal>, <Literal remap="tt">dgram</Literal>, <Literal remap="tt">raw</Literal>,
<Literal remap="tt">rdm</Literal>, or <Literal remap="tt">seqpacket</Literal>. This is a little
technical in nature. As a rule of thumb nearly all
<Literal remap="tt">tcp</Literal> based services use <Literal remap="tt">stream</Literal>, and nearly all
<Literal remap="tt">udp</Literal> based services use <Literal remap="tt">dgram</Literal>. It is only
very special types of server daemons that would use any of the other values.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>proto</Term>
<ListItem>
<Para>
The protocol to be considered valid for this
entry. This should match the appropriate entry in the
<Literal remap="tt">/etc/services</Literal> file. It will typically be
either <Literal remap="tt">tcp</Literal> or <Literal remap="tt">udp</Literal>. Sun RPC (Remote Procedure
Call) based servers will use either<Literal remap="tt">rpc/tcp</Literal> or
<Literal remap="tt">rpc/udp</Literal>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>flags</Term>
<ListItem>
<Para>
There are really only two possible settings
for this field. This field setting tells <Emphasis>inetd</Emphasis>
whether the network server program frees the socket
after it has been started (whether
<Emphasis>inetd</Emphasis> can start another one on the next
connection request), or, whether <Emphasis>inetd</Emphasis> should wait
and assume that any server daemon already running will
handle the new connection request. This is a
little tricky to work out, but as a rule of thumb all
<Literal remap="tt">tcp</Literal> servers should have this entry set to
<Literal remap="tt">nowait</Literal>. Most <Literal remap="tt">udp</Literal> servers should have this
entry set to <Literal remap="tt">wait</Literal>. Be warned there are some
notable exceptions. You should let the example guide you if you are not sure.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>user</Term>
<ListItem>
<Para>
This field describes which user account from
<Literal remap="tt">/etc/passwd</Literal> 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
<Literal remap="tt">nobody</Literal> user. If the network server
security is breached, the possible damage is minimized by using nobody.
Typically this field is set to <Literal remap="tt">root</Literal>,
because many servers require root privileges in order
to function correctly.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>server&lowbar;path</Term>
<ListItem>
<Para>
This field is pathname to the athoughctual
server program to execute for this entry.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>server&lowbar;args</Term>
<ListItem>
<Para>
This field comprises the rest of the
line and it 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.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Sect3>
<Title>An example <Literal remap="tt">/etc/inetd.conf</Literal></Title>
<Para>
As for the <Literal remap="tt">/etc/services</Literal> file all modern distributions will include
a good <Literal remap="tt">/etc/inetd.conf</Literal> file for you to work with. Here
is the <Literal remap="tt">/etc/inetd.conf</Literal> file from the
<ULink
URL="http://www.debian.org/">Debian</ULink> distribution.
</Para>
<Para>
<Screen>
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias &#60;tobias@et-inf.fho-emden.de&#62;
#
# &#60;service_name&#62; &#60;sock_type&#62; &#60;proto&#62; &#60;flags&#62; &#60;user&#62; &#60;server_path&#62; &#60;args&#62;
#
# 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
</Screen>
</Para>
</Sect3>
</Sect2>
</Sect1>
<Sect1>
<Title>Other miscellaneous network related configuration files.</Title>
<Para>
There are a number of miscellaneous files relating to network configuration
under linux that might be of interest. You may never have to modify
these files, but it is worth describing them so you know what they contain
and why they are used.
</Para>
<Sect2>
<Title><Literal remap="tt">/etc/protocols</Literal></Title>
<Para>
The <Literal remap="tt">/etc/protocols</Literal> 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. The file is also used by some programs
such as <Emphasis>tcpdump</Emphasis> to allow them to display names instead of numbers
in their output. The general syntax of the file is:
</Para>
<Para>
<Screen>
protocolname number aliases
</Screen>
</Para>
<Para>
The <Literal remap="tt">/etc/protocols</Literal> file supplied with the
<ULink
URL="http://www.debian.org/">Debian</ULink> distribution is as follows:
</Para>
<Para>
<Screen>
# /etc/protocols:
# $Id$
#
# 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 MessTransfernsport
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
</Screen>
</Para>
</Sect2>
<Sect2>
<Title><Literal remap="tt">/etc/networks</Literal></Title>
<Para>
The <Literal remap="tt">/etc/networks</Literal> file has a similar function to that of the
<Literal remap="tt">/etc/hosts</Literal> file.This file 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:
</Para>
<Para>
<Screen>
networkname networkaddress
</Screen>
</Para>
<Para>
An example might look like:
</Para>
<Para>
<Screen>
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
</Screen>
</Para>
<Para>
You will get a display of the network name (NOT its address) while using a command like <Emphasis>route
</Emphasis> in the following instance: the destination is a network, and that network has an entry in the <Literal remap="tt">/etc/networks
</Literal> file.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Network Security and access control.</Title>
<Para>
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. 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 security, including the <ULink
URL="Security-HOWTO.html">Security-HOWTO</ULink>
</Para>
<Para>
An important rule of thumb is:
`<Emphasis remap="bf">Don't run servers you don't intend to use</Emphasis>'.
Many distributions come configured with all sorts of services that are configured and
automatically started. To ensure even a minimum level of safety, you should go
through your <Literal remap="tt">/etc/inetd.conf</Literal> file. Comment out (<Emphasis>place a `&num;' at
the start of the line</Emphasis>) any entries for services you don't intend to use.
Good candidates are services such as: <Literal remap="tt">shell</Literal>, <Literal remap="tt">login</Literal>, <Literal remap="tt">exec</Literal>,
<Literal remap="tt">uucp</Literal>, <Literal remap="tt">ftp</Literal> and informational services such as <Literal remap="tt">finger</Literal>,
<Literal remap="tt">netstat</Literal> and <Literal remap="tt">systat</Literal>.
</Para>
<Para>
There are all sorts of security and access control mechanisms. I'll now describe
the most elementary:
</Para>
<Sect2>
<Title>/etc/ftpusers</Title>
<Para>
The <Literal remap="tt">/etc/ftpusers</Literal> file is a simple mechanism that allows you to
deny certain users from logging into your machine via ftp. When an incoming ftp connection is
received, the <Literal remap="tt">/etc/ftpusers</Literal> file is read by the ftp daemon program (<Emphasis>ftpd</Emphasis>).
The file is a simple list of those users who are not allowed login. It might look something like:
</Para>
<Para>
<Screen>
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
</Screen>
</Para>
</Sect2>
<Sect2>
<Title>/etc/securetty</Title>
<Para>
The <Literal remap="tt">/etc/securetty</Literal> file allows you to specify which <Literal remap="tt">tty</Literal> devices
<Literal remap="tt">root</Literal> are allowed for login. The <Literal remap="tt">/etc/securetty</Literal> file is read
by the login program (usually <Emphasis>/bin/login</Emphasis>). Its format is a list of
the tty devices names allowed: on all others <Literal remap="tt">root</Literal> login is disallowed:
</Para>
<Para>
<Screen>
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
</Screen>
</Para>
</Sect2>
<Sect2>
<Title>The <Emphasis>tcpd</Emphasis> hosts access control mechanism.</Title>
<Para>
The <Emphasis>tcpd</Emphasis> program listed in the samone
<Literal remap="tt">/etc/inetd.conf</Literal> provides logging and access control mechanisms to
services. It is configured to protect.
</Para>
<Para>
When it is invoked by the <Emphasis>inetd</Emphasis> program, it reads two files containing
access rules. It will then either alallow oreny access to the server it is protecting.
</Para>
<Para>
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: <Literal remap="tt">/etc/hosts.allow</Literal>, <Literal remap="tt">/etc/hosts.deny</Literal>.
I'll describe each of these in turn. For a complete description of this
facility, you should refer to the appropriate <Emphasis>man</Emphasis> pages
(<Literal remap="tt">hosts&lowbar;access(5)</Literal> is a good starting point).
</Para>
<Sect3>
<Title>/etc/hosts.allow</Title>
<Para>
The <Literal remap="tt">/etc/hosts.allow</Literal> file is a configuration file of the
<Emphasis>/usr/sbin/tcpd</Emphasis> program. The <Literal remap="tt">hosts.allow</Literal> file contains
rules describing which hosts are <Emphasis>allowed</Emphasis> access to a service on
your machine.
</Para>
<Para>
The file format is quite simple:
</Para>
<Para>
<Screen>
# /etc/hosts.allow
#
# &#60;service list&#62;: &#60;host list&#62; [: command]
</Screen>
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term><Literal remap="tt">service list</Literal> </Term>
<ListItem>
<Para>
This is a comma delimited list of
server names where this rule applies. Example
server names are: <Literal remap="tt">ftpd</Literal>, <Literal remap="tt">telnetd</Literal> and
<Literal remap="tt">fingerd</Literal>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal remap="tt">host list</Literal> </Term>
<ListItem>
<Para>
This is a comma delimited list of host
names. You may also use IP addresses here. You may
additionally specify either hostnames or addresses using
wildcard characters to match groups of hosts. Examples
include: <Literal remap="tt">gw.vk2ktj.ampr.org</Literal> to match a specific
host, <Literal remap="tt">.uts.edu.au</Literal> to match any hostname
ending in that string, <Literal remap="tt">44.</Literal> to match any IP
address commencing with those digits. There are some
special tokens to simplify configuration. Some of
these are: <Literal remap="tt">ALL</Literal> matches every host, <Literal remap="tt">LOCAL</Literal>
matches any host whose name does not contain a
`<Literal remap="tt">.</Literal>' ie is in the same domain as your machine and
<Literal remap="tt">PARANOID</Literal> matches any host whose name does not
match its address (name spoofing). There is one last
token that is also useful. The <Literal remap="tt">EXCEPT</Literal> token
allows you to provide a list with exceptions. This
will be covered in an example later.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term><Literal remap="tt">command</Literal> </Term>
<ListItem>
<Para>
This 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. It could also
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: <Literal remap="tt">&percnt;h</Literal> expands to
the name of the connecting host or address if it
doesn't have a name, <Literal remap="tt">&percnt;d</Literal> the daemon name being
called.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
An example:
</Para>
<Para>
<Screen>
# /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)
</Screen>
</Para>
</Sect3>
<Sect3>
<Title>/etc/hosts.deny</Title>
<Para>
The <Literal remap="tt">/etc/hosts.deny</Literal> file is a configuration file of the
<Emphasis>/usr/sbin/tcpd</Emphasis> program. The <Literal remap="tt">hosts.deny</Literal> file contains
rules describing which hosts are <Emphasis>disallowed</Emphasis> access to a service on
your machine.
</Para>
<Para>
A simple sample would look something like this:
</Para>
<Para>
<Screen>
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
</Screen>
</Para>
<Para>
The <Literal remap="tt">PARANOID</Literal> entry is redundant because the other entry traps
everything in any case. Either of these entries would make a reasonable default
(depending on your particular requirement).
</Para>
<Para>
Having an <Literal remap="tt">ALL: ALL</Literal> default in the <Literal remap="tt">/etc/hosts.deny</Literal> and then
specifically enabling on those services and hosts that you want in the
<Literal remap="tt">/etc/hosts.allow</Literal> file is the safest configuration.
</Para>
</Sect3>
</Sect2>
<Sect2>
<Title>/etc/hosts.equiv</Title>
<Para>
The <Literal remap="tt">hosts.equiv</Literal> file is used to grant certain hosts and users access
rights to accounts on your machine without having to supply a password. This
is useful in a secure environment where you control all machines, but is otherwise a
security hazard . Your machine is only as secure as the least secure
of the trusted hosts. To maximize security, don't use this mechanism.
Encourage your users not to use the <Literal remap="tt">.rhosts</Literal> file as well.
</Para>
</Sect2>
<Sect2>
<Title>Configure your <Emphasis>ftp</Emphasis> daemon properly.</Title>
<Para>
Many sites will be interested in running an anonymous <Emphasis>ftp</Emphasis> server to
allow other people to upload and download files without requiring a specific
userid. If you decide to offer this facility, make sure you configure the
<Emphasis>ftp</Emphasis> daemon properly for anonymous access. Most <Emphasis>man</Emphasis> pages for
<Literal remap="tt">ftpd(8)</Literal> describe in some length the proper procedures. You should
always ensure that you follow these instructions. An important tip is to
not use a copy of your <Literal remap="tt">/etc/passwd</Literal> file in the anonymous account
<Literal remap="tt">/etc</Literal> 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.
</Para>
</Sect2>
<Sect2>
<Title>Network Firewalling.</Title>
<Para>
Not allowing datagrams to even reach your machine (or servers) is an
excellent means of security. This is covered in depth in the <ULink
URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall-HOWTO</ULink>, and (more concisely)
in a later section of this document.
</Para>
</Sect2>
<Sect2>
<Title>Other suggestions.</Title>
<Para>
Here are some other (potentially religious) suggestions for you to consider:
</Para>
<Para>
<VariableList>
<VarListEntry>
<Term>sendmail</Term>
<ListItem>
<Para>
Despite its popularity, the <Emphasis>sendmail</Emphasis>
daemon appears with frightening regularity on security
warning announcements. My recommendation is not
to run it.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>NFS and other Sun RPC services</Term>
<ListItem>
<Para>
Be wary of these services. There are all sorts of possible exploits for
them. It is difficult finding an option to
services like NFS. If you configure them, make
sure you are careful to whom you allow mount rights.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
</Sect2>
</Sect1>
</Chapter>
<Chapter>
<Title>Ethernet Information</Title>
<Para>
This section covers information specific to Ethernet, and it also covers
the configuring of Ethernet Cards.
</Para>
<Sect1>
<Title>Supported Ethernet Cards</Title>
<Sect2>
<Title>3Com</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
3Com 3c501 - `Avoid like the plague!'' (3c501 driver)
</Para>
</ListItem>
<ListItem>
<Para>
3Com 3c503 (3c503 driver), 3c505 (3c505 driver), 3c507 (3c507 driver), 3c509/3c509B (ISA) / 3c579
(EISA)
</Para>
</ListItem>
<ListItem>
<Para>
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)
</Para>
</ListItem>
<ListItem>
<Para>
3Com 3ccfe575 Cyclone Cardbus (3c59x driver)
</Para>
</ListItem>
<ListItem>
<Para>
3Com 3c575 series Cardbus (3c59x driver) (ALL PCMCIA ??)
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>AMD, ATT, Allied Telesis, Ansel, Apricot</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
AMD LANCE (79C960) / PCnet-ISA/PCI (AT1500, HP J2405A,
NE1500/NE2100)
</Para>
</ListItem>
<ListItem>
<Para>
ATT GIS WaveLAN
</Para>
</ListItem>
<ListItem>
<Para>
Allied Telesis AT1700
</Para>
</ListItem>
<ListItem>
<Para>
Allied Telesis LA100PCI-T
</Para>
</ListItem>
<ListItem>
<Para>
Allied Telesyn AT2400T/BT ("ne" module)
</Para>
</ListItem>
<ListItem>
<Para>
Ansel Communications AC3200 (EISA)
</Para>
</ListItem>
<ListItem>
<Para>
Apricot Xen-II / 82596
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>Cabletron, Cogent, Crystal Lan</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Cabletron E21xx
</Para>
</ListItem>
<ListItem>
<Para>
Cogent EM110
</Para>
</ListItem>
<ListItem>
<Para>
Crystal Lan CS8920, Cs8900
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>Danpex, DEC, Digi, DLink</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Danpex EN-9400
</Para>
</ListItem>
<ListItem>
<Para>
DEC DE425 (EISA) / DE434/DE435 (PCI) / DE450/DE500 (DE4x5 driver)
</Para>
</ListItem>
<ListItem>
<Para>
DEC DE450/DE500-XA (dc21x4x) (Tulip driver)
</Para>
</ListItem>
<ListItem>
<Para>
DEC DEPCA and EtherWORKS
</Para>
</ListItem>
<ListItem>
<Para>
DEC EtherWORKS 3 (DE203, DE204, DE205)
</Para>
</ListItem>
<ListItem>
<Para>
DECchip DC21x4x "Tulip"
</Para>
</ListItem>
<ListItem>
<Para>
DEC QSilver's (Tulip driver)
</Para>
</ListItem>
<ListItem>
<Para>
Digi International RightSwitch
</Para>
</ListItem>
<ListItem>
<Para>
DLink DE-220P, DE-528CT, DE-530+, DFE-500TX, DFE-530TX
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>Fujitsu, HP, ICL, Intel</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Fujitsu FMV-181/182/183/184
</Para>
</ListItem>
<ListItem>
<Para>
HP PCLAN (27245 and 27xxx series)
</Para>
</ListItem>
<ListItem>
<Para>
HP PCLAN PLUS (27247B and 27252A)
</Para>
</ListItem>
<ListItem>
<Para>
HP 10/100VG PCLAN (J2577, J2573, 27248B, J2585) (ISA/EISA/PCI)
</Para>
</ListItem>
<ListItem>
<Para>
ICL EtherTeam 16i / 32 (EISA)
</Para>
</ListItem>
<ListItem>
<Para>
Intel EtherExpress
</Para>
</ListItem>
<ListItem>
<Para>
Intel EtherExpress Pro
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>KTI, Macromate, NCR NE2000/1000, Netgear, New Media</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
KTI ET16/P-D2, ET16/P-DC ISA (work jumperless andjumper lessware-configuration options)
</Para>
</ListItem>
<ListItem>
<Para>
Macromate MN-220P (PnP or NE2000 mode)
</Para>
</ListItem>
<ListItem>
<Para>
NCR WaveLAN
</Para>
</ListItem>
<ListItem>
<Para>
NE2000/NE1000 (be careful with clones)
</Para>
</ListItem>
<ListItem>
<Para>
Netgear FA-310TX (Tulip chip)
</Para>
</ListItem>
<ListItem>
<Para>
New Media Ethernet
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>PureData, SEEQ, SMC</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
PureData PDUC8028, PDI8023
</Para>
</ListItem>
<ListItem>
<Para>
SEEQ 8005
</Para>
</ListItem>
<ListItem>
<Para>
SMC Ultra / EtherEZ (ISA)
</Para>
</ListItem>
<ListItem>
<Para>
SMC 9000 series
</Para>
</ListItem>
<ListItem>
<Para>
SMC PCI EtherPower 10/100 (DEC Tulip driver)
</Para>
</ListItem>
<ListItem>
<Para>
SMC EtherPower II (epic100.c driver)
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>Sun Lance, Sun Intel, Schneider, WD, Zenith, IBM, Enyx</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
Sun LANCE adapters (kernel 2.2 and newer)
</Para>
</ListItem>
<ListItem>
<Para>
Sun Intel adapters (kernel 2.2 and newer)
</Para>
</ListItem>
<ListItem>
<Para>
Schneider and Koch G16
</Para>
</ListItem>
<ListItem>
<Para>
Western Digital WD80x3
</Para>
</ListItem>
<ListItem>
<Para>
Zenith Z-Note / IBM ThinkPad 300 built-in adapter
</Para>
</ListItem>
<ListItem>
<Para>
Znyx 312 etherarray (Tulip driver)
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>General Ethernet Information</Title>
<Para>
Ethernet devices names are `<Literal remap="tt">eth0</Literal>', `<Literal remap="tt">eth1</Literal>', `<Literal remap="tt">eth2</Literal>' etc. The first
card detected by the kernel is assigned `<Literal remap="tt">eth0</Literal>', and the rest are assigned
sequentially in the order in which they are detected.
</Para>
<Para>
Once you have your kernel properly built to support your ethernet card,
configuration of the card is easy.
</Para>
<Para>
Typically you would use something like (which most distributions already
do for you, if you configured them to support your ethernet):
</Para>
<Para>
<Screen>
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
</Screen>
</Para>
<Para>
Most of the ethernet drivers were developed by
<ULink
URL="mailto:becker@CESDIS.gsfc.nasa.gov">Donald Becker</ULink>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Using 2 or more Ethernet Cards in the same machine</Title>
<Sect2>
<Title>If your driver is a module (Normal with newer distros)</Title>
<Para>
The module will typically can detect all of the installed cards.
</Para>
<Para>
Information from the detection is stored in the file:
</Para>
<Para>
<Emphasis>/etc/conf.modules. </Emphasis>
</Para>
<Para>
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:
</Para>
<Para>
<Screen>
alias eth0 ne
alias eth1 ne
alias eth2 ne
options ne io=0x220,0x240,0x300
</Screen>
</Para>
<Para>
What this does is tell the program <Emphasis>modprobe</Emphasis> 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.
</Para>
<Para>
Most ISA modules can take multiple comma separated I/O values.
For example:
</Para>
<Para>
<Screen>
alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7
</Screen>
</Para>
<Para>
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.
</Para>
<Para>
The irq= option is used to specify the hardware IRQ, and the io= to specify
the different io ports.
</Para>
<Para>
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.
</Para>
<Para>
To learn how furthere your ethernet card(s) work under Linux, you
should refer to the <ULink
URL="Ethernet-HOWTO.html">Ethernet-HOWTO</ULink>.
</Para>
</Sect2>
</Sect1>
</Chapter>
<Chapter>
<Title>IP Related Information</Title>
<Para>
This section covers information specific to IP.
</Para>
<Sect1>
<Title>Kernel Level Options</Title>
<Para>
This section includes information on setting IP options within the kernel at
boot time. An example of these options are <COMMAND>ip_forward</COMMAND> or
<COMMAND>ip_bootp_agent</COMMAND>. These options are used by setting the value
to a file in the <Screen>/proc/sys/net/ipv4/</Screen> directory. The name of the
file is the name of the command.
</Para>
<Para>
For example, to set <Command>ip_forward</Command> <Command>enabled</Command>, you
would type <screen>echo 1 > /proc/sys/net/ipv4/ip_forward</screen>
</Para>
<Sect2><Title>General IP option listing</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
<Command>ip_forward</Command>
</Para>
<Para>
If <command>ip_forward</command><INDEXTERM><PRIMARY>ip_foward</PRIMARY></INDEXTERM>
is set to 0 it is disabled. If it is sforwardany other number it is enabled. This option is used in conjunction with technologies such
as routing between interfaces with IP Masquerading.
<INDEXTERM><PRIMARY>IP Masquerading</PRIMARY></INDEXTERM>.
</Para>
</ListItem>
<ListItem>
<Para>
<command>ip_default_ttl</command>
</Para>
<Para>
This is the time to live for an IP Packet. The default is 64 milliseconds.
</Para>
</ListItem>
<ListItem>
<Para>
<COMMAND>ip_addrmask_agent</COMMAND> - BOOLEAN
</Para>
<Para>
Reply to ICMP ADDRESS MASK requests.
default TRUE (router)
FALSE (host)
</Para>
</ListItem>
<ListItem>
<Para>
<COMMAND>ip_bootp_agent</COMMAND>
</Para>
<Para> - BOOLEAN
Accept packets with source address of sort 0.b.c.d
and destined to this host, broadcast or multicast.
Such packets are silently ignored otherwise.
default FALSE
</Para>
</ListItem>
<ListItem>
<Para>
<Command>ip_no_pmtu_disc</Command>
</ParA>
<Para> - BOOLEAN
Disable Path MTU Discovery.
default FALSE
</Para>
</ListItem>
<ListItem>
<Para>
<command>ip_fib_model</command> - INTEGER
</Para>
<Para>
0 - (DEFAULT) Standard model. All routes are in class MAIN.
1 - default routes go to class DEFAULT. This mode should
be very convenient for small ISPs making policy routing.
2 - RFC1812 compliant model.
Interface routes are in class MAIN.
Gateway routes are in class DEFAULT.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>EQL - multiple line traffic equaliser</Title>
<Para>
The EQL device name is `<Literal remap="ttequalizerteral">eql</Literal>'.
With the standard kernel source, you may have
only one EQL device per machine. EQL provides a means of utilizing multiple
Point-to-Point lines such as PPP, slip, or plip as a single logical link to
carry tcp/ip. Often it is cheaper to use multiple lower speed lines than to
have one high speed line installed.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
&#60;*&#62; EQL (serial line load balancing) support
</Screen>
</Para>
<Para>
To support this mechanism, the machine at the other end of the lines must also
support EQL. Linux, Livingstone Portmasters and newer dial-in servers support
compatible facilities.
</Para>
<Para>
To configure EQL you will need the eql tools which are available from:
<ULink
URL="ftp://metalab.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz">metalab.unc.edu</ULink>.
</Para>
<Para>
Configuration is fairly straightforward. You start by configuring the eql
interface. The eql interface is just like any other network device. You
configure the IP address and mtu using the <Emphasis>ifconfig</Emphasis> utility. Here
is an example:
</Para>
<Para>
<Screen>
root# ifconfig eql 192.168.10.1 mtu 1006
</Screen>
</Para>
<Para>
Next, you need to manually initiate each of the lines you will use. These may
be any combination of Point-to-Point network devices. How you initiate the
connections will depend on what sort of link they are. Refer to the
appropriate sections for further information.
</Para>
<Para>
Lastly you need to associate the serial link with the EQL device. This is
called `enslaving' : it is done with the <Emphasis>eql&lowbar;enslave</Emphasis> command as shown:
</Para>
<Para>
<Screen>
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
</Screen>
</Para>
<Para>
The `<Emphasis>estimated speed</Emphasis>' parameter you supply <Emphasis>eql&lowbar;enslave</Emphasis>
doesn't do anything directly. It is used by the EQL driver to determine what share of
the datagrams that device should receive. You can then fine tune the balancing of
the lines by playing with this value.
</Para>
<Para>
To disassociate a line from an EQL device, use the <Emphasis>eql&lowbar;emancipate</Emphasis>
command as shown:
</Para>
<Para>
<Screen>
root# eql_emancipate eql sl0
</Screen>
</Para>
<Para>
You add routing as you would for any other Point-to-Point link, except that your
routes should refer to the <Literal remap="tt">eql</Literal> device rather than the actual serial
devices. You would typically use:
</Para>
<Para>
<Screen>
root# route addthemselveseql
</Screen>
</Para>
<Para>
The EQL driver was developed by Simon Janes <Literal remap="tt">simon@ncm.com</Literal>.
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>IP Accounting (for Linux-2.0)</Title>
<Para>
The IP accounting features of the Linux kernel allow you to collect and
analyze some network usage data. The data collected comprises the number
of packets and the number of bytes accumulated since the figures were
last reset. You may specify a variety of rules to categorize the
figures to suit your purpose. This option has been
removed in kernel 2.1.102 because the old ipfwadm-based firewalling
was replaced by ``ipfwchains''.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] IP: accounting
</Screen>
</Para>
<Para>
After you have compiled and installed the kernel, you need to use the
<Emphasis>ipfwadm</Emphasis> command to configure IP accounting. There are many different
ways of breaking down the accounting information.
I've picked a simple example of what might be useful. You should
read the <Emphasis>ipfwadm</Emphasis> man page for more information.
</Para>
<Para>
Scenario: You have a ethernet network that is linked to the Internet via
a PPP link. On the ethernet, you have a machine that offers a number of
services. You are interested in knowing how much traffic is generated
by each of ftp (and world wide web traffic), as well as total tcp and udp
traffic.
</Para>
<Para>
You might use a command set that looks like the following (shown as a
shell script):
</Para>
<Para>
<Screen>
#!/bin/sh
#
# Flush the accounting rules
ipfwadm -A -f
#
# Set shortcuts
localnet=44.136.8.96/29
any=0/0
# Add rules for local ethernet segment
ipfwadm -A in -a -P tcp -D $localnet ftp-data
ipfwadm -A out -a -P tcp -S $localnet ftp-data
ipfwadm -A in -a -P tcp -D $localnet www
ipfwadm -A out -a -P tcp -S $localnet www
ipfwadm -A in -a -P tcp -D $localnet
ipfwadm -A out -a -P tcp -S $localnet
ipfwadm -A in -a -P udp -D $localnet
ipfwadm -A out -a -P udp -S $localnet
#
# Rules for default
ipfwadm -A in -a -P tcp -D $any ftp-data
ipfwadm -A out -a -P tcp -S $any ftp-data
ipfwadm -A in -a -P tcp -D $any www
ipfwadm -A out -a -P tcp -S $any www
ipfwadm -A in -a -P tcp -D $any
ipfwadm -A out -a -P tcp -S $any
ipfwadm -A in -a -P udp -D $any
ipfwadm -A out -a -P udp -S $any
#
# List the rules
ipfwadm -A -l -n
#
</Screen>
</Para>
<Para>
The names ``ftp-data'' and ``www'' refer to lines in
<Literal remap="tt">/etc/services</Literal>. The last command lists each of the Accounting
rules and displays the collected totals.
</Para>
<Para>
An important point to note when analyzing IP accounting is that
<Emphasis>totals for all rules that match will be incremented</Emphasis>. To
obtain differential figures, you need to perform appropriate maths. For
example, if I wanted to know how much data was not ftp or www, I would
subtract the individual totals from the rule that matches all ports.
</Para>
<Para>
<Screen>
root# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -&#62; 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -&#62; *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -&#62; 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -&#62; *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -&#62; *
231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -&#62; *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -&#62; *
0 0 out undp 44.136.8.96/29 0.0.0.0/0 * -&#62; *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -&#62; 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -&#62; *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -&#62; 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -&#62; *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -&#62; *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -&#62; *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -&#62; *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -&#62; *
</Screen>
</Para>
<Sect2>
<Title>IP Accounting (for Linux-2.2)</Title>
<Para>
The new accounting code is accessed via ``IP Firewall Chains''.
See <ULink
URL="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html">the IP chains home page</ULink> for more information.
You'll now need to use <Emphasis>ipchains</Emphasis> instead of <Literal remap="tt">ipfwadm</Literal>
to configure your filters. (From <Literal remap="tt">Documentation/Changes</Literal> in the
latest kernel sources).
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>IP Aliasing</Title>
<Para>
There are some applications where being able to configure multiple
IP addresses to a single network device is useful. Internet Service
Providers often use this facility to provide a "customized" feature to their
World Wide Web and ftp offerings for their customers. You can refer to
the ``IP-Alias mini-HOWTO'' for more information.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
....
[*] Network aliasing
....
&#60;*&#62; IP: aliasing support
</Screen>
</Para>
<Para>
After compiling and installing your kernel with IP&lowbar;Alias support,
configuration is very simple. The aliases are added to virtual network
devices associated with the actual network device. A simple naming
convention applies to these devices being <Literal remap="tt">&lt;devname&#62;:&lt;virtual
dev num&#62;</Literal>, e.g. <Literal remap="tt">eth0:0</Literal>, <Literal remap="tt">ppp0:10</Literal> etc. Note that the
ifname:number device can only be configured <Emphasis>after</Emphasis> the main
interface has been set up.
</Para>
<Para>
For example, assume you have an ethernet network that supports two different
IP subnetworks simultaneously. You also wish your machine to have direct access
to both. You could use something like:
</Para>
<Para>
<Screen>
root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
</Screen>
</Para>
<Para>
To delete an alias, add a `<Literal remap="tt">-</Literal>' to the end of its name, then
refer to it. It is as simple as:
</Para>
<Para>
<Screen>
root# ifconfig eth0:0- 0
</Screen>
</Para>
<Para>
All routes associated with that alias will also be deleted automatically.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>IP Firewall (for Linux-2.0)</Title>
<Para>
IP Firewall and Firewalling issues are covered in more depth in the
<ULink
URL="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html">Firewall-HOWTO</ULink>. IP Firewalling allows
you to secure your machine against unauthorized network access by filtering
or allowing datagrams from or to IP addresses that you nominate. There are
three different classes of rules; incoming filtering, outgoing filtering, and
forwarding filtering. Incoming rules are applied to datagrams that are
received by a network device. Outgoing rules are applied to datagrams that
are to be transmitted by a network device. Forwarding rules are applied to
datagrams that are received and are not for this machine (ie. datagrams that
would be routed).
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
</Screen>
</Para>
<Para>
Configuration of the IP firewall rules is performed using the <Emphasis>ipfwadm</Emphasis>
command. As I mentioned earlier, I am not a security expert.
I will present an example you can use. You should, however, do your own
research and develop your own rules.
</Para>
<Para>
Using your linux machine as a router and firewall gateway to protect your local
network from unauthorized access (from outside your network) is probably the most
common use of an IP firewall.
</Para>
<Para>
The following configuration is based on a contribution from Arnt Gulbrandsen:
<Literal remap="tt">&lt;agulbra@troll.no&gt;</Literal>.
</Para>
<Para>
The example describes the configuration of the firewall rules on the Linux
firewall/router machine illustrated below:
</Para>
<Para>
<Screen>
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
</Screen>
</Para>
<Para>
The following commands would normally be placed in an <Literal remap="tt">rc</Literal> file.
They would be automatically started each time the system
boots. For maximum security, they would be performed after the network
interfaces are configured (but before the interfaces are actually
brought up) to prevent anyone gaining access while the firewall machine
is rebooting.
</Para>
<Para>
<Screen>
#!/bin/sh
# Flush the 'Forwarding' rules table
# Change the default policy to 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. and for 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept
# First off, seal off the PPP interface
# I'd love to use '-a deny' instead of '-a reject -y' but then it
# would be impossible to originate connections on that interface too.
# The -o causes all rejected datagrams to be logged. This trades
# disk space against knowledge of an attack of configuration error.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30
# Throw away certain kinds of obviously forged packets right away:
# Nothing should come from multicast/anycast/broadcast addresses
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# and nothing coming from the loopback network should ever be
# seen on a wire
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
# accept incoming SMTP and DNS connections, but only
# to the Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS uses UDP as well as TCP, so allow that too
# for questions to our name server
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# but not "answers" coming to dangerous ports like NFS and
# Larry McVoy's NFS extension. If you run squid, add its port here.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050
# answers to other user ports are okay
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
-D 172.16.37.0/24 53 1024:65535
# Reject incoming connections to identd
# We use 'reject' here so that the connecting host is told
# straight away not to bother continuing, otherwise we'd experience
# delays while ident timed out.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113
# Accept some common service connections from the 192.168.64 and
# 192.168.65 networks, they are friends that we trust.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
-D 172.16.37.0/24 20:23
# accept and pass through anything originating inside
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
# deny most other incoming TCP connections and log them
# (append 1:1023 if you have problems with ftp not working)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24
# ... for UDP too
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
</Screen>
</Para>
<Para>
Good firewall configurations are a little tricky. This example
should be a reasonable starting point for you. The <Emphasis>ipfwadm</Emphasis>
manual page offers some assistance in how to use the tool. If
you intend to configure a firewall, be sure to ask around and
get as much advice from sources you consider reliable. Get
someone to test/sanity check your configuration from the outside.
</Para>
<Sect2>
<Title>IP Firewall (for Linux-2.2)</Title>
<Para>
The new firewalling code is accessed via ``IP Firewall Chains''.
See <ULink
URL="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html">the IP chanins home page</ULink> for more information. Among other
things, you'll now need to use <Emphasis>ipchains</Emphasis> instead of <Literal remap="tt">ipfwadm</Literal>
to configure your filters (From <Literal remap="tt">Documentation/Changes</Literal> in the
latest kernel sources).
</Para>
<Para>
We are aware that this is a sorely out of date statement. We are
currently working on getting this section current. You can expect a
newer version sometime this year.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>IPIP Encapsulation</Title>
<Para>
Why would you want to encapsulate IP datagrams within IP datagrams? It must
seem odd if you've never seen a working application.
Two common places where it is used are in Mobile-IP and
IP-Multicast. Amateur Radio is perhaps the most widely spread (and least known) useage.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
&#60;*&#62; IP: tunneling
</Screen>
</Para>
<Para>
IP tunnel devices are called `<Literal remap="tt">tunl0</Literal>', `<Literal remap="tt">tunl1</Literal>' etc.
</Para>
<Para>
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP network
comprises a network address and a network mask. This produces a series of
contiguous addresses that may all be routed via a single routing entry.
This is very convenient. It means that you may use any particular
IP address while you are connected to its piece of the network.
In most instances this is ok. If you are a mobile netizen, however, then
you may not be able to stay connected to the one place all the time. IP/IP
encapsulation (IP tunneling) allows you to overcome this restriction by
allowing datagrams destined for your IP address to be wrapped up and redirected
to another IP address. If you know that you're going to be operating from another
IP network, you can set up a machine on your home network
to accept datagrams to your IP address. You can then redirect these datagrams to the address
that you will be temporarily using.
</Para>
<Sect2>
<Title>A tunneled network configuration.</Title>
<Para>
<Screen>
192.168.1/24 192.168.2/24
- -
| ppp0 = ppp0 = |
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii |
| |
| /-----\ /-----\ |
| | | // | | |
|---| A |------//---------| B |---|
| | | // | | |
| \-----/ \-----/ |
| |
- -
</Screen>
</Para>
<Para>
The diagram illustrates another possible reason to use IPIP encapsulation;
virtual private networking. This example presupposes that you have two machines,
each with a simple dial up Internet connection. Each host is allocated just
a single IP address. Behind each of these machines are some private local area
networks. These LANs are configured with reserved IP network addresses. Suppose that you want
to allow any host on network A to connect to any host on network B (just as
if they were properly connected to the Internet with a network route). IPIP
encapsulation will allow you to do this configuration. Note: encapsulation does not solve
the problem of how you get the hosts on networks A and B to talk to any
other on the Internet. You will still need to use tricks like IP Masquerade.
Encapsulation is normally performed by machines functioning as routers.
</Para>
<Para>
Linux router `<Literal remap="tt">A</Literal>' would be configured with a script like the following:
</Para>
<Para>
<Screen>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
</Screen>
</Para>
<Para>
Linux router `<Literal remap="tt">B</Literal>' would be configured with a similar script:
</Para>
<Para>
<Screen>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# Ethernet configuration
ifconfig eth0 192.168.2.1 netmask $mask up
route add -net 192.168.2.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.2.1 up
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
</Screen>
</Para>
<Para>
The command:
</Para>
<Para>
<Screen>
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
</Screen>
</Para>
<Para>
reads: `Send any datagrams destined for <Literal remap="tt">192.168.1.0/24</Literal> inside an
IPIP encap datagram with a destination address of <Literal remap="tt">aaa.bbb.ccc.ddd</Literal>'.
</Para>
<Para>
Note that the configurations are reciprocated at either end. The tunnel device
uses the `<Literal remap="tt">gw</Literal>' in the route as the <Emphasis>destination</Emphasis> of the IP datagram
(where it will place the datagram it has received to route). That machine
must know how to decapsulate IPIP datagrams. In other words, it must also be
configured with a tunnel device.
</Para>
</Sect2>
<Sect2>
<Title>A tunneled host configuration.</Title>
<Para>
You do not have to be routing a whole network. You could, for example, route
just a single IP address. In that instance you might configure the <Literal remap="tt">tunl</Literal>
device on the `remote' machine with its home IP address. At the A end would have
a host route (and Proxy Arp) rather than a network route via the tunnel
device. Let's redraw and modify our configuration appropriately. Now we
have just host `<Literal remap="tt">B</Literal>' which you want to act and behave as if it is both
fully connected to the Internet, and also part of the remote network supported
by host `<Literal remap="tt">A</Literal>':
</Para>
<Para>
<Screen>
192.168.1/24
-
| ppp0 = ppp0 =
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii
|
| /-----\ /-----\
| | | // | |
|---| A |------//---------| B |
| | | // | |
| \-----/ \-----/
| also: 192.168.1.12
-
</Screen>
</Para>
<Para>
Linux router `<Literal remap="tt">A</Literal>' would be configured with:
</Para>
<Para>
<Screen>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -host 192.168.1.12 gw $remotegw tunl0
#
# Proxy ARP for the remote host
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
</Screen>
</Para>
<Para>
Linux host `<Literal remap="tt">B</Literal>' would be configured with:
</Para>
<Para>
<Screen>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.12 up
route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0
</Screen>
</Para>
<Para>
This sort of configuration is more typical of a Mobile-IP application: a single host
wants to roam around the Internet and maintain a single usable
IP address the whole time. You should refer to the Mobile-IP section for more
information on how this is handled in practice.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>IP Masquerade</Title>
<Para>
Many people have a simple dialup account to connect to the Internet. Nearly
everybody using this sort of configuration is allocated a single IP address
by the Internet Service Provider. This is normally enough to allow only one
host full access to the network. IP Masquerade is a clever trick that enables
you to have many machines make use of that one IP address. It causes the
other hosts to look like the machine supporting the dial-up connection. This is
where the term masquerade applies. There is a small caveat: the
masquerade function usually works only in one direction. That is, the
masqueraded hosts can make calls out, but they cannot accept or receive
network connections from remote hosts. This means that some network services
do not work (such as <Emphasis>talk</Emphasis>), and others (such as
<Emphasis>ftp</Emphasis>) must be configured
in passive (PASV) mode to operate. Fortunately, the most common network services such as
<Emphasis>telnet</Emphasis>, World Wide Web and <Emphasis>irc</Emphasis>
work just fine.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Code maturity level options ---&#62;
[*] Prompt for development and/or incomplete code/drivers
Networking options ---&#62;
[*] Network firewalls
....
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
[*] IP: masquerading (EXPERIMENTAL)
</Screen>
</Para>
<Para>
Normally, you have your linux machine supporting a SLIP or PPP dial-up line
(just as it would if it were a standalone machine). Additionally, it would have
another network device configured (perhaps an ethernet) with one
of the reserved network addresses. The hosts to be masqueraded would be on
this second network. Each of these hosts would have the IP address of the
ethernet port of the linux machine set as their default gateway or router.
</Para>
<Para>
A typical configuration might look something like this:
</Para>
<Para>
<Screen>
- -
\ | 192.168.1.0
\ | /255.255.255.0
\ --------- |
| | Linux | .1.1 |
NET =================| masq |------|
| PPP/slip | router| | --------
/ --------- |--| host |
/ | | |
/ | --------
- -
</Screen>
</Para>
<Sect2>
<Title>Masquerading with IPFWADM (Kernels 2.0.x)</Title>
<Para>
The most relevant commands for this configuration are:
</Para>
<Para>
<Screen>
# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the Internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
</Screen>
</Para>
</Sect2>
<Sect2>
<Title>Masquerading with IPCHAINS</Title>
<Para>
This is similar to using IPFWADM, but the command structure has changed:
</Para>
<Para>
<Screen>
# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the Internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipchains -A forward -s 192.168.1.0/24 -j MASQ
</Screen>
</Para>
<Para>
You can get more information on the Linux IP Masquerade feature from the
<ULink URL="http://ipmasq.cjb.net/">IP Masquerade Resource Page</ULink>. Also, a <Emphasis>very</Emphasis>
detailed document about masquerading is the ``IP-Masquerade mini-HOWTO''
(which also intructs to configure other OS's to run with a Linux
masquerade server).
</Para>
<Para>
For information on Applications of IP Masquerading, check the
<ULink URL="http://www.tsmservices.com/masq/">IPMASQ Applications</ULink> page.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>IP Transparent Proxy</Title>
<Para>
IP transparent proxy is a feature that enables you to redirect servers or
services destined for another machine to those services on this machine.
Typically, this would be useful where you have a linux machine as a router
(and also provides a proxy server). You would redirect all connections destined
for that service remotely to the local proxy server.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Code maturity level options ---&#62;
[*] Prompt for development and/or incomplete code/drivers
Networking options ---&#62;
[*] Network firewalls
....
[*] TCP/IP networking
....
[*] IP: firewalling
....
[*] IP: transparent proxy support (EXPERIMENTAL)
</Screen>
</Para>
<Para>
Configuration of the transparent proxy feature is performed using the
<Emphasis>ipfwadm</Emphasis> command.
</Para>
<Para>
An example that might be useful is as follows:
</Para>
<Para>
<Screen>
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
</Screen>
</Para>
<Para>
This example will cause any connection attempts to port <Literal remap="tt">telnet</Literal>
(23) on any host to be redirected to port 2323 on this host. If you
run a service on that port, you could forward telnet connections, log
them, or do whatever fits your needs.
</Para>
<Para>
A more interesting example is redirecting all <Literal remap="tt">http</Literal> traffic
through a local cache. However, the protocol used by proxy servers is
different from native http: (where a client connects to
<Literal remap="tt">www.server.com:80</Literal> and asks for <Literal remap="tt">/path/page</Literal>). When it
connects to the local cache, it contacts <Literal remap="tt">proxy.local.domain:8080</Literal>
and asks for <Literal remap="tt">www.server.com/path/page</Literal>.
</Para>
<Para>
To filter an <Literal remap="tt">http</Literal> request through the local proxy, you need to
adapt the protocol by inserting a small server, called
<Literal remap="tt">transproxy</Literal> (you can find it on the world wide web). You can choose
to run <Literal remap="tt">transproxy</Literal> on port 8081.Just ssue this command:
</Para>
<Para>
<Screen>
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
</Screen>
</Para>
<Para>
The <Literal remap="tt">transproxy</Literal> program, then, will receive all connections meant
to reach external servers, and will pass them to the local proxy (after fixing protocol differences).
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>IPv6</Title>
<Para>
Just when you thought you were beginning to understand IP networking, the
rules get changed! IPv6 is the shorthand notation for version 6 of the Internet
Protocol. IPv6 was developed primarily to overcome the concerns in the Internet
community. Users worried that there would soon be a shortage of IP addresses to allocate. IPv6
addresses are 16 bytes long (128 bits). IPv6 incorporates a number of other
changes, mostly simplifications, that will make IPv6 networks more managable
than IPv4 networks.
</Para>
<Para>
Linux already has a working (but not complete) IPv6 implementation in
the <Literal remap="tt">2.2.*</Literal> series kernels.
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<sect1><Title>IPv6 Linux resources</Title>
<Para>
<Ulink URL="http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO.html">IPv6-HOWTO</Ulink>
</Para>
<Para>
<Ulink URL="http://www.xelia.ch/Linux/IPng.html">
IPv6 for Linux</Ulink>
</Para>
<Para>
<Ulink URL="http://v6rpm.jindai.net/">
Linux IPv6 RPM Project</Ulink>
</Para>
<Para>
<Ulink URL="http://www.linuxhq.com/IPv6/linux-ipv6.faq.html">IPv6 FAQ/HOWTO</Ulink>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Mobile IP</Title>
<Para>
The term "IP mobility" describes the ability of a host that is able to
move its network connection from one point on the Internet to another (without
changing its IP address or losing connectivity). Usually when an IP host
changes its point of connectivity, it must also change its IP address.
IP Mobility overcomes this problem by allocating a fixed IP address to the
mobile host. It also uses IP encapsulation (tunneling) with automatic routing
to ensure that datagrams destined for it are routed to the actual IP address
it is currently using.
</Para>
<Para>
A project is underway to provide a complete set of IP mobility tools for Linux.
The status of the project and tools may be obtained from:
<ULink
URL="http://anchor.cs.binghamton.edu/~mobileip/">Linux Mobile IP Home Page</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Multicast</Title>
<Para>
IP Multicast allows an arbitrary number of IP hosts on disparate IP networks
to have IP datagrams simultaneously routed to them. This mechanism is exploited
to provide Internet wide "broadcast" material, such as audio and video
transmissions, as well as other novel applications.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] TCP/IP networking
....
[*] IP: multicasting
</Screen>
</Para>
<Para>
A suite of tools and some minor network configuration is required.
Please check the <ULink
URL="Multicast-HOWTO.html">Multicast-HOWTO</ULink>
for more information on Multicast support in Linux.
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Traffic Shaper - Changing allowed bandwidth</Title>
<Para>
The traffic shaper is a driver that creates new interface devices.
Those devices are traffic-limited in a user-defined way. They rely
on physical network devices for actual transmission, and they can be used as
outgoing routed for network traffic.
</Para>
<Para>
The shaper was introduced in Linux-2.1.15, and it was backported to
Linux-2.0.36 (it appeared in <Literal remap="tt">2.0.36-pre-patch-2</Literal> distributed by Alan
Cox, the author of the shaper device and maintainer of Linux-2.0).
</Para>
<Para>
The traffic shaper can only be compiled as a module. It is
configured by the <Emphasis>shapecfg</Emphasis> program. The commands are
similar to the following:
</Para>
<Para>
<Screen>
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
</Screen>
</Para>
<Para>
The shaper device can only control the bandwidth of outgoing
traffic (as packets are transmitted via the shaper; only according to
the routing tables). A ``route by source address''
functionality could help in limiting the overall bandwidth of specific
hosts using a Linux router.
</Para>
<Para>
Linux-2.2 already has support for such routing. If you need it for
Linux-2.0 please check the patch by Mike McLagan at
<Literal remap="tt">ftp.invlogic.com</Literal>. Refer to
<Literal remap="tt">Documentation</Literal>networking/shaper.txt for further information about
the shaper.
</Para>
<Para>
If you want to try out a (tentative) shaping for incoming packets,
try out <Literal remap="tt">rshaper-1.01</Literal> (or newer) from <ULink
URL="ftp://ftp.systemy.it/pub/develop">ftp.systemy.it</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>DHCP and DHCPD</Title>
<Para>
DHCP is an acronym for Dynamic Host Configuration Protocol.
The creation of DHCP has made configuring the network on multiple hosts
extremely simple. Instead of having to configure each host separately, you
can assign all of the common host-used parameters with a
DHCP server.
</Para>
<Para>
Each time the host boots up, it will broadcast a packet to the network. This
packet is a call to any DHCP servers located on the same segment
to configure the host.
</Para>
<Para>
DHCP is extermely useful in assigning items such as the IP address, Netmask,
and gateway of each host.
</Para>
<Sect1>
<Title>DHCP Client Setup for users of LinuxConf</Title>
<Para>
When you are in linux, and you are logged in as the user "root", start the program linuxconf.
This program comes with all versions of redhat, and it works with X as well
as with the console. It also works for both SuSe and Caldera.
</Para>
<Para>
<Screen>
Select Networking
-----------------&#62;Basic Host Information
-----------------&#62;Select Enable
-----------------&#62;Set Config Mode DHCP
</Screen>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>DHCP Server Setup for Linux</Title>
<Para>
<Emphasis>Retrieve DHCPD (if your machine does not already have it installed).</Emphasis>
<ULink
URL="ftp://ftp.isc.org/isc/dhcp/">Get DHCPD</ULink>
</Para>
<Para>
<Emphasis><Emphasis>Quick Note: MAKE SURE YOU HAVE MULTICAST ENABLED IN THE KERNEL.</Emphasis></Emphasis>
</Para>
<Para>
<Emphasis>If there is not a binary distribution for your version of linux, then you will
have to compile DHCPD.</Emphasis>
</Para>
<Para>
Edit your /etc/rc.d/rc.local to reflect an addition of a route for
255.255.255.255.
</Para>
<Para>
<Emphasis><Emphasis>Quoted from DHCPd README:</Emphasis></Emphasis>
</Para>
<Para>
In order for dhcpd to work correctly with picky DHCP clients (e.g.,
Windows 95), it must be able to send packets with an IP destination
address of 255.255.255.255. Unfortunately, Linux insists on changing
255.255.255.255 into the local subnet broadcast address (in this case,
the address would be 192.5.5.223). This results in a DHCP protocol violation. While
many DHCP clients don't notice the problem, some (e.g., all Microsoft
DHCP clients) will recognize the violation. Clients that have this problem will appear not to
see DHCPOFFER messages from the server.
</Para>
<Para>
Type the following as root:
</Para>
<Para>
route add -host 255.255.255.255 dev eth0
</Para>
<Para>
If the message appears:
</Para>
<Para>
255.255.255.255: Unknown host
</Para>
<Para>
Try adding the following entry to your /etc/hosts file:
</Para>
<Para>
255.255.255.255 dhcp
</Para>
<Para>
Then, try:
</Para>
<Para>
route add -host dhcp dev eth0
</Para>
<Sect2>
<Title>Options for DHCPD</Title>
<Para>
Now you need to configure DHCPd. In order to do this, you will have to
create or edit /etc/dhcpd.conf. There is a graphical interface for
dhcpd configuration under <ULink
URL="http://www.solucorp.qc.ca">linuxconf</ULink>. This makes configuring and managing DHCPD extremely
simple.
</Para>
<Para>
If you want to configure it by hand, you should follow instructions below. I suggest
configuring it by hand at least once. It will help in the diagnostics that
a GUI can't provide. Unfortunately Micrsoft doesn't believe this!
</Para>
<Para>
The simplest way to assign IP addresses is to assign them randomly.
A sample configuration file that shows this type of setup is displayed below:
</Para>
<Para>
<Screen>
# Sample /etc/dhcpd.conf
# (add your comments here)
default-lease-time 1200;
max-lease-time 9200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "mydomain.org";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}
</Screen>
</Para>
<Para>
This will allow the DHCP server to assign the client an IP address
from the range 192.168.1.10-192.168.1.100 or 192.168.1.150-192.168.1.200.
</Para>
<Para>
If the client doesn't request a longer time frame, then the DHCP server
will lease an IP address for 1200 seconds. Otherwise, the maximum (allowed) lease
the server will allow is 9200 seconds. The server sends the following
parameters to the client:
</Para>
<Para>
Use 255.255.255.0 as your subnet mask
Use 192.168.1.255 as your broadcast address
Use 192.168.1.254 as your default gateway
USE 192.168.1.1 and 192.168.1.2 as your DNS servers.
</Para>
<Para>
If you specify a WINS server for your Windows clients, you need
to include the following option in the dhcpd.conf file:
</Para>
<Para>
option netbios-name-servers 192.168.1.1;
</Para>
<Para>
You can also assign specific IP addresses based on the clients' ethernet
<Emphasis>MAC</Emphasis> address as follows:
</Para>
<Para>
<Screen>
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 192.168.1.222;
}
</Screen>
</Para>
<Para>
This will assign IP address 192.168.1.222 to a client with the ethernet
<Emphasis>MAC</Emphasis> address of 08:00:2b:4c:59:23.
</Para>
</Sect2>
<Sect2>
<Title>Starting the server</Title>
<Para>
In most cases the DHCP installation doesn't create a "dhcpd.leases" file.
Before you start the server, you must create an empty file:
</Para>
<Para>
<Emphasis>touch /var/state/dhcp/dhcpd.leases</Emphasis>
</Para>
<Para>
To start the DHCP server, simply type (or include in the bootup scripts):
</Para>
<Para>
<Emphasis> /usr/sbin/dhcpd</Emphasis>
</Para>
<Para>
This will start dhcpd on eth0 device. If you need to start it on
another device, simply supply it on the command line as shown below:
</Para>
<Para>
<Emphasis> /usr/sbin/dhcpd eth1</Emphasis>
</Para>
<Para>
If you wish to test the configuration for any oddities, you can start
dhcpd with the debugging mode. Typing the command below will allow you
to see exactly what is going on with the server.
</Para>
<Para>
<Emphasis> /usr/sbin/dhcpd -d -f</Emphasis>
</Para>
<Para>
<Emphasis>Boot up a client</Emphasis>.Take a look at the console of the server.
You will see a number of debugging messages appear on the screen.
</Para>
<Para>
<Emphasis><Emphasis>Your done</Emphasis></Emphasis>
</Para>
</Sect2>
</Sect1>
</Chapter>
<Chapter>
<Title>Advanced Networking with Kernel 2.2</Title>
<Para>
Kernel 2.2 has advanced the routing capabilities of Linux quite a bit.
Unfortunately, the documentation for using these new capabilities is almost
impossible to find (even if it does exist).
</Para>
<Para>
I have put some time into it and have been able to do a little with it. I
will add more as I have the time and the assistance to figure out what it all means.
</Para>
<Para>
In kernel 2.0 and below, Linux used the standard <Emphasis>route</Emphasis> command to
place routes in a single routing table. If you were to type <Emphasis>netstat
-rn</Emphasis> at the Linux prompt, you would see and example.
</Para>
<Para>
In the newer kernels (2.1 and above), you have another option. This option is
rule based, and it allows you to have multiple routing tables. The new rules
allow a great deal of flexibility in deciding how a packet is handled. You
can choose between routes based not only on the destination address,
but also on the source address, TOS, or incoming device.
</Para>
<Sect1>
<Title>The Basics</Title>
<Para>
<Emphasis>Listing the Routing Table:</Emphasis>
</Para>
<Para>
ip route
</Para>
<Para>
Now on my machine, this equates to the following output:
</Para>
<Para>
<Screen>
207.149.43.62 dev eth0 scope link
207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62
default via 207.149.43.1 dev eth0
</Screen>
</Para>
<Para>
The first line:
</Para>
<Para>
<Emphasis>207.149.43.62 dev eth0 scope link</Emphasis> is the route for the interface
</Para>
<Para>
The second line:
</Para>
<Para>
<Emphasis>207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62</Emphasis>
Is the route that says <Emphasis>everything that goes to 207.149.43.0 needs to go
out 207.149.43.62</Emphasis>.
</Para>
<Para>
The third line:
</Para>
<Para>
<Emphasis>default via 207.149.43.1 dev eth0</Emphasis> is the default route.
</Para>
<Sect2>
<Title>Using the information</Title>
<Para>
Now that we have walked through a basic routing table, lets see how we use
it. First read
<ULink
URL="http://www.compendium.com.ar/policy-routing.txt">the Policy routing text.</ULink> If you get confused, don't worry -- it is a confusing text.
It will give you the run down on everything that the new routing code can accomplish.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>Adding a route with the new ip tools</Title>
<Para>
In the previous section, we spoke about both listing the routing table and we
discussed what the basics of that listing meant. Fortunately, the output is very similar
to the syntax that you would use to implement that exact routing table on
your own.
</Para>
<Para>
<Screen>
ip route add 207.149.43.62 dev eth0 scope link
ip route add 207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62
ip route add 127.0.0.0/8 dev lo scope link
ip route add default via 207.149.43.1 dev eth0
</Screen>
</Para>
<Para>
As you can see, the output and input are almost exact (except for the adding
of the <Emphasis>ip route add</Emphasis> in front of the line).
</Para>
<Para>
<Emphasis>Note:</Emphasis> We are aware that the documentation on Routing with 2.2 is
sorely lacking in details. In fact, I think EVERYONE is aware of it! If you have any
experience in this matter, please contact us at:
<ULink
URL="mailto:poet@linuxports.com">poet@linuxports.com</ULink> We
would like to get any information that you may have to help strengthen our documentation!
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Using NAT with Kernel 2.2</Title>
<Para>
The IP Network Address Translation facility is pretty much the standardized
"big brother" of the Linux IP Masquerade facility. It is specified in some detail
in RFC-1631 (at your nearest RFC archive). NAT provides features that
IP-Masquerade does not (which make it eminently more suitable for use in both
corporate firewall router designs, and in larger scale installations).
</Para>
<Para>
An alpha implementation of NAT for Linux 2.0.29 kernel has been developed by
Michael.Hasenstein: <Literal remap="tt">Michael.Hasenstein@informatik.tu-chemnitz.de</Literal>. Michael's
documentation and implementation are available from:
</Para>
<Para>
<ULink
URL="http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html">Linux IP Network Address Web Page</ULink>
</Para>
<Para>
The much improved TCP/IP stack of Linux 2.2 kernel has NAT functionality
built-in. This facility seems to render the work by Michael Hasenstein somewhat obsolete
(Michael.Hasenstein@informatik.tu-chemnitz.de).
</Para>
<Para>
To get it to work, you need the kernel with enabled CONFIG&lowbar;IP&lowbar;ADVANCED&lowbar;ROUTER,
CONFIG&lowbar;IP&lowbar;MULTIPLE&lowbar;TABLES (aka policy routing) and CONFIG&lowbar;IP&lowbar;ROUTE&lowbar;NAT (aka
fast NAT). And if you want to use finer grained NAT rules, you may also
want to turn on firewalling (CONFIG&lowbar;IP&lowbar;FIREWALL) and CONFIG&lowbar;IP&lowbar;ROUTE&lowbar;FWMARK.
To actually operate these kernel features, you will need the "ip" program by
Alexey Kuznyetsov from ftp://ftp.inr.ac.ru/ip-routing/.
</Para>
<Para>
Incoming datagrams NAT
</Para>
<Para>
Now, to translate addresses of incoming datagrams, the following command is
used:
</Para>
<Para>
<Screen>
ip route add nat &#60;ext-addr&#62;[/&#60;masklen&#62;] via &#60;int-addr&#62;
</Screen>
</Para>
<Para>
This will make an incoming packet destined to "ext-addr" (the address visible
from outside Internet) to have its destination address field rewritten to
"int-addr" (the address in your internal network, behind your
gateway/firewall). The packet is then routed according to the local routing
table. You can translate either single host addresses or complete blocks.
<Emphasis>Examples:</Emphasis>
</Para>
<Para>
<Screen>
ip route add nat 195.113.148.34 via 192.168.0.2
ip route add nat 195.113.148.32/27 via 192.168.0.0
</Screen>
</Para>
<Para>
First command will make internal address 192.168.0.2 accessible as
195.113.148.34. The second example shows remapping block 192.168.0.0-31 to
195.113.148.32-63.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Kernel 2.2 IP Command Reference (Work In Progress)</Title>
<Sect1>
<Title>ip</Title>
<Para>
If you have the iproute2 tools installed, then executing the ip command will
allow the basic syntax to be displayed.
</Para>
<Para>
<Screen>
[root@jd Net4]# ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
where OBJECT := { link | addr | route | rule | neigh | tunnel |
maddr | mroute | monitor }
OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |
-f[amily] { inet | inet6 | dnet | link } | -o[neline] }
</Screen>
</Para>
<Para>
There are also several options available:
</Para>
<Para>
<Emphasis>-V, -Version</Emphasis> -- print the version of the ip utility you are using and exit.
</Para>
<Para>
<Emphasis>-s, -stats, -statistics</Emphasis> -- obtain more output on the speficied
device. You can issue this option more than once to increase the amount of
information being displayed.
</Para>
<Para>
<Emphasis>-f, -family followed by a protocol family identifier such as: inet, inet6 or
link.</Emphasis> -- Specify the exact protocol family to use. Inet uses the
standard IPv4 (e.g.; current Internet standard), inet6 uses IPv6 (ground
breadking, never to be implemented Internet standard), and link (a physical
link). If you do not present the option, the protocol family is guessed.
If not enough information is present, it will fallback to the default
setting.
</Para>
<Para>
<Emphasis>-o, -oneline</Emphasis> Show the output each device record in a single line.
</Para>
<Para>
<Emphasis>-r, -resolve</Emphasis> Use the system resolver (e.g.; DNS) to print actual
names (versus IP numbers).
</Para>
<Para>
<Emphasis>OBJECT</Emphasis> Is the object (device) that you can retrieve
information from, and/or you can also manage the device.
The current device types understood by the current implementation are:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
link -- The network device e.g.; eth0 or ppp0 .
</Para>
</ListItem>
<ListItem>
<Para>
address -- The IP (IP or IPv6) address on the specified device.
</Para>
</ListItem>
<ListItem>
<Para>
neigh -- The ARP or NDISC cache entry.
</Para>
</ListItem>
<ListItem>
<Para>
route -- The routing table entry.
</Para>
</ListItem>
<ListItem>
<Para>
rule -- The rule in routing policy database.
</Para>
</ListItem>
<ListItem>
<Para>
maddress -- The multicast address.
</Para>
</ListItem>
<ListItem>
<Para>
mroute -- The multicast route cache entry.
</Para>
</ListItem>
<ListItem>
<Para>
tunnel -- Whether or not to tunnel over IP.
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
The amount of possible options allowed on each object type depend on the
type of action being taken. As a basic rule, it is possible to <Emphasis>add</Emphasis>,
<Emphasis>delete</Emphasis>, or to show the object(s). Not all object will allow
additional commands to be used. Of course, command help is available for all
objects. When help is used, it will print out a list of available sytanx conventions
for the given object.
</Para>
<Para>
If you do not give a command, the default command will be assumed. Typically the
default command is to list the objects. If the objects can not be listed, the default will
provide standard help output.
</Para>
<Para>
<Emphasis>ARGUMENTS</Emphasis> is the list of arguments that can be passed to the command.
The number of arguments depends upon both the command and the object being used.
There are two types of arguments:
</Para>
<Para>
<Emphasis>Flags</Emphasis> consist of a keyword followed by a
value. For convenience, each command contains some default parameters that can be
left out for easier use. For example, the parameter <Emphasis
>dev&#62;</Emphasis> defaults to an <Emphasis>ip link</Emphasis>.
</Para>
<Para>
<Emphasis>Mistakes... thank God for smart coders!</Emphasis>
All the operations within the ip commands are dynamic. If the sytanx of the ip utility fails, it will not change the configuration of the system.
There is an exception to this rule: the <Emphasis>ip link</Emphasis> command. This command is
used to change part of a devices parameters.
</Para>
<Para>
It is difficult to list all the error messages (especially the syntax errors). Generally speaking, their meaning is clear in the
context of the commands.
The most common mistakes are:
1.
Netlink is not configured in the kernel. The message is:
Cannot open netlink socket: Invalid value
</Para>
<Para>
2.
RTNETLINK is not configured in the kernel. One of the following messages may be printed
(depending upon the command):
Cannot talk to rtnetlink: Connection refused Cannot send dump request: Connection refused
</Para>
<Para>
3.
Option CONFIG&lowbar;IP&lowbar;MULTIPLE&lowbar;TABLES was not selected when configuring kernel. In this case, any attempt to
use commandip rule will fail. For example:
</Para>
<Para>
<Emphasis>jd@home $ ip rule list RTNETLINK error: Invalid argument dump
terminated</Emphasis>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Using common PC hardware</Title>
<Sect1>
<Title>ISDN</Title>
<Para>
The Integrated Services Digital Network (ISDN) is a series of standards
that specify a general purpose switched digital data network. An ISDN `call'
creates a synchronous Point-to-Point data service to the destination. ISDN
is generally delivered on a high speed link that is broken down into a number
of discrete channels. There are two different types of channels, the
`B Channels' (which will actually carry the user data) and a single channel
called the `D channel' (which is used to send control information to the ISDN
exchange: used for establishing calls and other functions). In Australia, for example,
ISDN may be delivered on a 2Mbps link that is broken into 30 discrete 64kbps
B channels (with one 64kbps D channel). Any number of channels may be used at a
time, and these channels can be used in any combination. You could, for example, establish 30 separate calls
to 30 different destinations at 64kbps each. You could also establish 15 calls
to 15 different destinations at 128kbps each (two channels used per call).
Finally, you could establish just a small number of calls while leaving the rest idle. A channel may be used
for either incoming or outgoing calls. The original intention of ISDN was to
allow Telecommunications companies to provide a single data service. This service could
deliver either telephone (via digitised voice) or data services to your home
or business. In this case, the customer would not be required to make any special configuration changes.
</Para>
<Para>
There are a few different ways to connect your computer to an ISDN service.
One way is to use a device called a `Terminal Adaptor' .This adaptor plugs into the
Network Terminating Unit (that you telecommunications carrier will have
installed when you received your ISDN service), and it presents a number of serial
interfaces. One of those interfaces is used to enter commands. Some commands are used to establish
calls and configuration, while others are actually connected to the network
devices that are to use the data circuits (when they are established). Linux will
work in this sort of configuration without modification: you just treat
the port on the Terminal Adaptor like you would treat any other serial device.
The kernel ISDN support is also designed to allow the user to install an ISDN card into
the Linux machine. This allows the Linux software to handle the protocols, and the software can
make the calls itself.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
ISDN subsystem ---&#62;
&#60;*&#62; ISDN support
[ ] Support synchronous PPP
[ ] Support audio via ISDN
&#60; &#62; ICN 2B and 4B support
&#60; &#62; PCBIT-D support
&#60; &#62; Teles/NICCY1016PC/Creatix support
</Screen>
</Para>
<Para>
The Linux implementation of ISDN supports a number of different types of
internal ISDN cards. These are listed in the kernel configuration options:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
ICN 2B and 4B
</Para>
</ListItem>
<ListItem>
<Para>
Octal PCBIT-D
</Para>
</ListItem>
<ListItem>
<Para>
Teles ISDN-cards and compatibles
</Para>
</ListItem>
</ItemizedList>
</Para>
<Para>
Some of these cards require software to be downloaded to make them
operational. A separate utility exists to allow downloading to happen.
</Para>
<Para>
Full details on how to configure the Linux ISDN support is available from
the <Emphasis>/usr/src/linux/Documentation/isdn/</Emphasis> directory. You can also check the FAQ dedicated
to <Emphasis>isdn4linux</Emphasis>: it is available at
<ULink
URL="http://www.lrz-muenchen.de/~ui161ab/www/isdn/">www.lrz-muenchen.de</ULink>.
(You can click on the english flag to get an english version).
</Para>
<Para>
<Emphasis>A note about PPP</Emphasis>. The PPP suite of protocols will operate over
either asynchronous or synchronous serial lines. The commonly distributed
PPP daemon for Linux `<Emphasis>pppd</Emphasis>' supports only asynchronous mode. If you wish
to run the PPP protocols over your ISDN service, you need a specially modified
version. Details of where to find this version are available in the documentation
referred to above.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>PLIP for Linux-2.0</Title>
<Para>
PLIP device names are `<Literal remap="tt">plip0</Literal>', `<Literal remap="tt">plip1</Literal> and <Literal remap="tt">plip2</Literal>.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
&#60;*&#62; PLIP (parallel port) support
</Screen>
</Para>
<Para>
<Emphasis>PLIP</Emphasis> (Parallel Line IP) is similar to SLIP in that it is
used for providing a <Emphasis>Point-to-Point</Emphasis> network connection
between two machines.
However, it is designed to use the parallel printer
ports on your machine. It doesn't use the
serial ports (a cabling diagram in
included in the cabling diagram section later in this document). Because it
is possible to transfer more than one bit at a time with a parallel port, it
is possible to attain higher speeds with the <Emphasis>PLIP</Emphasis>
interface. PLIP will attain higher speeds than those achieved by using a standard serial device.
In addition, even the simplest of parallel printer ports can be used
(in lieu of you having to purchase comparatively expensive 16550AFN UART's for
your serial ports). PLIP uses a lot of CPU compared to a serial link. It is
not a good option if, for example, you are able to obtain some cheap ethernet cards.
However, it will work when nothing else is available (and will work quite well).
You should expect a data transfer rate of about 20 kilobytes per second (when
a link is running well).
</Para>
<Para>
The PLIP device driver competes with the parallel device driver for the
parallel port hardware. If you wish to use both drivers, then you should
compile them both as modules. This ensures that you are able to select which
port you want to use for PLIP, and that you can select which ports you want for the printer driver.
Refer to the ``Modules mini-HOWTO'' for more information on kernel module configuration.
</Para>
<Para>
Please note that some laptops use chipsets that will not work with PLIP.
These chipsets do not allow some combinations of signals. PLIP relies on
these signals, but printers don't use them.
</Para>
<Para>
The Linux <Emphasis>PLIP</Emphasis> interface is compatible with the
<Emphasis>Crynwyr</Emphasis> Packet
Driver PLIP/ .This will mean that you can connect your Linux machine
to a DOS machine running any other sort of tcp/ip software via <Emphasis>PLIIP</Emphasis>.
</Para>
<Para>
In the 2.0.* series kernel, the PLIP devices are mapped to i/o port and IRQ as
follows:
</Para>
<Para>
<Screen>
device i/o IRQ
------ ----- ---
plip0 0x3bc 5
plip1 0x378 7
plip2 0x278 2
</Screen>
</Para>
<Para>
If your parallel ports don't match any of the above combinations, then you
can change the IRQ of a port. Change the IRQ by using the <Emphasis>ifconfig</Emphasis> command with the
`<Literal remap="tt">irq</Literal>' parameter (be sure to enable IRQ's on your printer ports in your
ROM BIOS if it supports this option). As an alternative, you
can specify ``<Literal remap="tt">io=</Literal>'' and ``<Literal remap="tt">irq=</Literal>'' options on the
<Emphasis>insmod</Emphasis> command line (if you use modules). For example:
</Para>
<Para>
<Screen>
root# insmod plip.o io=0x288 irq=5
</Screen>
</Para>
<Para>
PLIP operation is controlled by two timeouts: their default values
are probably ok in most cases. You will more than likely need to increase them
if you have an especially slow computer. In this case the timers to
increase are actually on the <Emphasis>other</Emphasis> computer. A program called
<Emphasis>plipconfig</Emphasis> exists that allows you to change these timer settings
without recompiling your kernel. This program is supplied with many Linux
distributions.
</Para>
<Para>
To configure a <Emphasis>PLIP</Emphasis> interface, you will need to invoke
the following commands (or <Emphasis>add</Emphasis> them to your
initialization scripts):
</Para>
<Para>
<Screen>
root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
root# /sbin/route add remoteplip plip1
</Screen>
</Para>
<Para>
Here, the port being used is the one at I/O address 0x378;
<Emphasis>localplip</Emphasis> amd <Emphasis>remoteplip</Emphasis> are the names or IP addresses used
over the PLIP cable. I personally keep them in my <Literal remap="tt">/etc/hosts</Literal>
database:
</Para>
<Para>
<Screen>
# plip entries
192.168.3.1 localplip
192.168.3.2 remoteplip
</Screen>
</Para>
<Para>
The <Emphasis>pointopoint</Emphasis> parameter has the same meaning as for SLIP.
It specifies the address of the machine at the other end of the link.
</Para>
<Para>
In almost all respects, you can treat a <Emphasis>PLIP</Emphasis> interface as
though it were a <Emphasis>SLIP</Emphasis> interface. However, neither
<Emphasis>dip</Emphasis> nor <Emphasis>slattach</Emphasis> can be used.
</Para>
<Para>
Further information on PLIP may be obtained from the
``PLIP mini-HOWTO''.
</Para>
<Sect2>
<Title>PLIP for Linux-2.2</Title>
<Para>
During development of the 2.1 kernel versions, support for the
parallel port was changed to an improved setup.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
General setup ---&#62;
[*] Parallel port support
Network device support ---&#62;
&#60;*&#62; PLIP (parallel port) support
</Screen>
</Para>
<Para>
The new code for PLIP behaves like the old one. You can use the same <Emphasis>ifconfig</Emphasis>
and <Emphasis>route</Emphasis> commands as in the previous section. However, initialization
of the device is different due to the advanced parallel port support.
</Para>
<Para>
The ``first'' PLIP device is always called ``plip0'' (where first
is the first device detected by the system; similarly to what happens
for Ethernet devices). The actual parallel port being used is one of
the available ports, as shown in <Literal remap="tt">/proc/parport</Literal>. For example,
if you have only one parallel port, you'll only have a directory
called <Literal remap="tt">/proc/parport/0</Literal>.
</Para>
<Para>
If your kernel didn't detect the IRQ number used by your port,
``<Literal remap="tt">insmod plip</Literal>'' will fail. In this case just write the correct
number to <Literal remap="tt">/proc/parport/0/irq</Literal>,then reinvoke <Emphasis>insmod</Emphasis>.
</Para>
<Para>
Complete information about parallel port management is available in
the file <Literal remap="tt">Documentation/parport.txt</Literal>(part of your kernel sources).
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>PPP</Title>
<Para>
Due to the nature, size, complexity, and flexibility of PPP, it has been moved to
its own HOWTO. The PPP-HOWTO is still a <Ulink URL="http://www.linuxdoc.org">
Linux Documentation Project document</Ulink>, but its official home is at
the <Ulink URL="http://www.LinuxPorts.Com"> LinuxPorts.Com website</Ulink>
<Ulink URL="http://www.linuxports.com/howto/ppp">PPP section</Ulink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>SLIP client - (Antiquated)</Title>
<Para>
SLIP devices are named `<Literal remap="tt">sl0</Literal>', `<Literal remap="tt">sl1</Literal>' etc. The first device
configured is assigned `<Literal remap="tt">0</Literal>', and the rest of the devices are incremented sequentially
as they are configured.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
&#60;*&#62; SLIP (serial line) support
[ ] CSLIP compressed headers
[ ] Keepalive and linefill
[ ] Six bit SLIP encapsulation
</Screen>
</Para>
<Para>
SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a serial
line (could be a phone line with a dialup modem, or a leased line of some sort).
To use SLIP, you would of course need access to an <Emphasis>SLIP-server</Emphasis> in your
area. Many universities and businesses provide SLIP access all over the world.
</Para>
<Para>
SLIP uses the serial ports on your machine to carry IP datagrams. To do this,
SLIP must take control of the serial device. SLIP device names are named
<Emphasis>sl0</Emphasis>, <Emphasis>sl1</Emphasis> etc. How do these correspond to your serial
devices? The networking code uses what is called an <Emphasis>ioctl</Emphasis> (i/o
control) call to change the serial devices into SLIP devices. There are
two programs supplied that can perform this function: they are called <Emphasis>dip</Emphasis> and
<Emphasis>slattach</Emphasis>
</Para>
<Sect2>
<Title>dip</Title>
<Para>
<Emphasis>dip</Emphasis> (Dialup IP) is a smart program that is able to perform the following
tasks: set the speed of the serial device, command your modem to dial the remote end of the link,
automatically log you into the remote server, search for messages sent to you
by the server, and extract information from them (such as your IP address). It will then
perform the <Emphasis>ioctl</Emphasis> necessary to switch your serial port into
SLIP mode. <Emphasis>dip</Emphasis> has a powerful scripting ability. It's this ability
that you can exploit to automate your logon procedure.
</Para>
<Para>
You can find it at:
<ULink
URL="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz">metalab.unc.edu</ULink>.
</Para>
<Para>
Refer to the following for installation guidelines:
</Para>
<Para>
<Screen>
user% tar xvzf dip337o-uri.tgz
user% cd dip-3.3.7o
user% vi Makefile
root# make install
</Screen>
</Para>
<Para>
The <Literal remap="tt">Makefile</Literal> assumes the existence of a group called <Emphasis>uucp</Emphasis>.
However, you might like to change this to either <Emphasis>dip</Emphasis> or <Emphasis>SLIP</Emphasis>
(depending on your configuration).
</Para>
</Sect2>
<Sect2>
<Title>slattach</Title>
<Para>
<Emphasis>slattach</Emphasis> (as contrasted with <Emphasis>dip</Emphasis>) is a very simple program
that does not have the sophistication of <Emphasis>dip</Emphasis>.
It does not have the scripting ability of dip. It will only configure your
serial device as a SLIP device. It assumes you have all the information you
need, and it figures that you have the serial line established before you invoke it. <Emphasis>slattach</Emphasis>
is ideal to use where you have a permanent connection to your server (such as
a physical cable or a leased line).
</Para>
</Sect2>
<Sect2>
<Title>When do I use which ?</Title>
<Para>
You would use <Emphasis>dip</Emphasis> when your link (to the machine that is your SLIP
server) is either a dialup modem or some other temporary link. You would use
<Emphasis>slattach</Emphasis> when you have a leased line, perhaps a cable, between your
machine and the server: it is assumed that there is no special action needed to get this link
working. See section `Permanen ist Slip connection' for more information.
</Para>
<Para>
Configuring SLIP is much like configuring an Ethernet interface
(read section `Configuring an ethernet device' above). There
are a few key differences.
</Para>
<Para>
First of all, SLIP links are unlike ethernet networks in that there
are only two hosts on the network (one at each end of the
link). Ethernet is available for use as soon are you are
cabled. However, SLIP may require you to initialize your network connection
in some special way
(depending upon the type of link that you have).
</Para>
<Para>
If you are using <Emphasis>dip</Emphasis>, then this would not normally be done
at boot time. It could be done at some later time, when you're ready to use the
link. It is possible to automate this procedure. If you are using
<Emphasis>slattach</Emphasis> then you will probably want to add a section to your
<Emphasis>rc.inet1</Emphasis> file. This will soon be addressed in our document..
</Para>
<Para>
There are two major types of SLIP servers: Dynamic IP address
servers and static IP address servers. Almost every SLIP server will
prompt you to login using a username and password:
<Emphasis>dip</Emphasis> can handle logging you in automatically.
</Para>
</Sect2>
<Sect2>
<Title>Static SLIP server with a dialup line and DIP.</Title>
<Para>
A static SLIP server is one in which you have been supplied an IP address
that is exclusively yours. Each time you connect to the server, you will
configure your SLIP port with that address. The static SLIP server will
answer your modem call, possibly prompt you for a username and password,
and then route any datagrams destined for your address to you via that
connection. If you have a static server, then you may want to put entries
for your hostname and IP address (since you know what it will be) into your
<Literal remap="tt">/etc/hosts</Literal>. You should also configure some other files such as:
<Literal remap="tt">rc.inet2</Literal>, <Literal remap="tt">host.conf</Literal>, <Literal remap="tt">resolv.conf</Literal>,
<Literal remap="tt">/etc/HOSTNAME</Literal> and <Literal remap="tt">rc.local</Literal>. Remember that when configuring
<Literal remap="tt">rc.inet1</Literal>, you don't need to add any special commands for your SLIP
connection (since it is <Emphasis>dip</Emphasis> that does all of the hard work for you in
configuring your interface). You will need to give <Emphasis>dip</Emphasis> the appropriate
information so it can configure the interface for you (after it commands the
modem to establish the call and it has logged you into your SLIP server).
</Para>
<Para>
If this is how your SLIP server works, then you can move on to the section
`Using Dip' to learn how to configure <Emphasis>dip</Emphasis> it appropriately.
</Para>
</Sect2>
<Sect2>
<Title>Dynamic SLIP server with a dialup line and DIP.</Title>
<Para>
A <Emphasis>dynamic</Emphasis> SLIP server is one which allocates you an IP
address randomly (from a pool of addresses) each time you logon. This
means that there is no guarantee that you will have any particular
address. Address may well be used by someone else
after you have logged off. The network administrator who configured
the SLIP server will have assigned a pool of address for the SLIP
server to use. When the server receives a new incoming call, the following steps occur: initially, it finds
the first unused address; second, it guides the caller through the login process; finally, it
then prints a welcome message that contains the IP address it has
allocated. It will ultimately use that particular IP address for the duration of
the call.
</Para>
<Para>
Configuring for this type of server is similar to configuring for a
static server. You must add an extra step, however, where you obtain the IP
address the server has allocated to you. Then you can configure your SLIP
device with that address.
</Para>
<Para>
Again, <Emphasis>dip</Emphasis> does the hard work for you. New versions are smart
enough to not only log you in, but they are also able to automatically
read the IP address printed in the welcome message. They can then store this address so
that you can have your SLIP device configured.
</Para>
<Para>
If this is how your SLIP server works, then you can move to section
`Using Dip' to learn how to configure <Emphasis>dip</Emphasis> appropriately.
</Para>
</Sect2>
<Sect2>
<Title>Using DIP.</Title>
<Para>
As explained earlier, <Emphasis>dip</Emphasis> is a powerful program that can simplify
and automate these process: dialing into the SLIP server, logging in the user,
starting the connection, and configuring the SLIP devices with the
appropriate <Emphasis>ifconfig</Emphasis> and <Emphasis>route</Emphasis> commands.
</Para>
<Para>
To use <Emphasis>dip</Emphasis>, you'll need to write a `dip script'. This script
is basically a list of commands that <Emphasis>dip</Emphasis> understands. These commands
tell <Emphasis>dip</Emphasis> how to perform each of the actions that you require.
See <Literal remap="tt">sample.dip</Literal> that comes supplied with <Emphasis>dip</Emphasis>
to get an idea of how it works. <Emphasis>dip</Emphasis> is quite a powerful
program: it comes with many options. Instead of going into all of them here,
you should look at the <Emphasis>man</Emphasis> page, README, and sample files that
will have come with your version of <Emphasis>dip</Emphasis>.
</Para>
<Para>
You may notice that the <Literal remap="tt">sample.dip</Literal> script assumes that
you're using a static SLIP server (so you'll know what your IP address is
beforehand). For dynamic SLIP servers, the newer versions of
<Emphasis>dip</Emphasis> include a command you can use to automatically read and
configure your SLIP device (with the IP address that the dynamic server
allocates for you). The following sample is a modified version of the
<Literal remap="tt">sample.dip</Literal> that came supplied with <Emphasis>dip337j-uri.tgz</Emphasis>.
It is probably a good starting point for you. You might like to save
it as <Literal remap="tt">/etc/dipscript</Literal>, then you can edit it to suit your configuration:
</Para>
<Para>
<Screen>
#
# sample.dip Dialup IP connection support program.
#
# This file (should show) shows how to use the DIP
# This file should work for Annex type dynamic servers, if you
# use a static address server then use the sample.dip file that
# comes as part of the dip337-uri.tgz package.
#
#
# Version: @(#)sample.dip 1.40 07/20/93
#
# Author: Fred N. van Kempen, &#60;waltje@uWalt.NL.Mugnet.ORG&#62;
#
main:
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400
# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset
# Note! "Standard" pre-defined "errlevel" values:
# 0 - OK
# 1 - CONNECT
# 2 - ERROR
#
# You can change those grep'ping for "addchat()" in *.c...
# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble
# We are connected. Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:
# We are now logged in.
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error
# Command the server into SLIP mode
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error
# Get and Set your IP address from the server.
# Here we assume that after commanding the SLIP server into SLIP
# mode that it prints your IP address
get $locip remote 30
if $errlvl != 0 goto prompt_error
# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default
# Say hello and fire up!
done:
print CONNECTED $locip ---&#62; $rmtip
mode CSLIP
goto exit
prompt_error:
print TIME-OUT waiting for sliplogin to fire up...
goto error
login_trouble:
print Trouble waiting for the Login: prompt...
goto error
password:error:
print Trouble waiting for the Password: prompt...
goto error
modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit
exit:
exit
</Screen>
</Para>
<Para>
The above example assumes you are calling a <Emphasis>dynamic</Emphasis> SLIP server. If
you are calling a <Emphasis>static</Emphasis> SLIP server, then the <Literal remap="tt">sample.dip</Literal>
file that comes with <Emphasis>dip337j-uri.tgz</Emphasis> should work for you.
</Para>
<Para>
When <Emphasis>dip</Emphasis> is given the <Emphasis>get &dollar;local</Emphasis> command, it
searches the incoming text from the remote end for a string that looks like an
IP address (ie strings numbers separated by `.' characters). This modification
was put in place specifically for <Emphasis>dynamic</Emphasis> SLIP servers so that the
process of reading the IP address granted by the server could be automated.
</Para>
<Para>
The example above will automatically create a default route via your SLIP link.
If this is not what you want, you might have an ethernet connection that should
be your default route. Remove the <Emphasis>default</Emphasis> command from the script.
After this script has finished running (if you do an <Emphasis>ifconfig</Emphasis> command),
you will see that you have a device <Emphasis>sl0</Emphasis>. This is your SLIP device.
You can modify its configuration manually after the
<Emphasis>dip</Emphasis> command has finished by using both the <Emphasis>ifconfig</Emphasis> and
the <Emphasis>route</Emphasis> commands.
</Para>
<Para>
Please note that <Emphasis>dip</Emphasis> allows you to select a number of different
protocols to use with the <Literal remap="tt">mode</Literal> command. The most common example is
<Emphasis>cSLIP</Emphasis>: it is used for SLIP with compression. Please note that both ends of the
link must agree. You should ensure that whatever you select agrees with your server settings.
</Para>
<Para>
The above example is fairly robust, and it should cope with most errors. Please
refer to the <Emphasis>dip</Emphasis> man page for more information. Naturally, you could
code the script to do such things as redial the server if it
doesn't get a connection within a prescribed period of time. You can even try
a series of servers (if you have access to more than one).
</Para>
</Sect2>
<Sect2>
<Title>Permanent SLIP connection using a leased line and slattach.</Title>
<Para>
If you have a cable between two machines (or are fortunate enough to have a
leased line), or some other permanent serial connection between your machine
and second machine, then you don't need to go to all the trouble of using
<Emphasis>dip</Emphasis> to set up your serial link. <Emphasis>slattach</Emphasis> is a very simple
utility that will allow you just enough functionality to configure your
connection.
</Para>
<Para>
Since your connection will be a permanent one, you will want to add some
commands to your <Literal remap="tt">rc.inet1</Literal> file. To get a permanent
connection, make sure that you configure the serial device to
the correct speed. Then switch the serial device into SLIP mode. <Emphasis>slattach</Emphasis>
allows you to do this with one command. <Emphasis>Add</Emphasis> the following to your
<Literal remap="tt">rc.inet1</Literal> file:
</Para>
<Para>
<Screen>
#
# Attach a leased line static SLIP connection
#
# configure /dev/cua0 for 19.2kbps and cslip
/sbin/slattach -p cslip -s 19200 /dev/cua0 &#38;
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End static SLIP.
</Screen>
</Para>
<Para>
Where:
<VariableList>
<VarListEntry>
<Term>IPA.IPA.IPA.IPA</Term>
<ListItem>
<Para>
represents your IP address.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>IPR.IPR.IPR.IPR</Term>
<ListItem>
<Para>
represents the IP address of the remote end.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
<Emphasis>slattach</Emphasis> allocates the first unallocated SLIP device to the serial
device specified. <Emphasis>slattach</Emphasis> starts with <Emphasis>sl0</Emphasis>.
The first <Emphasis>slattach</Emphasis> command attaches SLIP device <Emphasis>sl0</Emphasis> to
the serial device specified; <Emphasis>sl1</Emphasis> the next time, etc.
</Para>
<Para>
<Emphasis>slattach</Emphasis> allows you to configure a number of different
protocols with the <Literal remap="tt">-p</Literal> argument. You will use
either <Emphasis>SLIP</Emphasis> or <Emphasis>cSLIP</Emphasis>: the choice will depend
on whether or not you want to use compression. Note: both ends must agree on compression or no
compression.
</Para>
</Sect2>
<Sect2>
<Title>SLIP server.</Title>
<Para>
If you have a machine that is perhaps network connected, and you'd like
other people be able to dial in and obtain network services, then you
will need to configure your machine as a server. If you want to use SLIP
as the serial line protocol, then you have three options as to how
to configure your Linux machine (as a SLIP server). My preference would be to
use the first presented (<Emphasis>sliplogin</Emphasis>) because it seems the easiest to
configure and understand. I will present a summary of each so that you can
make your own decision.
</Para>
</Sect2>
<Sect2>
<Title>Slip Server using <Emphasis>sliplogin</Emphasis>.</Title>
<Para>
<Emphasis>sliplogin</Emphasis> is a program that you can use in place of the normal login
shell for SLIP users. It converts the terminal line into a SLIP line. It also
allows you to configure your Linux machine as either a <Emphasis>static address
server</Emphasis> (users get the same address everytime they call in), or a
<Emphasis>dynamic address server</Emphasis> (where users may get a different address allocated
to them each time they call).
</Para>
<Para>
The caller will login as per the standard login process by entering their username
and password. However, instead of being presented with a shell after their login,
<Emphasis>sliplogin</Emphasis> is executed. Sliplogin searches its configuration file
(<Literal remap="tt">/etc/slip.hosts</Literal>) for an entry with a login name that matches that of
the caller. If it locates a match, it then configures the line as an 8bit clean line. It
uses an <Emphasis>ioctl</Emphasis> call to convert the line discipline to SLIP. When
this process is complete, the last stage of configuration takes place. Now
<Emphasis>sliplogin</Emphasis> invokes a shell script which configures the SLIP interface
with the relevant ip address and netmask. It will also set appropriate routing in place.
This script is usually called <Literal remap="tt">/etc/slip.login</Literal>. In a similar manner
to <Emphasis>getty</Emphasis> (where you have certain callers that require special
initialization) you can create configuration scripts called
<Literal remap="tt">/etc/slip.login.loginname</Literal>. These scripts will be run instead of the defaults.
</Para>
<Para>
There are either three or four files that you need to configure to get
<Emphasis>sliplogin</Emphasis> working for you. I will detail where to obtain
the software and how to configure in detail. The files are:
</Para>
<Para>
<ItemizedList>
<ListItem>
<Para>
<Literal remap="tt">/etc/passwd</Literal>, for the dialin user accounts.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">/etc/slip.hosts</Literal>, to contain the information unique to each
dial-in user.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">/etc/slip.login</Literal>, which manages the configuration of the routing
that needs to be performed for the user.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">/etc/slip.tty</Literal>, which is required only if you are configuring
your server for <Emphasis>dynamic address allocation</Emphasis>. It contains a table
of addresses to allocate.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">/etc/slip.logout</Literal>, which contains commands to clean up after the
user has hung up or logged out.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>Where to get <Emphasis>sliplogin</Emphasis></Title>
<Para>
You may already have the <Emphasis>sliplogin</Emphasis> package installed as part of your
distribution. If you do not have the package, then you can get <Emphasis>sliplogin</Emphasis> from:
<ULink
URL="ftp://metalab.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz">metalab.unc.edu</ULink>.
The tar file contains both source, precompiled binaries and a <Emphasis>man</Emphasis> page.
</Para>
<Para>
To ensure that only authorized users will be able to run the<Emphasis>sliplogin</Emphasis>
program, you should add an entry to your <Literal remap="tt">/etc/group</Literal> file similar to
the following:
</Para>
<Para>
<Screen>
..
slip::13:radio,fred
..
</Screen>
</Para>
<Para>
When you install the <Emphasis>sliplogin</Emphasis> package, the
<Emphasis>Makefile</Emphasis> will
change the group ownership of the
<Emphasis>sliplogin</Emphasis> program to <Literal remap="tt">slip</Literal>.
This will mean that only users who belong to that group will be able
to execute it. The example above will allow only users <Literal
remap="tt">radio</Literal> and
<Literal remap="tt">fred</Literal>
to execute
<Emphasis>sliplogin</Emphasis>.
</Para>
<Para>
To install the binaries into your <Literal remap="tt">/sbin</Literal> directory, and to place the
<Emphasis>man</Emphasis> page into section 8, perform the following:
</Para>
<Para>
<Screen>
# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# &#60;..edit the Makefile if you don't use shadow passwords..&#62;
# make install
</Screen>
</Para>
<Para>
If you want to recompile the binaries before installation, add a
<Literal remap="tt">make clean</Literal> before the <Literal remap="tt">make install</Literal>. If you want to install
the binaries somewhere else, you will need to edit the <Literal remap="tt">Makefile</Literal>
<Emphasis>install rule.</Emphasis>
</Para>
</Sect2>
<Sect2>
<Title>Configuring <Literal remap="tt">/etc/passwd</Literal> for Slip hosts.</Title>
<Para>
You would usually create some special logins for Slip callers in your
<Literal remap="tt">/etc/passwd</Literal> file. A convention commonly followed is to use the
<Emphasis>hostname</Emphasis> of the calling host with a capital `S' prefixing it.
If the calling host is called <Literal remap="tt">radio</Literal> then you could
create a <Literal remap="tt">/etc/passwd</Literal> entry that looked like:
</Para>
<Para>
<Screen>
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
</Screen>
</Para>
<Para>
It doesn't really matter what the account is called: just make it
meaningful to you!
</Para>
<Para>
Note: the caller doesn't need any special home directory. They will not
be presented with a shell from this machine, so <Literal remap="tt">/tmp</Literal> is a good choice.
Also note that <Emphasis>sliplogin</Emphasis> is used in place of the normal login shell.
</Para>
</Sect2>
<Sect2>
<Title>Configuring <Literal remap="tt">/etc/slip.hosts</Literal></Title>
<Para>
The <Literal remap="tt">/etc/slip.hosts</Literal> file is the file that <Emphasis>sliplogin</Emphasis>
searches (it looks for entries matching the login name) to obtain configuration details
for this particular caller. It is this file where you specify the ip address and netmask
that will be assigned to the caller (configured for their use). Sample
entries for two hosts: one a static configuration for host <Literal remap="tt">radio</Literal>, and
another is a dynamic configuration for user host <Literal remap="tt">albert</Literal>.They both might look like:
</Para>
<Para>
<Screen>
#
Sradio 44.136.8.99 44.136.8.100 255.255.255.0 normal -1
Salbert 44.136.8.99 DYNAMIC 255.255.255.0 compressed 60
#
</Screen>
</Para>
<Para>
The <Literal remap="tt">/etc/slip.hosts</Literal> file entries are:
</Para>
<Para>
<OrderedList>
<ListItem>
<Para>
The login name of the caller.
</Para>
</ListItem>
<ListItem>
<Para>
The ip address of the server machine (ie: this machine).
</Para>
</ListItem>
<ListItem>
<Para>
This is the ip address that is assigned to the caller. If this field is coded
<Literal remap="tt">DYNAMIC</Literal>, then an ip address will be allocated. This is based on the information
contained in your <Literal remap="tt">/etc/slip.tty</Literal> file (to be discussed later).
<Emphasis>Note:</Emphasis> you must be using at least version 1.3 of sliplogin for this to work.
</Para>
</ListItem>
<ListItem>
<Para>
The netmask assigned to the calling machine in dotted decimal notation
eg 255.255.255.0 for a Class C network mask.
</Para>
</ListItem>
<ListItem>
<Para>
This is the slip mode setting which allows you to enable/disable compression and
slip other features. Allowable values here are either "<Literal remap="tt">normal</Literal>" or
"<Literal remap="tt">compressed</Literal>".
</Para>
</ListItem>
<ListItem>
<Para>
A timeout parameter which specifies how long the line can remain idle (no
datagrams received) before the line is automatically disconnected. A negative
value disables this feature.
</Para>
</ListItem>
<ListItem>
<Para>
Optional arguments.
</Para>
</ListItem>
</OrderedList>
</Para>
<Para>
Note: You can use either hostnames or IP addresses (in dotted decimal notation)
for fields 2 and 3. If you use hostnames, then those hosts must be resolvable.
In other words, your machine must be able to locate an IP address for those hostnames.
If the machine can't locate an IP address, the script will fail when it is called. You can test this by
trying to telnet to the hostname. If you get the
`<Emphasis>Trying nnn.nnn.nnn...</Emphasis>' message, then your machine has been able to find
an ip address for that name. If you get the message `<Emphasis>Unknown host</Emphasis>', then
it was unsuccessful. In this case, you can either use ip addresses in dotted decimal notation, or fix
up your name resolver configuration (See section <Literal remap="tt">Name Resolution</Literal>).
</Para>
<Para>
The most common slip modes are:
<VariableList>
<VarListEntry>
<Term>normal</Term>
<ListItem>
<Para>
to enable normal uncompressed SLIP.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>compressed</Term>
<ListItem>
<Para>
to enable van Jacobsen header compression (cSLIP)
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
<Para>
Naturally these are mutually exclusive. You can use one or the other. For more
information on the other options available, refer to the <Emphasis>man</Emphasis> pages.
</Para>
</Sect2>
<Sect2>
<Title>Configuring the <Literal remap="tt">/etc/slip.login</Literal> file.</Title>
<Para>
After <Emphasis>sliplogin</Emphasis> has searched the <Literal remap="tt">/etc/slip.hosts</Literal>, and
it has found a matching entry, it will then attempt to execute the <Literal remap="tt">/etc/slip.login</Literal> file.
It will then configure the SLIP interface with its ip address and netmask.
</Para>
<Para>
The sample <Literal remap="tt">/etc/slip.login</Literal> file supplied with the <Emphasis>sliplogin</Emphasis>
package looks like this:
</Para>
<Para>
<Screen>
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a SLIP line. sliplogin invokes this with
# the parameters:
# $1 $2 $3 $4, $5, $6 ...
# SLIPunit ttyspeed pid the arguments from the slip.host entry
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 &#60;hw_addr&#62; pub
exit 0
#
</Screen>
</Para>
<Para>
You will note that this script simply uses the <Emphasis>ifconfig</Emphasis> and
<Emphasis>route</Emphasis> commands to configure the SLIP device (with its IP address,
remote IP address, and netmask). The script then creates a route for the remote address via
the SLIP device. This procedure is the same as you would invoke if you were using the
<Emphasis>slattach</Emphasis> command.
</Para>
<Para>
Note also the use of <Emphasis>Proxy ARP</Emphasis>. It ensures that other hosts on the same
ethernet as the server machine will know how to reach the dial-in host.
The <Literal remap="tt">&lt;hw&lowbar;addr&#62;</Literal> field should be the hardware address of the ethernet
card in the machine. If your server machine isn't on an ethernet network, then
you can eliminate this line.
</Para>
</Sect2>
<Sect2>
<Title>Configuring the <Literal remap="tt">/etc/slip.logout</Literal> file.</Title>
<Para>
You want to ensure that the serial device is restored
to its normal state when the call drops out (so that future callers will be able to login correctly).
This is achieved with the use of the <Literal remap="tt">/etc/slip.logout</Literal> file. It is
quite simple in format, and it is called with the same argument as the
<Literal remap="tt">/etc/slip.login</Literal> file.
</Para>
<Para>
<Screen>
#!/bin/sh -
#
# slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#
</Screen>
</Para>
<Para>
All it does is `down' the interface. This will delete the manual route
previously created. It also uses the <Emphasis>arp</Emphasis> command to delete any proxy
arp put in place. You don't need the <Emphasis>arp</Emphasis> command in the script
if your server machine does not have an ethernet port.
</Para>
</Sect2>
<Sect2>
<Title>Configuring the <Literal remap="tt">/etc/slip.tty</Literal> file.</Title>
<Para>
If you are using dynamic ip address allocation, you should have any hosts configured
with the <Literal remap="tt">DYNAMIC</Literal> keyword in the <Literal remap="tt">/etc/slip.hosts</Literal> file.
You must then configure the <Literal remap="tt">/etc/slip.tty</Literal> file to list what addresses
are assigned to what port. You only need this file if you wish your server
to dynamically allocate addresses to users.
</Para>
<Para>
The file is a table that lists both the <Emphasis>tty</Emphasis> devices that will support
dial-in SLIP connections,and the ip address that should be assigned to users
who call in on that port.
</Para>
<Para>
Its format is as follows:
<Screen>
# slip.tty tty -&#62; IP address mappings for dynamic SLIP
# format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0 192.168.0.100
/dev/ttyS1 192.168.0.101
#
</Screen>
</Para>
<Para>
What this table says is that callers that dial in on port <Literal remap="tt">/dev/ttyS0</Literal>
(who have their remote address field in the <Literal remap="tt">/etc/slip.hosts</Literal> file
set to <Literal remap="tt">DYNAMIC</Literal>) will be assigned an address of <Literal remap="tt">192.168.0.100</Literal>.
</Para>
<Para>
In this way you need only allocate one address per port for all the users who do
not require dedicated address. This helps you keep the number
of addresses you need down to a minimum.
</Para>
</Sect2>
<Sect2>
<Title>Slip Server using <Emphasis>dip</Emphasis>.</Title>
<Para>
Let me start by saying that some of the information below came from the
<Emphasis>dip</Emphasis> man pages (where how to run Linux as a SLIP server is briefly
documented). Please also beware that the following has been based on
the <Emphasis>dip337o-uri.tgz</Emphasis> package, and it probably will not apply to other
versions of <Emphasis>dip</Emphasis>.
</Para>
<Para>
<Emphasis>dip</Emphasis> has an input mode of operation. In this mode, it automatically locates
an entry for the user who invoked it, and it then configures the serial line as
a SLIP link (according to information it finds in the <Literal remap="tt">/etc/diphosts</Literal>
file). This input mode of operation is activated by invoking <Emphasis>dip</Emphasis>
as <Emphasis>diplogin</Emphasis>. By creating special accounts where <Emphasis>diplogin</Emphasis> is used as the
login shell, you are using <Emphasis>dip</Emphasis> as a SLIP server.
</Para>
<Para>
The first thing you will need to do is to make a symbolic link as follows:
</Para>
<Para>
<Screen>
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
</Screen>
</Para>
<Para>
You then need to add entries to both your <Literal remap="tt">/etc/passwd</Literal> and your
<Literal remap="tt">/etc/diphosts</Literal> files. The entries you need to make are formatted
as follows:
</Para>
<Para>
To configure Linux as a SLIP server with <Emphasis>dip</Emphasis>, you need to create some
special SLIP accounts for users. You will use <Emphasis>dip</Emphasis> (in input mode) as
the login shell. A suggested convention is to have all SLIP accounts
begin with a capital `S', eg `Sfredm'.
</Para>
<Para>
A sample <Literal remap="tt">/etc/passwd</Literal> entry for a SLIP user looks like the following:
</Para>
<Para>
<Screen>
Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^ ^^ ^^ ^^ ^^ ^^ ^^
| | | | | | \__ diplogin as login shell
| | | | | \_______ Home directory
| | | | \____________ User Full Name
| | | \_________________ User Group ID
| | \_____________________ User ID
| \_______________________________ Encrypted User Password
\__________________________________________ Slip User Login Name
</Screen>
</Para>
<Para>
After the user logs in, the <Emphasis>login</Emphasis> program (if it finds and
verifies the user) will execute the <Emphasis>diplogin</Emphasis>
command <Emphasis>dip</Emphasis>. <Emphasis>diplogin</Emphasis> knows that it
should automatically assume that it is being used a login shell. When
it is started as <Emphasis>diplogin</Emphasis> it uses the
<Emphasis>getuid()</Emphasis> function call to get the userid from whoever has
invoked it. It then searches the <Literal remap="tt">/etc/diphosts</Literal> file for the
first entry that matches either the userid or the name of the
<Emphasis>tty</Emphasis> device from where the call has originated. It then configures itself
appropriately. By deciding between giving the user an
entry in the <Literal remap="tt">diphosts</Literal> file, or providing her or him
the default configuration, you can build your server in such a
way that you can have a mix of static and dynamically assigned addressed
users.
</Para>
<Para>
You do not need to worry about manually adding such entries because
<Emphasis>dip</Emphasis> will automatically add a `Proxy-ARP' entry if invoked in input
mode.
</Para>
</Sect2>
<Sect2>
<Title>Configuring <Literal remap="tt">/etc/diphosts</Literal></Title>
<Para>
<Literal remap="tt">/etc/diphosts</Literal> is used by <Emphasis>dip</Emphasis> to lookup preset
configurations for remote hosts. These remote hosts might be users
dialing into your linux machine, or they might be for machines that you dial
into with your linux machine.
</Para>
<Para>
The general format for <Literal remap="tt">/etc/diphosts</Literal> is as follows:
</Para>
<Para>
<Screen>
..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
..
</Screen>
</Para>
<Para>
The fields are:
<OrderedList>
<ListItem>
<Para>
<Literal remap="tt">Login name</Literal>: as returned by getpwuid(getuid())
or tty name.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Unused</Literal>: compat. with passwd
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Remote Address</Literal>: IP address of the calling host, either numeric or by name
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Local Address</Literal>: IP address of this machine, again numeric or by name
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Netmask</Literal>: in dotted decimal notation
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Comment field</Literal>: place whatever you want here.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">Protocol</Literal>: Slip, CSlip etc.
</Para>
</ListItem>
<ListItem>
<Para>
<Literal remap="tt">MTU</Literal>: decimal number
</Para>
</ListItem>
</OrderedList>
</Para>
<Para>
An example <Literal remap="tt">/etc/net/diphosts</Literal> entry for a remote SLIP user might be:
</Para>
<Para>
<Screen>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
</Screen>
</Para>
<Para>
which specifies a SLIP link with remote address of 145.71.34.1 and MTU of 296,
or:
</Para>
<Para>
<Screen>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
</Screen>
</Para>
<Para>
which specifies a cSLIP-capable link with remote address 145.71.34.1 and MTU
of 1006.
</Para>
<Para>
All users who you wish to be allowed a statically allocated dial-up
IP access should have an entry in the <Literal remap="tt">/etc/diphosts</Literal>. If you want
users who call a particular port to have their details dynamically allocated,
then you must have an entry for the <Literal remap="tt">tty</Literal> device (and do not configure a
user based entry). You should remember to configure at least one entry for
each <Literal remap="tt">tty</Literal> device that is used. This ensures that a suitable
configuration is available for them regardless of which modem they call in on.
</Para>
<Para>
When a user logs in, they will receive a normal login and password prompt.
They should then enter their SLIP-login userid and password. If these verify
properly, then the user will see no special messages. The user should then change into
SLIP mode at their end. The user should then be able to connect and be
configured with the relevant parameters from the <Literal remap="tt">diphosts</Literal> file.
</Para>
</Sect2>
<Sect2>
<Title>SLIP server using the <Emphasis>dSLIP</Emphasis> package.</Title>
<Para>
Matt Dillon <Literal remap="tt">&lt;dillon@apollo.west.oic.com&gt;</Literal> has written a package
that does not only dial-in but also dial-out SLIP. Matt's package is
a combination of small programs and scripts that manage your connections
for you. You will need to have <Emphasis>tcsh</Emphasis> installed as at least one
of the scripts requires it. Matt supplies a binary copy of the <Emphasis>expect</Emphasis>
utility as it too is needed by one of the scripts. You will most likely need
some experience with <Emphasis>expect</Emphasis> to get this package working to your
liking, but don't let that deter your efforts!
</Para>
<Para>
Matt has written a good set of installation instructions in the
README file, so I won't bother to repeat them.
</Para>
<Para>
You can get the <Emphasis>dSLIP</Emphasis> package from its home site at:
</Para>
<Para>
<Emphasis>apollo.west.oic.com</Emphasis>
<Screen>
/pub/linux/dillon_src/dSLIP203.tgz
</Screen>
</Para>
<Para>
or from:
</Para>
<Para>
<Emphasis>metalab.unc.edu</Emphasis>
<Screen>
/pub/Linux/system/Network/serial/dSLIP203.tgz
</Screen>
</Para>
<Para>
Read the <Literal remap="tt">README</Literal> file and create the <Literal remap="tt">/etc/passwd</Literal> and
<Literal remap="tt">/etc/group</Literal> entries <Emphasis>before</Emphasis> doing a <Literal remap="tt">make install</Literal>.
</Para>
</Sect2>
</Sect1>
</Chapter>
<Chapter>
<Title>Other Network Technologies</Title>
<Para>
The following subsections are specific to particular network
technologies. The information contained in these sections does not
necessarily apply to any other type of network technology. The topics
are sorted alphabetically.
</Para>
<Sect1>
<Title>ARCNet</Title>
<Para>
ARCNet device names are `<Literal remap="tt">arc0e</Literal>', `<Literal remap="tt">arc1e</Literal>', `<Literal remap="tt">arc2e</Literal>' etc. or
`<Literal remap="tt">arc0s</Literal>', `<Literal remap="tt">arc1s</Literal>', `<Literal remap="tt">arc2s</Literal>' etc. The first card detected by the
kernel is assigned either `<Literal remap="tt">arc0e</Literal>' or `<Literal remap="tt">arc0s</Literal>' The rest are assigned
sequentially in the order they are detected. The letter at the end signifies
either the ethernet encapsulation packet format or the RFC1051 packet format.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
&#60;*&#62; ARCnet support
[ ] Enable arc0e (ARCnet "Ether-Encap" packet format)
[ ] Enable arc0s (ARCnet RFC1051 packet format)
</Screen>
</Para>
<Para>
Once you have your kernel properly built to support your ethernet card, then
configuring the card is easy.
</Para>
<Para>
Typically you would use something like:
</Para>
<Para>
<Screen>
root# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
</Screen>
</Para>
<Para>
Please refer to the
<Literal remap="tt">/usr/src/linux/Documentation/networking/arcnet.txt</Literal> and
<Literal remap="tt">/usr/src/linux/Documentation/networking/arcnet-hardware.txt</Literal> files
for further information.
</Para>
<Para>
ARCNet support was developed by Avery Pennarun, <Literal remap="tt">apenwarr@foxnet.net</Literal>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Appletalk (<Literal remap="tt">AF&lowbar;APPLETALK</Literal>)</Title>
<Para>
The Appletalk support has no special device names as it uses existing network
devices.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
&#60;*&#62; Appletalk DDP
</Screen>
</Para>
<Para>
Appletalk support allows your Linux machine to interwork with Apple networks.
An important use for this is to share resources (such as printers and disks)
between your Linux and Apple computers. Additional software is required;
this is called <Emphasis>netatalk</Emphasis>. Wesley Craig <Literal remap="tt">netatalk@umich.edu</Literal> represents
a team called the `Research Systems Unix Group' at the University of Michigan.
They have produced the <Emphasis>netatalk</Emphasis> package. This product provides software that
implements the Appletalk protocol stack along with some useful utilities.
The <Emphasis>netatalk</Emphasis> package will either be supplied with your Linux
distribution, or you will have to ftp it from the home site at
<ULink
URL="ftp://terminator.rs.itd.umich.edu/unix/netatalk/">University of Michigan</ULink>
</Para>
<Para>
To build and install the package, do something like the following:
</Para>
<Para>
<Screen>
user% tar xvfz .../netatalk-1.4b2.tar.Z
user% make
root# make install
</Screen>
</Para>
<Para>
You may want to edit the `Makefile' before calling <Emphasis>make</Emphasis> to
actually compile the software. Specifically, you might want to change
the DESTDIR variable that defines where the files will later be installed.
The default of /usr/local/atalk is fairly safe.
</Para>
<Sect2>
<Title>Configuring the Appletalk software.</Title>
<Para>
The first thing you need to do to make it all work is to ensure that the
appropriate entries in the <Literal remap="tt">/etc/services</Literal> file are present. The
entries you need are:
</Para>
<Para>
<Screen>
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
</Screen>
</Para>
<Para>
The next step is to create the Appletalk configuration files in the
<Literal remap="tt">/usr/local/atalk/etc</Literal> directory (or wherever you installed the
package).
</Para>
<Para>
The first file to create is the <Literal remap="tt">/usr/local/atalk/etc/atalkd.conf</Literal> file.
This file initially needs only one line. This line gives the name of the network
device supporting the network that your Apple machines are on:
</Para>
<Para>
<Screen>
eth0
</Screen>
</Para>
<Para>
The Appletalk daemon program will add extra details after it has been initiated.
</Para>
</Sect2>
<Sect2>
<Title>Exporting a Linux filesystems via Appletalk.</Title>
<Para>
You can export filesystems from your linux machine to the network so that any
Apple machine on the network can share them.
</Para>
<Para>
To do this you must configure the
<Literal remap="tt">/usr/local/atalk/etc/AppleVolumes.system</Literal> file. There is another
configuration file called <Literal remap="tt">/usr/local/atalk/etc/AppleVolumes.default</Literal>
This file has exactly the same format: it describes which filesystems users
connecting with guest privileges will receive.
</Para>
<Para>
Full details on how to configure these files (and their various options)
can be found in the <Emphasis>afpd</Emphasis> man page.
</Para>
<Para>
A simple example might look like:
</Para>
<Para>
<Screen>
/tmp Scratch
/home/ftp/pub "Public Area"
</Screen>
</Para>
<Para>
This would export your <Literal remap="tt">/tmp</Literal> filesystem as AppleShare Volume
`Scratch', and it would export your ftp public directory as AppleShare Volume `Public Area'.
The volume names are not mandatory. The daemon will choose some for you,
but it won't hurt to specify them anyway.
</Para>
</Sect2>
<Sect2>
<Title>Sharing your Linux printer across Appletalk.</Title>
<Para>
It is simple to share your linux printer with your Apple machines.
You need to run the <Emphasis>papd</Emphasis> program, the Appletalk
Printer Access Protocol Daemon. When you run this program, it will accept
requests from your Apple machines and spool the print job to your local
line printer daemon.
</Para>
<Para>
You need to edit the <Literal remap="tt">/usr/local/atalk/etc/papd.conf</Literal> file to configure
the daemon. The syntax of this file is the same as that of your usual
<Literal remap="tt">/etc/printcap</Literal> file. The name you give to the definition is
registered with the Appletalk naming protocol NBP.
</Para>
<Para>
A sample configuration might look like:
</Para>
<Para>
<Screen>
TricWriter:\
:pr=lp:op=cg:
</Screen>
</Para>
<Para>
This would make a printer named `TricWriter' available to your Appletalk
network. All accepted jobs would be printed to the linux printer `<Literal remap="tt">lp</Literal>'
(as defined in the <Literal remap="tt">/etc/printcap</Literal> file) using <Emphasis>lpd</Emphasis>. The entry
`<Literal remap="tt">op=cg</Literal>' says that the linux user `<Literal remap="tt">cg</Literal>' is the operator of the printer.
</Para>
</Sect2>
<Sect2>
<Title>Starting the appletalk software.</Title>
<Para>
Ok.You should now be ready to test this basic configuration. There is an
<Emphasis>rc.atalk</Emphasis> file supplied with the <Emphasis>netatalk</Emphasis> package that should
work ok for you, so all you should have to do is:
</Para>
<Para>
<Screen>
root# /usr/local/atalk/etc/rc.atalk
</Screen>
</Para>
<Para>
All should startup and run ok. You should see no error messages.
The software will send messages to the console indicating each stage as it
starts.
</Para>
</Sect2>
<Sect2>
<Title>Testing the appletalk software.</Title>
<Para>
To test that the software is functioning properly: go to one of your Apple
machines, pull down the Apple menu, select the Chooser, click on AppleShare,
and your Linux box should appear.
</Para>
</Sect2>
<Sect2>
<Title>Caveats of the appletalk software.</Title>
<Para>
<ItemizedList>
<ListItem>
<Para>
You may need to start the Appletalk support before you
configure your IP network. If you have problems
starting the Appletalk programs (or if after you start
them you have trouble with your IP network), then try
starting the Appletalk software before you run your
<Literal remap="tt">/etc/rc.d/rc.inet1</Literal> file.
</Para>
</ListItem>
<ListItem>
<Para>
The <Emphasis>afpd</Emphasis> (Apple Filing Protocol Daemon)
SEVERELY MESSES UP YOUR HARD DISK. It creates a couple of directories called
``<Literal remap="tt">.AppleDesktop</Literal>'' and <Literal remap="tt">Network Trash
Folder</Literal> below the mount
points. For each directory you access, it
will create a <Literal remap="tt">.AppleDouble</Literal> below it so it can
store resource forks, etc. Think twice before
exporting <Literal remap="tt">/</Literal>; you will have a great time
cleaning up afterwards.
</Para>
</ListItem>
<ListItem>
<Para>
The <Emphasis>afpd</Emphasis> program expects clear text passwords
from the Macs. Security could be a problem, so be
very careful when you run this daemon on a machine
connected to the Internet. You only have yourself to blame
if somebody nasty does something bad!
</Para>
</ListItem>
<ListItem>
<Para>
The existing diagnostic tools (such as <Emphasis>netstat</Emphasis>
and <Emphasis>ifconfig</Emphasis>) don't support Appletalk. The raw
information is available in the <Literal remap="tt">/proc/net/</Literal>
directory.
</Para>
</ListItem>
</ItemizedList>
</Para>
</Sect2>
<Sect2>
<Title>More information</Title>
<Para>
For a much more detailed description of how to configure Appletalk for Linux,
refer to Anders Brownworth <Emphasis>Linux Netatalk-HOWTO</Emphasis> page at
<ULink
URL="http://thehamptons.com/anders/netatalk/">thehamptons.com</ULink>.
</Para>
</Sect2>
</Sect1>
<Sect1>
<Title>ATM</Title>
<Para>
Werner Almesberger <Literal remap="tt">&lt;werner.almesberger@lrc.di.epfl.ch&gt;</Literal> is
managing a project to provide Asynchronous Transfer Mode support for Linux.
Current information on the status of the project may be obtained from:
<ULink
URL="http://lrcwww.epfl.ch/linux-atm/">lrcwww.epfl.ch</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>AX25 (<Literal remap="tt">AF&lowbar;AX25</Literal>)</Title>
<Para>
AX.25 device names are `<Literal remap="tt">sl0</Literal>', `<Literal remap="tt">sl1</Literal>', etc. in <Literal remap="tt">2.0.*</Literal> kernels or
`<Literal remap="tt">ax0</Literal>', `<Literal remap="tt">ax1</Literal>', etc. in <Literal remap="tt">2.1.*</Literal> kernels.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] Amateur Radio AX.25 Level 2
</Screen>
</Para>
<Para>
The AX25, Netrom and Rose protocols are covered by the
<ULink URL="AX25-HOWTO.html">AX25-HOWTO</ULink>.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
</Para>
<Para>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor: <Literal remap="tt">jsn@cs.nott.ac.uk</Literal>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>DECNet</Title>
<Para>
Support for DECNet is currently a work in progress. You should expect it to
appear in a late <Literal remap="tt">2.1.*</Literal> kernel.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>FDDI</Title>
<Para>
FDDI device names are `<Literal remap="tt">fddi0</Literal>', `<Literal remap="tt">fddi1</Literal>', `<Literal remap="tt">fddi2</Literal>' etc. The first
card detected by the kernel is assigned `<Literal remap="tt">fddi0</Literal>' : the rest are assigned
sequentially in the order that they are detected.
</Para>
<Para>
Larry Stefani, <Literal remap="tt">lstefani@ultranet.com</Literal>, has developed a
driver for the Digital Equipment Corporation FDDI EISA and PCI cards.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] FDDI driver support
[*] Digital DEFEA and DEFPA adapter support
</Screen>
</Para>
<Para>
When you have your kernel built and installed to support the FDDI driver,
configuration of the FDDI interface is almost identical to that of an ethernet
interface. You just specify the appropriate FDDI interface name in the
<Emphasis>ifconfig</Emphasis> and <Emphasis>route</Emphasis> commands.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Frame Relay</Title>
<Para>
The Frame Relay device names are `<Literal remap="tt">dlci00</Literal>', `<Literal remap="tt">dlci01</Literal>' etc for the
DLCI encapsulation devices, and `<Literal remap="tt">sdla0</Literal>', `<Literal remap="tt">sdla1</Literal>' etc for the FRAD(s).
</Para>
<Para>
Frame Relay is a new networking technology that is designed to suit data
communications traffic that is of a `bursty' or intermittent nature. You
connect to a Frame Relay network using a Frame Relay Access Device (FRAD).
The Linux Frame Relay supports IP over Frame Relay as described in RFC-1490.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
&#60;*&#62; Frame relay DLCI support (EXPERIMENTAL)
(24) Max open DLCI
(8) Max DLCI per device
&#60;*&#62; SDLA (Sangoma S502/S508) support
</Screen>
</Para>
<Para>
Mike McLagan, <Literal remap="tt">mike.mclagan@linux.org</Literal>, developed the Frame Relay support
and configuration tools.
</Para>
<Para>
Currently the only FRAD I know of that are supported are
<ULink
URL="http://www.sangoma.com/">Sangoma Technologies</ULink>
<Literal remap="tt">S502A</Literal>, <Literal remap="tt">S502E</Literal> , <Literal remap="tt">S508</Literal>,
and the Emerging Technologies. The Emerging Technologies website is found at: <ULink
URL="http://www.etinc.com/">here</ULink>.
</Para>
<Para>
<Emphasis>
I would like to make a point at this juncture. I have personal experience with
Emerging Technologies, and I do not recommend them. I found thier staff to be
very unprofessional and extremely rude. If anyone else has been fortunate enough to have a good
experience with them, I would like to know. I will say this for Emerging Technologies:
their product is flexible, and it and appears to be stable.</Emphasis>
</Para>
<Para>
To configure the FRAD and DLCI devices (after you have rebuilt your kernel),
you will need the Frame Relay configuration tools. These are available from
<ULink
URL="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz">ftp.invlogic.com</ULink>.
</Para>
<Para>
Compiling and installing the tools is straightforward, but the lack of a
top level Makefile makes it a fairly manual process:
</Para>
<Para>
<Screen>
user% tar xvfz .../frad-0.15.tgz
user% cd frad-0.15
user% for i in common dlci frad; make -C $i clean; make -C $i; done
root# mkdir /etc/frad
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
root# install -m 700 -o root -g root frad/fradcfg /sbin
rppt# install -m 700 -o root -g root dlci/dlcicfg /sbin
</Screen>
</Para>
<Para>
Note that the previous commands use <Emphasis>sh</Emphasis> syntax. If you use a
<Emphasis>csh</Emphasis> flavour instead (like <Emphasis>tcsh</Emphasis>), the <Emphasis>for</Emphasis> loop will look
different.
</Para>
<Para>
After installing the tools, you need to create an
<Literal remap="tt">/etc/frad/router.conf</Literal> file. You can use this template (which
is a modified version of one of the example files):
</Para>
<Para>
<Screen>
# /etc/frad/router.conf
# This is a template configuration for frame relay.
# All tags are included. The default values are based on the code
# supplied with the DOS drivers for the Sangoma S502A card.
#
# A '#' anywhere in a line constitutes a comment.
# Blanks are ignored (you can indent with tabs too).
# Unknown [] entries and unknown keys are ignored .
#
[Devices]
Count=1 # number of devices to configure
Dev_1=sdla0 # the name of a device
#Dev_2=sdla1 # the name of a device
# Specified here, these are applied to all devices and can be overridden for
# each individual board.
#
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
#
# MTU=1500 # Maximum transmit IFrame length, default is 4096
# T391=10 # T391 value 5 - 30, default is 10
# T392=15 # T392 value 5 - 30, default is 15
# N391=6 # N391 value 1 - 255, default is 6
# N392=3 # N392 value 1 - 10, default is 3
# N393=4 # N393 value 1 - 10, default is 4
# Specified here, these set the defaults for all boards
# CIRfwd=16 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
#
# Device specific configuration
#
#
#
# The first device is a Sangoma S502E
#
[sdla0]
Type=Sangoma # Type of the device to configure, currently only
# SANGOMA is recognized
#
# These keys are specific to the 'Sangoma' type
#
# The type of Sangoma board - S502A, S502E, S508
Board=S502E
#
# The name of the test firmware for the Sangoma board
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
#
# The name of the FR firmware
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
#
Port=360 # Port for this particular card
Mem=C8 # Address of memory window, A0-EE, depending on card
IRQ=5 # IRQ number, do not supply for S502A
DLCIs=1 # Number of DLCI's attached to this device
DLCI_1=16 # DLCI #1's number, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
#
# Specified here, these apply to this device only,
# and override defaults from above
#
# Access=CPE # CPE or NODE, default is CPE
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal # External or Internal, default is Internal
# Baud=128 # Specified baud rate of attached CSU/DSU
# MTU=2048 # Maximum transmit IFrame length, default is 4096
# T391=10 # T391 value 5 - 30, default is 10
# T392=15 # T392 value 5 - 30, default is 15
# N391=6 # N391 value 1 - 255, default is 6
# N392=3 # N392 value 1 - 10, default is 3
# N393=4 # N393 value 1 - 10, default is 4
#
# The second device is some other card
#
# [sdla1]
# Type=FancyCard # Type of the device to configure.
# Board= # Type of Sangoma board
# Key=Value # values specific to this type of device
#
# DLCI Default configuration parameters
# These may be overridden in the DLCI specific configurations
#
CIRfwd=64 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
# DLCI Configuration
# These are all optional. The naming convention is
# [DLCI_D&#60;devicenum&#62;_&#60;DLCI_Num&#62;]
#
[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0
[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0
</Screen>
</Para>
<Para>
After you've built your <Literal remap="tt">/etc/frad/router.conf</Literal> file, the only
step remaining is to configure the actual devices. This is
only a little trickier than a normal network device configuration.
Remember to bring up the FRAD device before the DLCI
encapsulation devices. These commands are best hosted in a shell
script because of their number:
</Para>
<Para>
<Screen>
#!/bin/sh
# Configure the frad hardware and the DLCI parameters
/sbin/fradcfg /etc/frad/router.conf || exit 1
/sbin/dlcicfg file /etc/frad/router.conf
#
# Bring up the FRAD device
ifconfig sdla0 up
#
# Configure the DLCI encapsulation interfaces and routing
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#
</Screen>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>IPX (<Literal remap="tt">AF&lowbar;IPX</Literal>)</Title>
<Para>
The IPX protocol is most commonly utilized in Novell NetWare(tm) local area
network environments. Linux includes support for this protocol, and it may be
configured to act as a network endpoint (or, as a router for IPX).
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] The IPX protocol
[ ] Full internal IPX network
</Screen>
</Para>
<Para>
The IPX protocol and the NCPFS are covered in greater depth in the
<ULink
URL="IPX-HOWTO.html">IPX-HOWTO</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>NetRom (<Literal remap="tt">AF&lowbar;NETROM</Literal>)</Title>
<Para>
NetRom device names are `<Literal remap="tt">nr0</Literal>', `<Literal remap="tt">nr1</Literal>', etc.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] Amateur Radio AX.25 Level 2
[*] Amateur Radio NET/ROM
</Screen>
</Para>
<Para>
The AX25, Netrom and Rose protocols are covered by the
<ULink
URL="AX25-HOWTO.html">AX25-HOWTO</ULink>.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
</Para>
<Para>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor, <Literal remap="tt">jsn@cs.nott.ac.uk</Literal>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Rose protocol (<Literal remap="tt">AF&lowbar;ROSE</Literal>)</Title>
<Para>
Rose device names are `<Literal remap="tt">rs0</Literal>', `<Literal remap="tt">rs1</Literal>', etc. in <Literal remap="tt">2.1.*</Literal> kernels.
Rose is available in the <Literal remap="tt">2.1.*</Literal> kernels.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Networking options ---&#62;
[*] Amateur Radio AX.25 Level 2
&#60;*&#62; Amateur Radio X.25 PLP (Rose)
</Screen>
</Para>
<Para>
The AX25, Netrom and Rose protocols are covered by the
<ULink
URL="AX25-HOWTO.html">AX25-HOWTO</ULink>.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
</Para>
<Para>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor: <Literal remap="tt">jsn@cs.nott.ac.uk</Literal>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>SAMBA - `NetBEUI', `NetBios', `CIFS' support.</Title>
<Para>
SAMBA is an implementation of the Session Management Block protocol. Samba
allows Microsoft and other systems to mount and use your disks and printers.
</Para>
<Para>
SAMBA and its configuration are covered in detail in the
<ULink
URL="SMB-HOWTO.html">SMB-HOWTO</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>STRIP support (Starmode Radio IP)</Title>
<Para>
STRIP device names are `<Literal remap="tt">st0</Literal>', `<Literal remap="tt">st1</Literal>', etc.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
....
[*] Radio network interfaces
&#60; &#62; STRIP (Metricom starmode radio IP)
</Screen>
</Para>
<Para>
STRIP is a protocol designed (specifically for a range of Metricom
radio modems) for a research project being conducted by Stanford
University called the <ULink
URL="http://mosquitonet.Stanford.EDU/mosquitonet.html">MosquitoNet Project</ULink>. There is a lot of interesting reading
here (even if you aren't directly interested in the project).
</Para>
<Para>
The Metricom radios connect to a serial port, employ spread spectrum
technology and are typically capable of about 100kbps.
Information on the Metricom radios is available from:
<ULink
URL="http://www.metricom.com/">Metricom Web Server</ULink>.
</Para>
<Para>
The standard network tools and utilities currently do not support the
STRIP driver. You will have to download some customized tools from the
MosquitoNet web server. Details on what software you need is available at:
<ULink
URL="http://mosquitonet.Stanford.EDU/strip.html">MosquitoNet STRIP Page</ULink>.
</Para>
<Para>
A summary of the configuration is that you use a modified <Emphasis>slattach</Emphasis> program
to set the line discipline of a serial tty device to STRIP. Configure
the resulting `<Literal remap="tt">st[0-9]</Literal>' device as you would for ethernet with one
important exception: for technical reasons, STRIP does not support the ARP
protocol, so you must manually configure the ARP entries for each of the hosts
on your subnet. This shouldn't prove too onerous!
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Token Ring</Title>
<Para>
Token ring device names are `<Literal remap="tt">tr0</Literal>', `<Literal remap="tt">tr1</Literal>' etc. Token Ring is an
IBM standard LAN protocol that avoids collisions by providing a mechanism
that allows only one station on the LAN the right to transmit at a time.
A `token' is held by one station. This station is the only one
allowed to transmit. When it has transmitted
its data, it then passes the token onto the next station. The token loops amongst
all active stations; hence the name `Token Ring'.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
....
[*] Token Ring driver support
&#60; &#62; IBM Tropic chipset based adaptor support
</Screen>
</Para>
<Para>
Configuration of token ring is identical to that of ethernet except for
configuring the network device name.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>X.25</Title>
<Para>
X.25 is a circuit based packet switching protocol defined by the
<Literal remap="tt">C.C.I.T.T.</Literal> (a standards body recognized by Telecommunications companies
in most parts of the world). Implementations of X.25 and LAPB are currently being
worked on, and recent <Literal remap="tt">2.1.*</Literal> kernels include the work in progress.
</Para>
<Para>
Jonathon Naylor <Literal remap="tt">jsn@cs.nott.ac.uk</Literal> is leading the development.
A mailing list has been established to discuss Linux X.25 related matters.
If you'd like to subscribe, send a message to: <Literal remap="tt">majordomo@vger.rutgers.edu</Literal>. Be sure
to include the text "<Literal remap="tt">subscribe linux-x25</Literal>" in the body of the message.
</Para>
<Para>
Early versions of the configuration tools may be obtained from Jonathon's ftp
site at :<ULink
URL="ftp://ftp.cs.nott.ac.uk/jsn/">ftp.cs.nott.ac.uk</ULink>.
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>WaveLan Card</Title>
<Para>
Wavelan device names are `<Literal remap="tt">eth0</Literal>', `<Literal remap="tt">eth1</Literal>', etc.
</Para>
<Para>
<Emphasis>Kernel Compile Options</Emphasis>:
<Screen>
Network device support ---&#62;
[*] Network device support
....
[*] Radio network interfaces
....
&#60;*&#62; WaveLAN support
</Screen>
</Para>
<Para>
The WaveLAN card is a spread spectrum wireless lan card. The card looks
very much like an ethernet card, and it is configured in much the same
manner.
</Para>
<Para>
You can get information on the Wavelan card from
<ULink
URL="http://www.wavelan.com/">Wavelan.com</ULink>.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Cables and Cabling</Title>
<Para>
Those of you handy with a soldering iron may want to build your own cables
to interconnect two linux machines. The following cabling diagrams should
assist you with your little project.
</Para>
<Sect1>
<Title>Serial NULL Modem cable</Title>
<Para>
Not all NULL modem cables are alike. Many null modem cables do little more
than trick your computer into thinking all the appropriate signals are
present (and then swap transmit and receive data). This is ok, but it means that you
must use software flow control (XON/XOFF) that is less efficient than
hardware flow control. The following cable provides the best possible signalling
between machines, and it allows you to use hardware (RTS/CTS) flow control.
<Screen>
Pin Name Pin Pin
Tx Data 2 ----------------------------- 3
Rx Data 3 ----------------------------- 2
RTS 4 ----------------------------- 5
CTS 5 ----------------------------- 4
Ground 7 ----------------------------- 7
DTR 20 -\--------------------------- 8
DSR 6 -/
RLSD/DCD 8 ---------------------------/- 20
\- 6
</Screen>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Parallel port cable (PLIP cable)</Title>
<Para>
If you intend to use the PLIP protocol between two machines, then this cable
will work for you (irrespective of what sort of parallel ports you have
installed).
<Screen>
Pin Name pin pin
STROBE 1*
D0-&#62;ERROR 2 ----------- 15
D1-&#62;SLCT 3 ----------- 13
D2-&#62;PAPOUT 4 ----------- 12
D3-&#62;ACK 5 ----------- 10
D4-&#62;BUSY 6 ----------- 11
D5 7*
D6 8*
D7 9*
ACK-&#62;D3 10 ----------- 5
BUSY-&#62;D4 11 ----------- 6
PAPOUT-&#62;D2 12 ----------- 4
SLCT-&#62;D1 13 ----------- 3
FEED 14*
ERROR-&#62;D0 15 ----------- 2
INIT 16*
SLCTIN 17*
GROUND 25 ----------- 25
</Screen>
</Para>
<Para>
Notes:
<ItemizedList>
<ListItem>
<Para>
Do not connect the pins marked with an asterisk `*'.
</Para>
</ListItem>
<ListItem>
<Para>
Extra grounds are 18,19,20,21,22,23 and 24.
</Para>
</ListItem>
<ListItem>
<Para>
If the cable you are using has a metallic shield, it should be connected
to the metallic DB-25 shell at <Emphasis>one end only</Emphasis>.
</Para>
</ListItem>
</ItemizedList>
<Emphasis>Warning: A miswired PLIP cable can destroy your controller card.</Emphasis> Be
very careful! Be sure to double check every connection to ensure that you don't cause
yourself any unnecessary work or heartache.
</Para>
<Para>
While you may be able to run PLIP cables for long distances, you should
avoid it if you can. The specifications for the cable allow for a cable
length of about 1 meter or so. Please be very careful when running long
PLIP cables as sources of strong electromagnetic fields (such as lightning,
power lines, and radio transmitters) can interfere with and sometimes even
damage your controller. If you really want to connect two of your computers
over a large distance, then you really should be looking at obtaining a pair of
thin-net ethernet cards (and running some coaxial cable).
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>10base2 (thin coax) Ethernet Cabling</Title>
<Para>
10base2 is an ethernet cabling standard that specifies the use of 50 ohm
coaxial cable that has a diameter of about 5 millimeters. There are a couple of
important rules to remember when interconnecting machines with 10base2 cabling.
The first is that you must use terminators at <Emphasis>both ends</Emphasis> of the cabling.
A terminator is a 50 ohm resistor that helps to ensure that the signal is
absorbed (and not reflected) when it reaches the end of the cable. Without
a terminator at each end of the cabling, you may find that the ethernet is
unreliable (or doesn't work). Normally you'd use `T pieces' to
interconnect the machines. You would end up with something that looks like this:
</Para>
<Para>
<Screen>
|==========T=============T=============T==========T==========|
| | | |
| | | |
----- ----- ----- -----
| | | | | | | |
----- ----- ----- -----
</Screen>
</Para>
<Para>
The `<Literal remap="tt">&verbar;</Literal>' at either end represents a terminator, the
`<Literal remap="tt">======</Literal>' represents a length of coaxial cable with BNC plugs at either
end, and the `<Literal remap="tt">T</Literal>' represents a `T piece' connector. You should keep the
length of cable between the `T piece' and the actual ethernet card in the
PC as short as possible. The `T piece' will ideally be plugged directly into
the ethernet card.
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Twisted Pair Ethernet Cable</Title>
<Para>
If you have only two twisted pair ethernet cards (and you wish to connect
them), you do not require a hub. You can cable the two cards directly together.
A diagram showing how to do this is included in the
<ULink
URL="Ethernet-HOWTO.html">Ethernet-HOWTO</ULink>
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Glossary of Terms used in this document.</Title>
<Para>
The following is a list of some of the most important terms used in this
document.
<VariableList>
<VarListEntry>
<Term>ARP</Term>
<ListItem>
<Para>
This is an acronym for the <Emphasis>Address Resolution
Protocol</Emphasis> . It is how a network machine associates an
IP Address with a hardware address.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>ATM</Term>
<ListItem>
<Para>
This is an acronym for <Emphasis>Asynchronous Transfer
Mode</Emphasis>. An ATM network packages data into standard size
blocks which it can convey efficiently from point to
point. ATM is a circuit switched packet network technology.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Client</Term>
<ListItem>
<Para>
This is usually the piece of software at the end
of a system where the user is located. There are exceptions.
For example, in the X11 window system, it is actually the
server with the user and the client runs on the remote
machine. The client is the program (or end) of a system that is
receiving the service provided by the server. In the case of
<Emphasis>peer to peer</Emphasis> systems such as <Emphasis>slip</Emphasis> or <Emphasis>ppp</Emphasis>, the
client is taken to be the end that initiates the connection.
The remote end being called is taken to be the server.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Datagram</Term>
<ListItem>
<Para>
A datagram is a discrete package of data and
headers which contain addresses (which is the basic unit of
transmission across an IP network). You might also hear this
called a `packet'.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>DLCI</Term>
<ListItem>
<Para>
The DLCI is the Data Link Connection Identifier. It
is used to identify a unique virtual Point-to-Point connection
via a Frame Relay network. The DLCI's are normally assigned by
the Frame Relay network provider.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Frame Relay</Term>
<ListItem>
<Para>
Frame Relay is a network technology ideally
suited to carrying traffic that is of bursty or sporadic in
nature. Network costs are reduced by having many Frame Relay
customer sharing the same network capacity (and relying on them
wanting to make use of the network at slightly different
times).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Hardware address</Term>
<ListItem>
<Para>
This is a number that uniquely
identifies a host in a physical network at the media access
layer. Examples of this are <Emphasis>Ethernet Addresses</Emphasis> and
<Emphasis>AX.25 Addresses</Emphasis>.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>ISDN</Term>
<ListItem>
<Para>
This is an acronym for <Emphasis>Integrated Services
Digital Network</Emphasis>. ISDN provides a standardized means by
which Telecommunications companies may deliver either voice or
data information to a customers premises. ISDN is technically
a circuit switched data network.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>ISP</Term>
<ListItem>
<Para>
This is an acronym for an Internet Service
Provider. These are organizations or companies that provide
people with network connectivity to the Internet.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>IP address</Term>
<ListItem>
<Para>
This is a number that uniquely identifies a
TCP/IP host on the network. The address is 4 bytes long and is
usually represented in what is called the "dotted decimal
notation" (where each byte is represented in decimal from with
dots `.' between them).
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>MSS</Term>
<ListItem>
<Para>
The Maximum Segment Size (<Emphasis>MSS</Emphasis>) is the
largest quantity of data that can be transmitted at one
time. If you want to prevent local fragmentation, MSS would
equal MTU-IP header.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>MTU</Term>
<ListItem>
<Para>
The Maximum Transmission Unit (<Emphasis>MTU</Emphasis>) is a
parameter that determines the largest datagram than can be
transmitted by an IP interface (without it needing to be broken
down into smaller units). The MTU should be larger than the
largest datagram you wish to transmit unfragmented. Note: this
only prevents fragmentation locally. Some other link in the
path may have a smaller MTU: the datagram will be
fragmented at that point. Typical values are 1500 bytes for an
ethernet interface, or 576 bytes for a SLIP interface.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Route</Term>
<ListItem>
<Para>
The <Emphasis>route</Emphasis> is the path that your datagrams
take through the network to reach their destination.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Server</Term>
<ListItem>
<Para>
This is usually the piece of software or end of a
system remote from the user. The server provides some service
to one or many clients. Examples of servers include <Emphasis>ftp</Emphasis>,
<Emphasis>Networked File System</Emphasis>, or <Emphasis>Domain Name Server</Emphasis>. In the
case of <Emphasis>peer to peer</Emphasis> systems (such as <Emphasis>slip</Emphasis> or
<Emphasis>ppp</Emphasis> ), the server is taken to be the end of the link that is
called. The end calling is taken to be the client.
</Para>
</ListItem>
</VarListEntry>
<VarListEntry>
<Term>Window</Term>
<ListItem>
<Para>
The <Emphasis>window</Emphasis> is the largest amount of data
that the receiving end can accept at a given point in time.
</Para>
</ListItem>
</VarListEntry>
</VariableList>
</Para>
</Chapter>
<Chapter>
<Title>Authors</Title>
<Sect1>
<Title>Current</Title>
<Para>
Joshua D. Drake
</Para>
<Para><Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=Net-HOWTO_Donation&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
<Sect1>
<Title>Past</Title>
<Para>
Terry Dawson
Alessandro Rubini
<Ulink URL="https://secure.paypal.com/cgi-bin/webscr?cmd=_xclick&amp;business=auctions@commandprompt.com&amp;return=http://www.linuxdoc.com&amp;item_name=http://www.linuxdoc.com&amp;item_number=Net-HOWTO_Donation&amp;amount=2.50">Was this section helpful? Why not Donate $2.50?</Ulink></para>
</sect1>
</Chapter>
<Chapter>
<Title>Copyright.</Title>
<Para>
<Emphasis>Copyright Information</Emphasis>
</Para>
<Para>
The NET-3/4-HOWTO,NET-3, and Networking-HOWTO, information on how to install and configure networking
support for Linux. Copyright (c) 1997 Terry Dawson, 1998 Alessandro Rubini,
1999 & 2000 Joshua D. Drake &lcub;POET&rcub;/CommandPrompt, Inc. - <ULink
URL="http://www.linuxports.com/">http://www.linuxports.com/</ULink>
</Para>
<Para>
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version. This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public License for more details. You should have received a copy of the GNU
General Public License along with this program; if not, write to the: Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
</Para>
</Chapter>
</Book>
View Git Blame Copy Permalink