<!doctype linuxdoc system>

<article>
<title>Linux Networking-HOWTO (Previously the Net-3 Howto)
<author>Current Author: <em>unmaintained</em>
<date>v1.5, August 1999
<toc>
<p>
Original Authors: Terry Dawson (main author), VK2KTJ; Alessandro Rubini (maintainer)
<p>
Former Maintainer: Joshua Drake (Poet)
<p>
The Linux Operating System boasts kernel based networking support written
almost entirely from scratch. The performance of the tcp/ip implementation
in recent kernels makes it a worthy alternative to even the best of its peers.
This document aims to describe how to install and configure the Linux
networking software and associated tools.
<p>
<!-- Table of contents -->

<!-- Begin the document -->
<p>
<!--######################################################################-->
<sect><heading>Introduction.
<p>This is the first release since LinuxPorts has become the author of
this document. First let me say that we hope that over the next few months
you will find this document to be of use and that we are able to provide
accurate and timely information in regards to networking issues with Linux.
<p>
This document like the other howto's that we manage is going to become very
different, this document will shortly become the Networking-HOWTO not just
the Net-3(4) Howto. We will cover such items as PPP, VPN, and others...
<p>
<sect><heading>Document History
<p>The original NET-FAQ was written by Matt Welsh and Terry Dawson to
answer frequently asked questions about networking for Linux at a time
before the Linux Documentation Project had formally started. It
covered the very early development versions of the Linux Networking
Kernel. The NET-2-HOWTO superceded the NET-FAQ and was one of the
original LDP HOWTO documents, it covered what was called version 2 and
later version 3 of the Linux kernel Networking software. This document
in turn supercedes it and relates only to version 4 of the Linux
Networking Kernel or more specifically kernel releases 2.x and 2.2.x.

<p>Previous versions of this document became quite large because of
the enormous amount of material that fell within its scope. To help
reduce this problem a number of HOWTO's dealing with specific
networking topics have been produced. This document will provide
pointers to them where relevant and cover those areas not yet covered
by other documents.

<!--======================================================================-->
<sect1><heading>Feedback

<p>We are always interested in feedback. Please contact us at:
<htmlurl url="mailto:feedback@en.tldp.org" name="feedback@en.tldp.org">.
<p>Again, if you find anything erroneous or anything you would like to see
added, please contact us.
<!--######################################################################-->
<sect><heading>How to use this HOWTO.

<p>This document is organized top-down. The first sections include
informative material and can be skipped if you are not interested;
what follows is a generic discussion of networking issues, and you
must ensure you understand this before proceeding to more specific
parts. The rest, ``technology specific'' information is grouped in
three main sections: Ethernet and IP-related information, technologies
pertaining to widespread PC hardware and seldom-used technologies.

<p>The suggested path through the document is thus the following:

<descrip>
<p><tag>Read the generic sections</tag>These sections apply to every, or
	nearly every, technology described later and so are very
	important for you to understand. On the other hand, I expect
	many of the readers to be already confident with this material.

<p><tag>Consider your network</tag>You should know how your network is,
	or will be, designed and exactly what hardware and technology
	types you will be implementing.

<p><tag>Read the ``Ethernet and IP'' section if you are directly connected
	a LAN or the Internet</tag>This section describes basic
	Ethernet configuration and the various features that Linux offers
	for IP networks, like firewalling, advanced routing and so on.

<p><tag>Read the next section if you are interested in low-cost local
	networks or dial-up connections</tag>The section describes PLIP,
	PPP, SLIP and ISDN, the widespread technologies used on personal
	workstations.

<p><tag>Read the technology specific sections related to your
	requirements</tag>If your needs differ from IP and/or common
	hardware, the final section covers details specific to
	non-IP protocols and peculiar communication hardware.

<p><tag>Do the configuration work</tag>You should actually try to
	configure your network and take careful note of any problems
	you have. 

<p><tag>Look for further help if needed</tag>If you experience problems
	that this document does not help you to resolve then read the
	section related to where to get help or where to report bugs.

<p><tag>Have fun!</tag>Networking is fun, enjoy it.

</descrip>

<!--======================================================================-->
<sect1><heading>Conventions used in this document

<p>No special convention is used here, but you must be warned about
the way commands are shown. Following the classic Unix documentation,
any command you should type to your shell is prefixed by a
prompt. This howto shows "<tt>user%</tt>" as the prompt for commands
that do not require superuser privileges, and "<tt>root#</tt>" as the
prompt for commands that need to run as root. I chose to use
"<tt>root#</tt>" instead of a plain "<tt>#</tt>" to prevent confusion
with snapshots from shell scripts, where the hash mark is used to
define comment lines.

<p>When ``Kernel Compile Options'' are shown, they are represented in
the format used by <em/menuconfig/. They should be understandable even
if you (like me) are not used to <em/menuconfig/. If you are in doubt
about the options' nesting, running the program once can't but help.

<p>Note that any link to other HOWTO's is local to help you browsing
your local copy of the LDP documents, in case you are using the html
version of this document. If you don't have a complete set of
documents, every HOWTO can be retrieved from <tt>metalab.unc.edu</tt>
(directory <tt>/pub/Linux/HOWTO</tt>) and its countless mirrors.

<!--######################################################################-->
<sect><heading>General Information about Linux Networking.
<p>

<!--======================================================================-->
<sect1><heading>A brief history of Linux Networking Kernel Development.

<p>
Developing a brand new kernel implementation of the tcp/ip protocol stack
that would perform as well as existing implementations was not an easy task.
The decision not to port one of the existing implementations was made at a
time when there was some uncertainty as to whether the existing
implementations may become encumbered by restrictive copyrights because of the
court case put by U.S.L. and when there was a lot of fresh enthusiasm for
doing it differently and perhaps even better than had already been done.
<p>
The original volunteer to lead development of the kernel network code was
Ross Biro <tt/&lt;biro@yggdrasil.com>/. Ross produced a simple and
incomplete but mostly usable implementation set of routines that were
complemented by an ethernet driver for the WD-8003 network interface card.
This was enough to get many people testing and experimenting with the software
and some people even managed to connect machines in this configuration to live
internet connections. The pressure within the Linux community driving
development for networking support was building and eventually the cost of a
combination of some unfair pressure applied to Ross and his own personal
commitments outweighed the benefit he was deriving and he stepped down as
lead developer. Ross's efforts in getting the project started and accepting
the responsibility for actually producing something useful in such
controversial circumstances were what catalyzed all future work and were
therefore an essential component of the success of the current product.
<p>
Orest Zborowski <tt/&lt;obz@Kodak.COM>/ produced the original BSD socket
programming interface for the Linux kernel. This was a big step forward
as it allowed many of the existing network applications to be ported to
linux without serious modification.
<p>
Somewhere about this time Laurence Culhane <tt/&lt;loz@holmes.demon.co.uk>/
developed the first drivers for Linux to support the SLIP protocol. These
enabled many people who did not have access to Ethernet networking to
experiment with the new networking software. Again, some people took this
driver and pressed it into service to connect them to the Internet. This
gave many more people a taste of the possibilities that could be realized
if Linux had full networking support and grew the number of users actively
using and experimenting with the networking software that existed.
<p>
One of the people that had also been actively working on the task of building
networking support was Fred van Kempen <tt/&lt;waltje@uwalt.nl.mugnet.org>/.
After a period of some uncertainty following Ross's resignation from the lead
developer position Fred offered his time and effort and accepted the role
essentially unopposed. Fred had some ambitious plans for the direction that
he wanted to take the Linux networking software and he set about progressing
in those directions. Fred produced a series of networking code called the
`NET-2' kernel code (the `NET' code being Ross's) which many people were
able to use pretty much usefully. Fred formally put a number of innovations
on the development agenda, such as the dynamic device interface, Amateur Radio
AX.25 protocol support and a more modularly designed networking implementation.
Fred's NET-2 code was used by a fairly large number of enthusiasts, the number
increasing all the time as word spread that the software was working.
The networking software at this time was still a large number of patches to
the standard release of kernel code and was not included in the normal release.
The NET-FAQ and subsequent NET-2-HOWTO's described the then fairly complex
procedure to get it all working. Fred's focus was on developing innovations to
the standard network implementations and this was taking time. The community
of users was growing impatient for something that worked reliably and satisfied
the 80% of users and, as with Ross, the pressure on Fred as lead developer rose.
<p>
Alan Cox <tt/&lt;iialan@www.uk.linux.org>/ proposed a solution to the
problem designed to resolve the situation. He proposed that he would take
Fred's NET-2 code and debug it, making it reliable and stable so that it
would satisfy the impatient user base while relieving that pressure from
Fred allowing him to continue his work. Alan set about doing this, with some
good success and his first version of Linux networking code was called
`Net-2D(ebugged)'. The code worked reliably in many typical configurations and
the user base was happy. Alan clearly had ideas and skills of his own to
contribute to the project and many discussions relating to the direction the
NET-2 code was heading ensued. There developed two distinct schools within the
Linux networking community, one that had the philosophy of `make it work
first, then make it better' and the other of `make it better first'. Linus
ultimately arbitrated and offered his support to Alan's development efforts
and included Alan's code in the standard kernel source distribution.
This placed Fred in a difficult position. Any continued development would
lack the large user base actively using and testing the code and this would
mean progress would be slow and difficult. Fred continued to work for a short
time and eventually stood down and Alan came to be the new leader of the Linux
networking kernel development effort.
<p>
Donald Becker <tt>&lt;becker@cesdis.gsfc.nasa.gov></tt> soon revealed his
talents in the low level aspects of networking and produced a huge range of
ethernet drivers, nearly all of those included in the current kernels were
developed by Donald. There have been other people that have made significant
contributions, but Donald's work is prolific and so warrants special mention.
<p>
Alan continued refining the NET-2-Debugged code for some time while working on
progressing some of the matters that remained unaddressed on the `TODO' list.
By the time the Linux <tt/1.3.*/ kernel source had grown its teeth the kernel
networking code had migrated to the NET-3 release on which current versions
are based. Alan worked on many different aspects of the networking code and
with the assistance of a range of other talented people from the Linux
networking community grew the code in all sorts of directions. Alan produced
dynamic network devices and the first standard AX.25 and IPX implementations.
Alan has continued tinkering with the code, slowly restructuring and enhancing
it to the state it is in today.
<p>
PPP support was added by Michael Callahan <tt/&lt;callahan@maths.ox.ac.uk>/
and Al Longyear <tt/&lt;longyear@netcom.com>/ this too was critical to
increasing the number of people actively using linux for networking.
<p>
Jonathon Naylor <tt/&lt;jsn@cs.nott.ac.uk>/ has contributed by significantly
enhancing Alan's AX.25 code, adding NetRom and Rose protocol support.
The AX.25/NetRom/Rose support itself is quite significant, because no other
operating system can boast standard native support for these protocols beside
Linux.
<p>
There have of course been hundreds of other people who have made significant
contribution to the development of the Linux networking software. Some of these
you will encounter later in the technology specific sections, other
people have contributed modules, drivers, bug-fixes, suggestions, test
reports and moral support. In all cases each can claim to have played a part
and offered what they could. The Linux kernel networking code is an excellent
example of the results that can be obtained from the Linux style of anarchic
development, if it hasn't yet surprised you, it is bound to soon enough,
the development hasn't stopped.

<!--======================================================================-->
<sect1><heading>Linux Networking Resources.
<p>
There are a number of places where you can find good information about
Linux networking.
<p>
There are a wealth of Consultants available. A listing can be found at
<htmlurl url="http://www.linuxports.com/" name="LinuxPorts Consultants Database">
<p>
Alan Cox, the current maintainer of the Linux kernel networking code maintains
a world wide web page that contains highlights of current and new developments
in linux Networking at:
<htmlurl url="http://www.uk.linux.org/NetNews.html" name="www.uk.linux.org">.
<p>
Another good place is a book written by Olaf Kirch entitled the
<tt/Network Administrators Guide/. It is a work of the
<htmlurl url="http://www.linuxdoc.org/" name="Linux Documentation Project">
and you can read it interactively at
<htmlurl url="http://metalab.unc.edu/LDP/LDP/nag/nag.html"
	name="Network Administrators Guide HTML version">
or you can obtain it in various formats by ftp from the
<htmlurl url="ftp://metalab.unc.edu/pub/Linux/docs/LDP/network-guide/" name="metalab.unc.edu LDP ftp archive">. Olaf's book is quite
comprehensive and provides a good high level overview of network configuration
under linux.
<p>
There is a newsgroup in the Linux news hierarchy dedicated to networking
and related matters, it is:
<htmlurl url="news:comp.os.linux.networking" name="comp.os.linux.networking">
<p>
There is a mailing list to which you can subscribe where you may ask questions
relating to Linux networking. To subscribe you should send a mail message:
<tscreen><verb>
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:

subscribe linux-net
</verb></tscreen>
<p>
On the various IRC networks there are often <tt/#linux/ channels on
which people will be able to answer questions on linux networking.
<p>
Please remember when reporting any problem to include as much relevant detail
about the problem as you can. Specifically you should specify the versions of
software that you are using, especially the kernel version, the version of
tools such as <em/pppd/ or <em/dip/ and the exact nature of the problem
you are experiencing. This means taking note of the exact syntax of any error
messages you receive and of any commands that you are issuing.

<!--======================================================================-->
<sect1><heading>Where to get some non-linux-specific network information.
<p>
If you are after some basic tutorial information on tcp/ip networking
generally, then I recommend you take a look at the following documents:

<descrip>
<p><tag>tcp/ip introduction</tag> this document comes as both a <htmlurl
	url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc"
	name="text version"> and a <htmlurl
	url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps"
	name="postscript version">.

<p><tag>tcp/ip administration </tag> this document comes as both a
	<htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc"
	name="text version"> and a <htmlurl
	url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps"
	name="postscript version">.  
</descrip>

<p>If you are after some more detailed information on tcp/ip networking then
I highly recommend:

  <quote><em>Internetworking with TCP/IP, Volume 1: principles,
  protocols and architecture</em>, by Douglas E. Comer, ISBN
  0-13-227836-7, Prentice Hall publications, Third Edition,
  1995.</quote>

If you are wanting to learn about how to write network applications in
a Unix compatible environment then I also highly recommend:

  <quote><em>Unix Network Programming</em>, by W. Richard Stevens,
  ISBN 0-13-949876-1, Prentice Hall publications, 1990.</quote>

A second edition of this book is appearing on the bookshelves; the new
book is made up of three volumes: check <htmlurl url="http://www.phptr.com/"
name="Prenice-Hall's web site"> to probe further.

<p>You might also try the <htmlurl url="news:comp.protocols.tcp-ip"
name="comp.protocols.tcp-ip"> newsgroup.

<p>An important source of specific technical information relating to
the Internet and the tcp/ip suite of protocols are RFC's. RFC is an
acronym for `Request For Comment' and is the standard means of
submitting and documenting Internet protocol standards. There are many
RFC repositories. Many of these sites are ftp sites and other provide
World Wide Web access with an associated search engine that allows you
to search the RFC database for particular keywords.

<p>One possible source for RFC's is at <htmlurl
url="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html" name="Nexor
RFC database">.

<!--######################################################################-->
<sect><heading>Generic Network Configuration Information.
<p>
The following subsections you will pretty much need to know and understand
before you actually try to configure your network. They are fundamental
principles that apply regardless of the exact nature of the network you
wish to deploy.

<!--======================================================================-->
<sect1><heading>What do I need to start ?
<p>
Before you start building or configuring your network you will need some
things. The most important of these are:

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Current Kernel source(Optional).
<p>Please note:
<p>
The majority of current distributions come with networking enabled, therefore 
it may not be required to recompile the kernel. If you are running well known 
hardware you should be just fine. For example: 3COM NIC, NE2000 NIC, or a 
Intel NIC. However if you find yourself in the position that you do need to 
update the kernel, the following information is provided.
<p>
Because the kernel you are running now might not yet have support for the
network types or cards that you wish to use you will probably need the
kernel source so that you can recompile the kernel with the appropriate
options.
<p>
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.

<p>You can always obtain the latest kernel source from <htmlurl
url="ftp://ftp.cdrom.com/pub/linux/sunsite/kernel.org/pub/linux/kernel" name="ftp.cdrom.com">.
This is not the official site but they have LOTS of bandwidth and ALOT of
users allowed. The official site is kernel.org but please use the above if
you can. Please remember that ftp.kernel.org is seriously overloaded. Use a
mirror.

<p>Normally the kernel source will be untarred into the
<tt>/usr/src/linux</tt> directory. For information on how to apply
patches and build the kernel you should read the <htmlurl
url="Kernel-HOWTO.html" name="Kernel-HOWTO">.  For information on how
to configure kernel modules you should read the ``Modules
mini-HOWTO''. Also, the <tt>README</tt> file found in the kernel
sources and the <tt>Documentation</tt> directory are very informative
for the brave reader.

<p>Unless specifically stated otherwise, I recommend you stick with
the standard kernel release (the one with the even number as the
second digit in the version number). Development release kernels (the
ones with the odd second digit) may have structural or other changes
that may cause problems working with the other software on your
system. If you are uncertain that you could resolve those sorts of
problems in addition to the potential for there being other software
errors, then don't use them.

<p>On the other hand, some of the features described here have been
introduced during the development of 2.1 kernels, so you must take
your choice: you can stick to 2.0 while wait for 2.2 and an updated
distribution with every new tool, or you can get 2.1 and look around
for the various support programs needed to exploit the new
features. As I write this paragraph, in August 1998, 2.1.115 is
current and 2.2 is expected to appear pretty soon.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Current Network tools.
<p>
The network tools are the programs that you use to configure linux network
devices. These tools allow you to assign addresses to devices and configure
routes for example.
<p>
Most modern linux distributions are supplied with the network tools, so if
you have installed from a distribution and haven't yet installed the network
tools then you should do so.
<p>
If you haven't installed from a distribution then you will need to source and
compile the tools yourself. This isn't difficult.
<p>
The network tools are now maintained by Bernd Eckenfels and are available at:
<!-- NOTE: last checked fron RH-5.1, aug 98 -->
<htmlurl url="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/"
	name="ftp.inka.de"> and are mirrored at:
<htmlurl url="ftp://ftp.uk.linux.org/pub/linux/Networking/base/"
	name="ftp.uk.linux.org">.
<p>
You can also get the latest RedHat packages from <htmlurl
url="ftp://ftp.cdrom.com/pub/linux/redhat/redhat-6.0/i386/base/"
name="net-tools-1.51-3.i386.rpm">
<p>
Be sure to choose the version that is most appropriate for the kernel you
wish to use and follow the instructions in the package to install.
<p>
To install and configure the version current at the time of the writing you
need do the following:

	<tscreen><verb>
	user% tar xvfz net-tools-1.33.tar.gz
	user% cd net-tools-1.33
	user% make config
	user% make
	root# make install
	</verb></tscreen>
<p>
Or to use the Redhat packahges:
<p>
	<tscreen<verb>
	root# rpm -U net-tools-1.51-3.i386.rpm
	</verb></tscreen>
<p>

Additionally, if you intend configuring a firewall or using the IP masquerade
feature you will require the <em>ipfwadm</em> command. The latest version of
it may be obtained from:
	<htmlurl url="ftp:/ftp.xos.nl/pub/linux/ipfwadm" name="ftp.xos.nl">. Again
there are a number of versions available. Be sure to pick the version that
most closely matches your kernel. Note that the firewalling features of Linux
changed during 2.1 development and has been superceded by <em>ipchains</em>
in v2.2 of the kernel. <em>ipfwadm</em> only applies to version 2.0 of the
kernel. The following are known to be distributions with version 2.0 or
below of the kernel.

	<tscreen><verb>
	Redhat 5.2 or below
	Caldera pre version 2.2
	Slackware pre version 4.x
	Debian pre version 2.x
	</verb></tscreen>
<p>
To install and configure the version current at the time of this writing you
need to read the IPChains howto located at <htmlurl url="http://www.linuxdoc.org/"
name="The Linux Documentation Project">

<p>Note that if you run version 2.2 (or late 2.1) of the kernel,
<em/ipfwadm/ is not the right tool to configure firewalling. This version
of the NET-3-HOWTO currently doesn't deal with the new firewalling setup. If
you need more detailed information on ipchains please refer to the above.
<!-- FIXME: new firewall tools -->

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Network Application Programs.

<p> The network application programs are programs such as
<em>telnet</em> and <em>ftp</em> and their respective server
programs. David Holland has been managing a distribution of the most
common of these, which is now maintained by
<tt/netbug@ftp.uk.linux.org/.  You may obtain the distribution from:
<htmlurl url="ftp://ftp.uk.linux.org/pub/linux/Networking/base"
name="ftp.uk.linux.org">.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>IP Addresses, an Explanation.

<p>
Internet Protocol Addresses are composed of four bytes. The convention is
to write addresses in what is called `dotted decimal notation'. In this form
each byte is converted to a decimal number (0-255) dropping any leading
zero's unless the number is zero and written with each byte separated by a
`.' character. By convention each interface of a host or router has an IP
address. It is legal for the same IP address to be used on each interface of a
single machine in some circumstances but usually each interface will have its
own address.
<p>
Internet Protocol Networks are contiguous sequences of IP addresses. All
addresses within a network have a number of digits within the address in
common. The portion of the address that is common amongst all addresses
within the network is called the `network portion' of the address. The
remaining digits are called the `host portion'. The number of bits that
are shared by all addresses within a network is called the netmask and it
is role of the netmask to determine which addresses belong to the network it
is applied to and which don't. For example, consider the following:

	<tscreen><verb>
	-----------------  ---------------
	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
	-----------------  ---------------
	</verb></tscreen>
<p>
Any address that is 'bitwise anded' with its netmask will reveal the address
of the network it belongs to. The network address is therefore always the
lowest numbered address within the range of addresses on the network and
always has the host portion of the address coded all zeroes.
<p>
The broadcast address is a special address that every host on the network
listens to in addition to its own unique address. This address is the one
that datagrams are sent to if every host on the network is meant to receive
it. Certain types of data like routing information and warning messages
are transmitted to the broadcast address so that every host on the network
can receive it simultaneously. There are two commonly used standards for
what the broadcast address should be. The most widely accepted one is to
use the highest possible address on the network as the broadcast address.
In the example above this would be <tt>192.168.110.255</tt>. 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.
<p>
For administrative reasons some time early in the development of the IP
protocol some arbitrary groups of addresses were formed into networks and
these networks were grouped into what are called classes. These classes
provide a number of standard size networks that could be allocated. The ranges
allocated are:

	<tscreen><verb>
	----------------------------------------------------------
	| 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 |
	----------------------------------------------------------
	</verb></tscreen>

<p>
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:

<descrip>

<p><tag>Installing a linux machine on an existing IP network</tag>If
  you wish to install a linux machine onto an existing IP network then
  you should contact whoever administers the network and ask them for
  the following information:

	<itemize>
	<item>Host IP Address
	<item>IP network address
	<item>IP broadcast address
	<item>IP netmask
	<item>Router address
	<item>Domain Name Server Address
	</itemize>

  You should then configure your linux network device with those
  details.  You can not make them up and expect your configuration to
  work.

<p><tag>Building a brand new network that will never connect to the
  Internet</tag> 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:

	<tscreen><verb>
	-----------------------------------------------------------
	|         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 |
	-----------------------------------------------------------
	</verb></tscreen>

  You should first decide how large you want your network to be and then
  choose as many of the addresses as you require.
</descrip>

<!--======================================================================-->
<sect1><heading>Where should I put the configuration commands ?
<p>
There are a few different approaches to Linux system boot
procedures. After the kernel boots, it always executes a program
called `<em/init/'. The <em/init/ program then reads its configuration
file called <tt>/etc/inittab</tt> and commences the boot
process. There are a few different flavours of <em/init/ around,
although everyone is now converging to the System V (Five) flavor,
developed by Miguel van Smoorenburg.
<p>
Despite the fact that the <em/init/ program is always the same, the
setup of system boot is organized in a different way by each
distribution.
<p>
Usually the <tt>/etc/inittab</tt> file contains an entry looking something
like:

	<tscreen><verb>
	si::sysinit:/etc/init.d/boot
	</verb></tscreen>
<p>
This line specifies the name of the shell script file that actually manages
the boot sequence. This file is somewhat equivalent to the <tt/AUTOEXEC.BAT/
file in MS-DOS.
<p>
There are usually other scripts that are called by the boot script and often
the network is configured within one of many of these.
<p>
The following table may be used as a guide for your system:

<tscreen><verb>
---------------------------------------------------------------------------
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/*
---------------------------------------------------------------------------
</verb></tscreen>

<p>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 <tt>/etc/sysconfig</tt>, whence it is
retrieved by boot scripts). If you want to grasp the details of the
boot process, my suggestion is to check <em>/etc/inittab</em> and the
documentation that accompanies <em>init</em>. 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.

<p>Most modern distributions include a program that will allow you to
configure many of the common sorts of network interfaces. If you have
one of these then you should see if it will do what you want before
attempting a manual configuration.

<!-- FIXME: check where the config program lives in Slackw, RH, Deb -->
	<tscreen><verb>
	-----------------------------------------
	Distrib   | Network configuration program
	-----------------------------------------
	RedHat    | /usr/bin/netcfg
	Slackware | /sbin/netconfig
	-----------------------------------------
	</verb></tscreen>

<!--======================================================================-->
<sect1><heading>Creating your network interfaces.
<p>
In many Unix operating systems the network devices have appearances in the
<em>/dev</em> directory. This is not so in Linux. In Linux the network devices
are created dynamically in software and do not require device files to
be present.
<p>
In the majority of cases the network device is automatically created by the
device driver while it is initializing and has located your hardware. For
example, the ethernet device driver creates <tt/eth&lsqb;0..n]/ interfaces
sequentially as it locates your ethernet hardware. The first ethernet card
found becomes <tt/eth0/, the second <tt/eth1/ etc.
<p>
In some cases though, notably <em/slip/ and <em/ppp/, 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 <em/slip/ or <em/ppp/ devices may vary during the uptime of the
machine. These cases will be covered in more detail in later sections.

<!--======================================================================-->
<sect1><heading>Configuring a network interface.
<p>
When you have all of the programs you need and your address and network
information you can configure your network interfaces. When we talk about
configuring a network interface we are talking about the process of assigning
appropriate addresses to a network device and to setting appropriate values
for other configurable parameters of a network device. The program most
commonly used to do this is the <em/ifconfig/ (interface configure) command.
<p>
Typically you would use a command similar to the following:

	<tscreen><verb>
	root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
	</verb></tscreen>

<p>In this case I'm configuring an ethernet interface `<tt/eth0/' with the
IP address `<tt/192.168.0.1/' and a network mask of `<tt/255.255.255.0/'.
The `<em/up/' that trails the command tells the interface that it should
become active, but can usually be omitted, as it is the default. To
shutdown an interface, you can just call ``<tt>ifconfig eth0 down</tt>''.
<p>
The kernel assumes certain defaults when configuring interfaces. For example,
you may specify the network address and broadcast address for an interface,
but if you don't, as in my example above, then the kernel will make reasonable
guesses as to what they should be based on the netmask you supply and if you
don't supply a netmask then on the network class of the IP address configured.
In my example the kernel would assume that it is a class-C network
being configured on the interface and configure a network address of
`<tt/192.168.0.0/' and a broadcast address of `<tt/192.168.0.255/' for the
interface.

<p>There are many other options to the <em/ifconfig/ command. The most
important of these are:

	<descrip>
	<tag/up/this option activates an interface (and is the default).

	<tag/down/this option deactivates an interface.

	<tag/&lsqb;-]arp/this option enables or disables use of the
		address resolution protocol on this interface

	<tag/&lsqb;-]allmulti/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
		videoconferencing but is normally not used.

	<tag/mtu N/this parameter allows you to set the <em/MTU/ of
		this device.

	<tag/netmask &lt;addr>/this parameter allows you to set the network
		mask of the network this device belongs to.

	<tag/irq &lt;addr>/this parameter only works on certain types of
		hardware and allows you to set the IRQ of the hardware
		of this device.

	<tag/&lsqb;-]broadcast &lsqb;addr]/this parameter allows you
		to enable and set the accepting of datagrams destined
		to the broadcast address, or to disable reception of
		these datagrams.

	<tag/&lsqb;-]pointopoint &lsqb;addr]/this parameter allows you
		to set the address of the machine at the remote end of
		a point to point link such as for <em/slip/ or
		<em/ppp/.

	<tag/hw &lt;type> &lt;addr>/this parameter allows you to set
		the hardware address of certain types of network
		devices. This is not often useful for ethernet, but is
		useful for other network types such as AX.25.
	</descrip>

<p>You may use the <em/ifconfig/ command on any network interface. Some user
programs such as <em/pppd/ and <em/dip/ automatically configure the network
devices as they create them, so manual use of <em/ifconfig/ is unnecessary.

<!--======================================================================-->
<sect1><heading>Configuring your Name Resolver.

<p>The `<em/Name Resolver/' is a part of the linux standard library. Its prime
function is to provide a service to convert human-friendly hostnames like
`<tt/ftp.funet.fi/' into machine friendly IP addresses such as
<tt/128.214.248.6/.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>What's in a name ?

<p>You will probably be familiar with the appearance of Internet host
names, but may not understand how they are constructed, or
deconstructed. Internet domain names are hierarchical in nature, that
is, they have a tree-like structure. A `<em/domain/' is a family, or
group of names. A `<em/domain/' may be broken down into
`<em/subdomain/'. A `<em/toplevel domain/' 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:

	<!-- FIXME: add .firm and other top-level domains -->
	<descrip>
	<tag/COM/Commercial Organizations
	<tag/EDU/Educational Organizations
	<tag/GOV/Government Organizations
	<tag/MIL/Military Organizations
	<tag/ORG/Other organizations
	<tag/NET/Internet-Related Organizations
	<tag/Country Designator/these are two letters codes that
		represent a particular country.
	</descrip>

<p>For historical reasons most domains belonging to one of the
non-country based top level domains were used by organizations within
the United States, although the United States also has its own country
code `<tt/.us/'. This is not true any more for <tt/.com/ and <tt/.org/
domains, which are commonly used by non-us companies.

<p>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 <tt/com/, <tt/edu/, <tt/gov/, <tt/mil/ and
<tt/org/ domains. So for example you end up with: <tt/com.au/ and
<tt/gov.au/ 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.

<p>The next level of division usually represents the name of the
organization.  Further subdomains vary in nature, often the next level
of subdomain is based on the departmental structure of the
organization but it may be based on any criterion considered
reasonable and meaningful by the network administrators for the
organization.

<p>The very left-most portion of the name is always the unique name
assigned to the host machine and is called the `<em/hostname/', the
portion of the name to the right of the hostname is called the
`<em/domainname/' and the complete name is called the `<em/Fully
Qualified Domain Name/'.

<p>To use Terry's host as an example, the fully qualified domain name
is `<tt/perf.no.itg.telstra.com.au/'. This means that the host name is
`<tt/perf/' and the domain name is `<tt/no.itg.telstra.com.au/'. The
domain name is based on a top level domain based on his country,
Australia and as his email address belongs to a commercial
organization, `<tt/.com/' is there as the next level domain. The name
of the company is (was) `<tt/telstra/' and their internal naming
structure is based on organizational structure, in this case the
machine belongs to the Information Technology Group, Network
Operations section.

<p>Usually, the names are fairly shorter; for example, my ISP is
called ``<tt/systemy.it/'' and my non-profit organization is called
``<tt/linux.it/'', without any <tt/com/ and <tt/org/ subdomain, so
that my own host is just called ``<tt/morgana.systemy.it/'' and
<tt/rubini@linux.it/ 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 belong to uses the domain <tt/pluto.linux.it/,
because the owners of <tt/linux.it/ agreed to open a subdomain for the LUG.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>What information you will need.
<p>
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 `<em/Domain Name Server/', so you will need to know the IP
address of a local nameserver that you can use.
<p>
There are three files you need to edit, I'll cover each of these in turn.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/resolv.conf

<p>The <tt>/etc/resolv.conf</tt> is the main configuration file for
the name resolver code. Its format is quite simple. It is a text file
with one keyword per line. There are three keywords typically used,
they are:

	<descrip>
	<tag/domain/this keyword specifies the local domain name.
	<tag/search/this keyword specifies a list of alternate domain
		names to search for a hostname
	<tag/nameserver/this keyword, which may be used many times,
		specifies an IP address of a domain name server to
		query when resolving names
	</descrip>

<p>An example <tt>/etc/resolv.conf</tt> might look something like:

	<tscreen><verb>
	domain maths.wu.edu.au
	search maths.wu.edu.au wu.edu.au
	nameserver 192.168.10.1
	nameserver 192.168.12.1
	</verb></tscreen>

<p>This example specifies that the default domain name to append to unqualified
names (ie hostnames supplied without a domain) is <tt/maths.wu.edu.au/ and
that if the host is not found in that domain to also try the <tt/wu.edu.au/
domain directly. Two nameservers entry are supplied, each of which may be
called upon by the name resolver code to resolve the name.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/host.conf

<p>The <tt>/etc/host.conf</tt> file is where you configure some items that
govern the behaviour of the name resolver code. The format of this file
is described in detail in the `<tt/resolv+/' man page. In nearly all
circumstances the following example will work for you:

	<tscreen><verb>                          
	order hosts,bind                                          
	multi on  
	</verb></tscreen>

<p>This configuration tells the name resolver to check the <tt>/etc/hosts</tt>
file before attempting to query a nameserver and to return all valid addresses
for a host found in the <tt>/etc/hosts</tt> file instead of just the first.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/hosts

<p>The <tt>/etc/hosts</tt> file is where you put the name and IP
address of local hosts. If you place a host in this file then you do
not need to query the domain name server to get its IP Address. The
disadvantage of doing this is that you must keep this file up to date
yourself if the IP address for that host changes. In a well managed
system the only hostnames that usually appear in this file are an
entry for the loopback interface and the local hosts name.

	<tscreen><verb>
	# /etc/hosts
	127.0.0.1      localhost loopback
	192.168.0.1    this.host.name
	</verb></tscreen>

<p>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.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Running a name server

<p>If you want to run a local nameserver, you can do it easily. Please
refer to the <htmlurl url="DNS-HOWTO.html" name="DNS-HOWTO"> and to any
documents included in your version of <em/BIND/ (Berkeley Internet
Name Domain).

<!--======================================================================-->
<sect1><heading>Configuring your loopback interface.
<p>
The `<tt/loopback/' 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
`<tt/127.0.0.1/' has been assigned specifically for loopback. So no matter
what machine you go to, if you open a telnet connection to <tt/127.0.0.1/
you will always reach the local host.
<p>
Configuring the loopback interface is simple and you should ensure you do
(but note that this task is usually performed by the standard initialization
scripts).

	<tscreen><verb>
	root# ifconfig lo 127.0.0.1
	root# route add -host 127.0.0.1 lo
	</verb></tscreen>

<p>We'll talk more about the <em/route/ command in the next section.

<!--======================================================================-->
<sect1><heading>Routing.

<p>Routing is a big topic. It is easily possible to write large
volumes of text about it. Most of you will have fairly simple routing
requirements, some of you will not. I will cover some basic
fundamentals of routing only.  If you are interested in more detailed
information then I suggest you refer to the references provided at the
start of the document.

<p>Let's start with a definition. What is IP routing ? Here is one
that I'm using:

	<p><quote>IP Routing is the process by which a host with
	multiple network connections decides where to deliver IP
	datagrams it has received.</quote>

<p>It might be useful to illustrate this with an example. Imagine a typical
office router, it might have a PPP link off the Internet, a number of
ethernet segments feeding the workstations and another PPP link off to
another office. When the router receives a datagram on any of its network
connections, routing is the mechanism that it uses to determine which interface
it should send the datagram to next. Simple hosts also need to route, all
Internet hosts have two network devices, one is the loopback interface
described above and the other is the one it uses to talk to the rest of
the network, perhaps an ethernet, perhaps a PPP or SLIP serial interface.
<p>
Ok, so how does routing work ? Each host keeps a special list of routing
rules, called a routing table. This table contains rows which typically
contain at least three fields, the first is a destination address,
the second is the name of the interface to which the datagram is to be routed
and the third is optionally the IP address of another machine which will
carry the datagram on its next step through the network. In linux you
can see this table by using the following command:

	<tscreen><verb>
	user% cat /proc/net/route
	</verb></tscreen>

<p>or by using either of the following commands:

	<tscreen><verb>
	user% /sbin/route -n
	user% netstat -r
	</verb></tscreen>

<p>The routing process is fairly simple: an incoming datagram is received,
the destination address (who it is for) is examined and compared with
each entry in the table. The entry that best matches that address is
selected and the datagram is forwarded to the specified interface. If the
gateway field is filled then the datagram is forwarded to that host via
the specified interface, otherwise the destination address is assumed to
be on the network supported by the interface.
<p>
To manipulate this table a special command is used. This command takes
command line arguments and converts them into kernel system calls that
request the kernel to add, delete or modify entries in the routing table.
The command is called `<em/route/'.
<p>
A simple example. Imagine you have an ethernet network. You've been told
it is a class-C network with an address of <tt/192.168.1.0/. You've been
supplied with an IP address of <tt/192.168.1.10/ for your use and have
been told that <tt/192.168.1.1/ is a router connected to the Internet.
<p>
The first step is to configure the interface as described earlier. You would
use a command like:

	<tscreen><verb>
	root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
	</verb></tscreen>

<p>You now need to add an entry into the routing table to tell the kernel that
datagrams for all hosts with addresses that match <tt/192.168.1.*</tt> should
be sent to the ethernet device. You would use a command similar to:

	<tscreen><verb>
	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	</verb></tscreen>

<p>Note the use of the `<tt/-net/' argument to tell the route program that this
entry is a network route. Your other choice here is a `<tt/-host/' route which
is a route that is specific to one IP address.
<p>
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 ?
<p>
It would be a very difficult job to have to add routes to every possible
destination network, so there is a special trick that is used to simplify this
task. The trick is called the `<tt/default/' route. The <tt/default/ route
matches every possible destination, but poorly, so that if any other entry
exists that matches the required address it will be used instead of the
<tt/default/ route. The idea of the <tt/default/ route is simply to enable
you to say "and everything else should go here". In the example I've contrived
you would use an entry like:

	<tscreen><verb>
	root# route add default gw 192.168.1.1 eth0
	</verb></tscreen>

<p>The `<tt/gw/' argument tells the route command that the next argument is
the IP address, or name, of a gateway or router machine which all datagrams
matching this entry should be directed to for further routing.
<p>
So, your complete configuration would look like:

	<tscreen><verb>
	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
	</verb></tscreen>

<p>If you take a close look at your network `<tt/rc/' files you will find
that at least one of them looks very similar to this. This is a very common
configuration.
<p>
Let's now look at a slightly more complicated routing configuration. Let's
imagine we are configuring the router we looked at earlier, the one supporting
the PPP link to the Internet and the lan segments feeding the workstations in
the office. Lets imagine the router has three ethernet segments and one PPP
link. Our routing configuration would look something like:

	<tscreen><verb>
	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
	</verb></tscreen>

<p>Each of the workstations would use the simpler form presented
above, only the router needs to specify each of the network routes
separately because for the workstations the <tt/default/ route
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 `<tt/gw/'.  The reason for this is
simple, serial link protocols such as PPP and slip only ever 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 pointless and redundant as
there is no other choice, so you do not need to specify a gateway for
these types of network connections. Other network types such as
ethernet, arcnet or token ring do require the gateway to be specified
as these networks support large numbers of hosts on them.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>So what does the <em/routed/ program do ?
<p>
The routing configuration described above is best suited to simple network
arrangements where there are only ever single possible paths to destinations.
When you have a more complex network arrangement things get a little more
complicated. Fortunately for most of you this won't be an issue.
<p>
The big problem with `manual routing' or `static routing' as described, is
that if a machine or link fails in your network then the only way you can
direct your datagrams another way, if another way exists, is by manually
intervening and executing the appropriate commands. Naturally this is
clumsy, slow, impractical and hazard prone. Various techniques have been
developed to automatically adjust routing tables in the event of network
failures where there are alternate routes, all of these techniques are
loosely grouped by the term `dynamic routing protocols'.
<p>
You may have heard of some of the more common dynamic routing protocols. The
most common are probably RIP (Routing Information Protocol) and OSPF (Open
Shortest Path First Protocol). The Routing Information Protocol is very common
on small networks such as small-medium sized corporate networks or building
networks. OSPF is more modern and more capable at handling large network
configurations and better suited to environments where there is a large number
of possible paths through the network. Common implementations of these
protocols are: `<em/routed/' - RIP and `<em/gated/' - RIP, OSPF and others.
The `<em/routed/' program is normally supplied with your Linux distribution
or is included in the `NetKit' package detailed above.
<p>
An example of where and how you might use a dynamic routing protocol might
look something like the following:

<tscreen><verb>
    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

</verb></tscreen>

<p>We have three routers A, B and C. Each supports one ethernet segment with
a Class C IP network (netmask 255.255.255.0). Each router also has a PPP link
to each of the other routers. The network forms a triangle.
<p>
It should be clear that the routing table at router A could look like:

	<tscreen><verb>
	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
	root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
	</verb></tscreen>

<p>This would work just fine until the link between router A and B should fail.
If that link failed then with the routing entry shown above hosts on the
ethernet segment of A could not reach hosts on the ethernet segment on B
because their datagram would be directed to router A's ppp0 link which is
broken. They could still continue to talk to hosts on the ethernet segment
of C and hosts on the C's ethernet segment could still talk to hosts on
B's ethernet segment because the link between B and C is still intact.
<p>
But wait, if A can talk to C and C can still talk to B, why shouldn't A
route its datagrams for B via C and let C send them to B ? This is exactly
the sort of problem that dynamic routing protocols like RIP were designed
to solve. If each of the routers A, B and C were running a routing daemon
then their routing tables would be automatically adjusted to reflect the
new state of the network should any one of the links in the network fail.
To configure such a network is simple, at each router you need only do
two things. In this case for Router A:

	<tscreen><verb>
	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# /usr/sbin/routed
	</verb></tscreen>

<p>The `<em/routed/' routing daemon automatically finds all active network
ports when it starts and sends and listens for messages on each of the
network devices to allow it to determine and update the routing table
on the host.
<p>
This has been a very brief explanation of dynamic routing and where you would
use it. If you want more information then you should refer to the suggested
references listed at the top of the document.
<p>
The important points relating to dynamic routing are:

	<enum>

	<item>You only need to run a dynamic routing protocol daemon
		when your Linux machine has the possibility of
		selecting multiple possible routes to a destination.
		An example of this would be if you plan to use 
		IP Masquerading.
	
	<item>The dynamic routing daemon will automatically modify
		your routing table to adjust to changes in your
		network.

	<item>RIP is suited to small to medium sized networks.
	</enum>

<!--======================================================================-->
<sect1><heading>Configuring your network servers and services.
<p>
Network servers and services are those programs that allow a remote user to
make user of your Linux machine. Server programs listen on network ports.
Network ports are a means of addressing a particular service on any particular
host and are how a server knows the difference between an incoming telnet
connection and an incoming ftp connection. The remote user establishes a
network connection to your machine and the server program, the network daemon
program, listening on that port accepts the connection and executes. There are
two ways that network daemons may operate. Both are commonly employed in
practice. The two ways are:

	<descrip>

	<p><tag>standalone</tag>the network daemon program listens on the
		designated network port and when an incoming
		connection is made it manages the network connection
		itself to provide the service.

	<p><tag>slave to the <em/inetd/ server</tag>the <em/inetd/ server
		is a special network daemon program that specializes
		in managing incoming network connections. It has a
		configuration file which tells it what program needs
		to be run when an incoming connection is received. Any
		service port may be configured for either of the tcp
		or udp protcols. The ports are described in another
		file that we will talk about soon.

	</descrip>

<p>There are two important files that we need to configure. They are the
<tt>/etc/services</tt> file which assigns names to port numbers and the
<tt>/etc/inetd.conf</tt> file which is the configuration file for the
<em/inetd/ network daemon.

<!-- -------------------------------------------------------------------- -->
<sect2><heading><tt>/etc/services</tt>
<p>
The <tt>/etc/services</tt> file is a simple database that associates a
human friendly name to a machine friendly service port. Its format is
quite simple. The file is a text file with each line representing and
entry in the database. Each entry is comprised of three fields separated by
any number of whitespace (tab or space) characters. The fields
are:

  <verb>
  name      port/protocol        aliases     # comment
  </verb>

	<descrip>

	<p><tag>name</tag>a single word name that represents the service
		being described.

	<p><tag>port/protocol</tag>this field is split into two subfields.
	
		
		<p><tag>port</tag>a number that specifies the port number
			the named service will be available on. Most
			of the common services have assigned service
			numbers. These are described in
			<tt>RFC-1340</tt>.
		<p><tag>protocol</tag>this subfield may be set to either
			<tt>tcp</tt> or <tt>udp</tt>.

	It is important to note that an entry of <tt>18/tcp</tt> is
	very different from an entry of <tt>18/udp</tt> and that there
	is no technical reason why the same service needs to exist on
	both. Normally common sense prevails and it is only if a
	particular service is available via both <tt>tcp</tt> and
	<tt>udp</tt> that you will see an entry for both.

	<p><tag>aliases</tag>other names that may be used to refer to
		this service entry.

	</descrip>

<p>Any text appearing in a line after a `<tt/#/' character is ignored and treated
as a comment.

<!-- .................................................................... -->
<sect3>An example <tt>/etc/services</tt> file.
<p>
All modern linux distributions provide a good <tt>/etc/services</tt> file.
Just in case you happen to be building a machine from the ground up, here is
a copy of the <tt>/etc/services</tt> file supplied with an old
<htmlurl url="http://www.debian.org/" name="Debian"> distribution:

<tscreen><verb>
# /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 Protocol
re-mail-ck	50/udp				# Remote Mail Checking Protocol
domain		53/tcp		nameserver	# name-domain server
domain		53/udp		nameserver
mtp		57/tcp				# deprecated
bootps		67/tcp				# BOOTP server
bootps		67/udp
bootpc		68/tcp				# BOOTP client
bootpc		68/udp
tftp		69/udp
gopher		70/tcp				# Internet Gopher
gopher		70/udp
rje		77/tcp		netrjs
finger		79/tcp
www		80/tcp		http		# WorldWideWeb HTTP
www		80/udp				# HyperText Transfer Protocol
link		87/tcp		ttylink
kerberos	88/tcp		kerberos5 krb5	# Kerberos v5
kerberos	88/udp		kerberos5 krb5	# Kerberos v5
supdup		95/tcp
# 100 - reserved
hostnames	101/tcp		hostname	# usually from sri-nic
iso-tsap	102/tcp		tsap		# part of ISODE.
csnet-ns	105/tcp		cso-ns		# also used by CSO name server
csnet-ns	105/udp		cso-ns
rtelnet		107/tcp				# Remote Telnet
rtelnet		107/udp
pop-2		109/tcp		postoffice	# POP version 2
pop-2		109/udp
pop-3		110/tcp				# POP version 3
pop-3		110/udp
sunrpc		111/tcp		portmapper	# RPC 4.0 portmapper TCP
sunrpc		111/udp		portmapper	# RPC 4.0 portmapper UDP
auth		113/tcp		authentication tap ident
sftp		115/tcp
uucp-path	117/tcp
nntp		119/tcp		readnews untp	# USENET News Transfer Protocol
ntp		123/tcp
ntp		123/udp				# Network Time Protocol
netbios-ns	137/tcp				# NETBIOS Name Service
netbios-ns	137/udp
netbios-dgm	138/tcp				# NETBIOS Datagram Service
netbios-dgm	138/udp
netbios-ssn	139/tcp				# NETBIOS session service
netbios-ssn	139/udp
imap2		143/tcp				# Interim Mail Access Proto v2
imap2		143/udp
snmp		161/udp				# Simple Net Mgmt Proto
snmp-trap	162/udp		snmptrap	# Traps for SNMP
cmip-man	163/tcp				# ISO mgmt over IP (CMOT)
cmip-man	163/udp
cmip-agent	164/tcp
cmip-agent	164/udp
xdmcp		177/tcp				# X Display Mgr. Control Proto
xdmcp		177/udp
nextstep	178/tcp		NeXTStep NextStep	# NeXTStep window
nextstep	178/udp		NeXTStep NextStep	# server
bgp		179/tcp				# Border Gateway Proto.
bgp		179/udp
prospero	191/tcp				# Cliff Neuman's Prospero
prospero	191/udp
irc		194/tcp				# Internet Relay Chat
irc		194/udp
smux		199/tcp				# SNMP Unix Multiplexer
smux		199/udp
at-rtmp		201/tcp				# AppleTalk routing
at-rtmp		201/udp
at-nbp		202/tcp				# AppleTalk name binding
at-nbp		202/udp
at-echo		204/tcp				# AppleTalk echo
at-echo		204/udp
at-zis		206/tcp				# AppleTalk zone information
at-zis		206/udp
z3950		210/tcp		wais		# NISO Z39.50 database
z3950		210/udp		wais
ipx		213/tcp				# IPX
ipx		213/udp
imap3		220/tcp				# Interactive Mail Access
imap3		220/udp				# Protocol v3
ulistserv	372/tcp				# UNIX Listserv
ulistserv	372/udp
#
# UNIX specific services
#
exec		512/tcp
biff		512/udp		comsat
login		513/tcp
who		513/udp		whod
shell		514/tcp		cmd		# no passwords used
syslog		514/udp
printer		515/tcp		spooler		# line printer spooler
talk		517/udp
ntalk		518/udp
route		520/udp		router routed	# RIP
timed		525/udp		timeserver
tempo		526/tcp		newdate
courier		530/tcp		rpc
conference	531/tcp		chat
netnews		532/tcp		readnews
netwall		533/udp				# -for emergency broadcasts
uucp		540/tcp		uucpd		# uucp daemon
remotefs	556/tcp		rfs_server rfs	# Brunhoff remote filesystem
klogin		543/tcp				# Kerberized `rlogin' (v5)
kshell		544/tcp		krcmd		# Kerberized `rsh' (v5)
kerberos-adm	749/tcp				# Kerberos `kadmin' (v5)
#
webster		765/tcp				# Network dictionary
webster		765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations.  For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined.  This list specifies the port used by the server process as its
#> contact port.  While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
#
ingreslock	1524/tcp
ingreslock	1524/udp
prospero-np	1525/tcp		# Prospero non-privileged
prospero-np	1525/udp
rfe		5002/tcp		# Radio Free Ethernet
rfe		5002/udp		# Actually uses UDP only
bbs		7000/tcp		# BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial.  Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4	750/udp		kdc	# Kerberos (server) udp
kerberos4	750/tcp		kdc	# Kerberos (server) tcp
kerberos_master	751/udp			# Kerberos authentication
kerberos_master	751/tcp			# Kerberos authentication
passwd_server	752/udp			# Kerberos passwd server
krb_prop	754/tcp			# Kerberos slave propagation
krbupdate	760/tcp		kreg	# Kerberos registration
kpasswd		761/tcp		kpwd	# Kerberos "passwd"
kpop		1109/tcp		# Pop with Kerberos
knetd		2053/tcp		# Kerberos de-multiplexor
zephyr-srv	2102/udp		# Zephyr server
zephyr-clt	2103/udp		# Zephyr serv-hm connection
zephyr-hm	2104/udp		# Zephyr hostmanager
eklogin		2105/tcp		# Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv	871/tcp			# SUP server
supfiledbg	1127/tcp		# SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp		1/ddp			# Routing Table Maintenance Protocol
nbp		2/ddp			# Name Binding Protocol
echo		4/ddp			# AppleTalk Echo Protocol
zip		6/ddp			# Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg		1236/tcp		# Gracilis Packeten remote config server
xtel		1313/tcp		# french minitel
cfinger		2003/tcp		# GNU Finger
postgres	4321/tcp		# POSTGRES
mandelspawn	9359/udp	mandelbrot	# network mandelbrot

# Local services
</verb></tscreen>

<p>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 <tt>/etc/services</tt> from a recent distribution.

<!-- -------------------------------------------------------------------- -->
<sect2><heading><tt>/etc/inetd.conf</tt>
<p>
The <tt>/etc/inetd.conf</tt> file is the configuration file for the
<em/inetd/ server daemon. Its function is to tell <em/inetd/ what to do
when it receives a connection request for a particular service. For each
service that you wish to accept connections for you must tell <em/inetd/
what network server daemon to run and how to run it.
<p>
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 `<tt/#/'
is ignored and considered a comment. Each line contains seven fields separated
by any number of whitespace (tab or space) characters. The general format
is as follows:

  <tscreen><verb>
  service  socket_type  proto  flags  user  server_path  server_args
  </verb></tscreen>

	<descrip>

	<p><tag>service</tag>is the service relevant to this
		configuration as taken from the <tt>/etc/services</tt>
		file.

	<p><tag>socket_type</tag>this field describes the type of socket
		that this entry will consider relevant, allowable
		values are: <tt/stream/, <tt/dgram/, <tt/raw/,
		<tt/rdm/, or <tt/seqpacket/. This is a little
		technical in nature, but as a rule of thumb nearly all
		<tt/tcp/ based services use <tt/stream/ and nearly all
		<tt/udp/ based services use <tt/dgram/. It is only
		very special types of server daemons that would use
		any of the other values.

	<p><tag>proto</tag>the protocol to considered valid for this
		entry. This should match the appropriate entry in the
		<tt>/etc/services</tt> file and will typically be
		either <tt/tcp/ or <tt/udp/. Sun RPC (Remote Procedure
		Call) based servers will use <tt>rpc/tcp</tt> or
		<tt>rpc/udp</tt>.

	<p><tag>flags</tag>there are really only two possible settings
		for this field.  This field setting tells <em/inetd/
		whether the network server program frees the socket
		after it has been started and therefore whether
		<em/inetd/ can start another one on the next
		connection request, or whether <em/inetd/ should wait
		and assume that any server daemon already running will
		handle the new connection request. Again this is a
		little tricky to work out, but as a rule of thumb all
		<tt/tcp/ servers should have this entry set to
		<tt/nowait/ and most <tt/udp/ servers should have this
		entry set to <tt/wait/. Be warned there are some
		notable exceptions to this, so let the example guide
		you if you are not sure.

	<p><tag>user</tag>this field describes which user account from
		<tt>/etc/passwd</tt> 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
		<tt/nobody/ user so that if the network server
		security is breached the possible damage is minimized.
		Typically this field is set to <tt/root/ though,
		because many servers require root privileges in order
		to function correctly.

	<p><tag>server_path</tag>this field is pathname to the actual
		server program to execute for this entry.

	<p><tag>server_args</tag>this field comprises the rest of the
		line and is optional. This field is where you place
		any command line arguments that you wish to pass to
		the server daemon program when it is launched.

	</descrip>

<!-- .................................................................... -->
<sect3>An example <tt>/etc/inetd.conf</tt>
<p>
As for the <tt>/etc/services</tt> file all modern distributions will include
a good <tt>/etc/inetd.conf</tt> file for you to work with. Here, for
completeness is the <tt>/etc/inetd.conf</tt> file from the
<htmlurl url="http://www.debian.org/" name="Debian"> distribution.

<tscreen><verb>
# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# 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
</verb></tscreen>

<!--======================================================================-->
<sect1><heading>Other miscellaneous network related configuration files.
<p>
There are a number of miscellaneous files relating to network configuration
under linux that you might be interested in. You may never have to modify
these files, but it is worth describing them so you know what they contain
and what they are for.

<!-- -------------------------------------------------------------------- -->
<sect2><heading><tt>/etc/protocols</tt>
<p>
The <tt>/etc/protocols</tt> file is a database that maps protocol id numbers
against protocol names. This is used by programmers to allow them to
specify protocols by name in their programs and also by some programs
such as <em>tcpdump</em> to allow them to display names instead of numbers
in their output. The general syntax of the file is:

  <tscreen><verb>
  protocolname  number  aliases
  </verb></tscreen>

<p>The <tt>/etc/protocols</tt> file supplied with the
<htmlurl url="http://www.debian.org/" name="Debian"> distribution is as follows:

<tscreen><verb>
# /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 Message Transport
rspf	73	RSPF		# Radio Shortest Path First.
vmtp	81	VMTP		# Versatile Message Transport
ospf	89	OSPFIGP		# Open Shortest Path First IGP
ipip	94	IPIP		# Yet Another IP encapsulation
encap	98	ENCAP		# Yet Another IP encapsulation
</verb></tscreen>


<!-- -------------------------------------------------------------------- -->
<sect2><heading><tt>/etc/networks</tt>
<p>
The <tt>/etc/networks</tt> file has a similar function to that of the
<tt>/etc/hosts</tt> file. It provides a simple database of network names
against network addresses. Its format differs in that there may be
only two fields per line and that the fields are coded as:

  <tscreen><verb>
  networkname networkaddress
  </verb></tscreen>

An example might look like:

	<tscreen><verb>
	loopnet    127.0.0.0
	localnet   192.168.0.0
	amprnet    44.0.0.0
	</verb></tscreen>

<p>When you use commands like the <em>route</em> command, if a destination is
a network and that network has an entry in the <tt>/etc/networks</tt> file
then the route command will display that network name instead of its
address.

<!--======================================================================-->
<sect1><heading>Network Security and access control.
<p>
Let me start this section by warning you that securing your machine and
network against malicious attack is a complex art. I do not consider myself
an expert in this field at all and while the following mechanisms I describe
will help, if you are serious about security then I recommend you do some
research of your own into the subject. There are many good references on the
Internet relating to the subject, including the <htmlurl
url="Security-HOWTO.html" name="Security-HOWTO">
<p>
An important rule of thumb is:
	`<bf>Don't run servers you don't intend to use</bf>'.
Many distributions come configured with all sorts of services configured and
automatically started. To ensure even a minimum level of safety you should go
through your <tt>/etc/inetd.conf</tt> file and comment out (<em>place a `#' at
the start of the line</em>) any entries for services you don't intend to use.
Good candidates are services such as: <tt/shell/, <tt/login/, <tt/exec/,
<tt/uucp/, <tt/ftp/ and informational services such as <tt/finger/,
<tt/netstat/ and <tt/systat/.
<p>
There are all sorts of security and access control mechanisms, I'll describe
the most elementary of them.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/ftpusers
<p>
The <tt>/etc/ftpusers</tt> file is a simple mechanism that allows you to
deny certain users from logging into your machine via ftp. The
<tt>/etc/ftpusers</tt> file is read by the ftp daemon program (<em/ftpd/) when
an incoming ftp connection is received. The file is a simple list of those
users who are disallowed from logging in. It might looks something like:

	<tscreen><verb>
	# /etc/ftpusers - users not allowed to login via ftp
	root
	uucp
	bin
	mail
	</verb></tscreen>

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/securetty
<p>
The <tt>/etc/securetty</tt> file allows you to specify which <tt/tty/ devices
<tt/root/ is allowed to login on. The <tt>/etc/securetty</tt> file is read
by the login program (usually <em>/bin/login</em>). Its format is a list of
the tty devices names allowed, on all others <tt/root/ login is disallowed:

	<tscreen><verb>
	# /etc/securetty - tty's on which root is allowed to login
	tty1
	tty2
	tty3
	tty4
	</verb></tscreen>

<!-- -------------------------------------------------------------------- -->
<sect2><heading>The <em>tcpd</em> hosts access control mechanism.
<p>
The <em>tcpd</em> program you will have seen listed in the same
<tt>/etc/inetd.conf</tt> provides logging and access control mechanisms to
services it is configured to protect.
<p>
When it is invoked by the <em>inetd</em> program it reads two files containing
access rules and either allows or denies access to the server it is protecting
accordingly.
<p>
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: <tt>/etc/hosts.allow</tt>, <tt>/etc/hosts.deny</tt>.
I'll describe each of these in turn. For a complete description of this
facility you should refer to the appropriate <em>man</em> pages
(<tt>hosts_access(5)</tt> is a good starting point).

<!-- .................................................................... -->
<sect3><heading>/etc/hosts.allow
<p>
The <tt>/etc/hosts.allow</tt> file is a configuration file of the
<em>/usr/sbin/tcpd</em> program. The <tt>hosts.allow</tt> file contains
rules describing which hosts are <em>allowed</em> access to a service on
your machine.
<p>
The file format is quite simple:

	<tscreen><verb>
	# /etc/hosts.allow
	#
	# <service list>: <host list> [: command]
	</verb></tscreen>

	<descrip>
	<p><tag><tt/service list/ </tag>is a comma delimited list of
		server names that this rule applies to.  Example
		server names are: <tt/ftpd/, <tt/telnetd/ and
		<tt/fingerd/.

	<p><tag><tt/host list/ </tag>is a comma delimited list of host
		names. You may also use IP addresses here. You may
		additionally specify hostnames or addresses using
		wildcard characters to match groups of hosts. Examples
		include: <tt/gw.vk2ktj.ampr.org/ to match a specific
		host, <tt>.uts.edu.au</tt> to match any hostname
		ending in that string, <tt>44.</tt> to match any IP
		address commencing with those digits.  There are some
		special tokens to simplify configuration, some of
		these are: <tt/ALL/ matches every host, <tt/LOCAL/
		matches any host whose name does not contain a
		`<tt/./' ie is in the same domain as your machine and
		<tt/PARANOID/ matches any host whose name does not
		match its address (name spoofing). There is one last
		token that is also useful. The <tt/EXCEPT/ token
		allows you to provide a list with exceptions. This
		will be covered in an example later.

	<p><tag><tt/command/ </tag>is an optional parameter. This
		parameter is the full pathname of a command that would
		be executed everytime this rule is matched. It could
		for example run a command that would attempt to
		identify who is logged onto the connecting host, or to
		generate a mail message or some other warning to a
		system administrator that someone is attempting to
		connect. There are a number of expansions that may be
		included, some common examples are: <tt/%h/ expands to
		the name of the connecting host or address if it
		doesn't have a name, <tt/%d/ the daemon name being
		called.

</descrip>

<p>An example:

  <tscreen><verb>
  # /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)
  </verb></tscreen>

<!-- .................................................................... -->
<sect3><heading>/etc/hosts.deny
<p>
The <tt>/etc/hosts.deny</tt> file is a configuration file of the
<em>/usr/sbin/tcpd</em> program. The <tt>hosts.deny</tt> file contains
rules describing which hosts are <em>disallowed</em> access to a service on
your machine.
<p>
A simple sample would look something like this:

  <tscreen><verb>
  # /etc/hosts.deny
  #
  # Disallow all hosts with suspect hostnames
  ALL: PARANOID
  #
  # Disallow all hosts.
  ALL: ALL
  </verb></tscreen>

<p>The <tt>PARANOID</tt> entry is really redundant because the other entry traps
everything in any case. Either of these entry would make a reasonable default
depending on your particular requirement.
<p>
Having an <tt>ALL: ALL</tt> default in the <tt>/etc/hosts.deny</tt> and then
specifically enabling on those services and hosts that you want in the
<tt>/etc/hosts.allow</tt> file is the safest configuration.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>/etc/hosts.equiv
<p>
The <tt/hosts.equiv/ 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 a
security hazard otherwise. Your machine is only as secure as the least secure
of the trusted hosts. To maximize security, don't use this mechanism and
encourage your users not to use the <tt/.rhosts/ file as well.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Configure your <em/ftp/ daemon properly.
<p>
Many sites will be interested in running an anonymous <em/ftp/ 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
<em/ftp/ daemon properly for anonymous access. Most <em/man/ pages for
<tt>ftpd(8)</tt> describe in some length how to go about this. You should
always ensure that you follow these instructions. An important tip is to
not use a copy of your <tt>/etc/passwd</tt> file in the anonymous account
<tt>/etc</tt> 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.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Network Firewalling.
<p>
Not allowing datagrams to even reach your machine or servers is an
excellent means of security. This is covered in depth in the <htmlurl
url="Firewall-HOWTO.html" name="Firewall-HOWTO">, and (more concisely)
in a later section of this document.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Other suggestions.
<p>
Here are some other, potentially religious suggestions for you to consider.

	<descrip>
	<p><tag>sendmail</tag>despite its popularity the <em/sendmail/
		daemon appears with frightening regularity on security
		warning announcements. Its up to you, but I choose not
		to run it.

	<p><tag>NFS and other Sun RPC services</tag>be wary of
		these. There are all sorts of possible exploits for
		these services. It is difficult finding an option to
		services like NFS, but if you configure them, make
		sure you are careful with who you allow mount rights
		to.
	</descrip>

<!-- FIXME: check everything from here onwards -->
<!--######################################################################-->
<sect><heading>IP- and Ethernet-Related Information

<p>This section covers information specific to Ethernet and IP. These
subsections have been grouped together because I think they are the
most interesting ones in the formerly-called ``Technology Specific''
Section. Anyone with a LAN should be able to benefit from these
goodies.

<!--======================================================================-->
<sect1><heading>Ethernet
<p>
Ethernet device names are `<tt/eth0/', `<tt/eth1/', `<tt/eth2/' etc. The first
card detected by the kernel is assigned `<tt/eth0/' and the rest are assigned
sequentially in the order they are detected.
<p>
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.
<p>
To learn how to make your ethernet card(s) working under Linux you
should refer to the <htmlurl url="Ethernet-HOWTO.html"
name="Ethernet-HOWTO">.
<p>
Once you have your kernel properly built to support your ethernet card then
configuration of the card is easy.
<p>
Typically you would use something like (which most distributions already
do for you, if you configured them to support your ethernet):
<p>
	<tscreen><verb>
	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
	</verb></tscreen>

<p>
Most of the ethernet drivers were developed by Donald Becker,
<tt/becker@CESDIS.gsfc.nasa.gov/.


<!--======================================================================-->
<sect1><heading>EQL - multiple line traffic equaliser
<p>
The EQL device name is `<tt/eql/'. 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.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    [*] Network device support
	    <*> EQL (serial line load balancing) support
	</verb></tscreen>

<p>
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.
<p>
To configure EQL you will need the eql tools which are available from:
<htmlurl url="ftp://metalab.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz"
	name="metalab.unc.edu">.
<p>
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 <em/ifconfig/ utility, so something
like:

	<tscreen><verb>
	root# ifconfig eql 192.168.10.1 mtu 1006
	</verb></tscreen>

<p>
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.
<p>
Lastly you need to associate the serial link with the EQL device, this is
called `enslaving' and is done with the <em/eql_enslave/ command as shown:

	<tscreen><verb>
	root# eql_enslave eql sl0 28800
	root# eql_enslave eql ppp0 14400
	</verb></tscreen>

<p>The `<em>estimated speed</em>' parameter you supply <em/eql_enslave/ doesn't
do anything directly. It is used by the EQL driver to determine what share of
the datagrams that device should receive, so you can fine tune the balancing of
the lines by playing with this value.
<p>
To disassociate a line from an EQL device you use the <em/eql_emancipate/
command as shown:

	<tscreen><verb>
	root# eql_emancipate eql sl0
	</verb></tscreen>

<p>
You add routing as you would for any other point to point link, except your
routes should refer to the <tt/eql/ device rather than the actual serial
devices themselves, typically you would use:

	<tscreen><verb>
	root# route add default eql
	</verb></tscreen>

<p>
The EQL driver was developed by Simon Janes, <tt/simon@ncm.com/.

<!--======================================================================-->
<sect1><heading>IP Accounting (for Linux-2.0)
<p>
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 whatever purpose you may have. This option has been
removed in kernel 2.1.102, because the old ipfwadm-based firewalling
was replaced by ``ipfwchains''.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] IP: accounting
	</verb></tscreen>

<p>After you have compiled and installed the kernel you need to use the
<em/ipfwadm/ command to configure IP accounting. There are many different
ways of breaking down the accounting information that you might choose.
I've picked a simple example of what might be useful to use, you should
read the <em/ipfwadm/ man page for more information.
<p>
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 and that 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.
<p>
You might use a command set that looks like the following, which is shown as a
shell script:

	<tscreen><verb>
	#!/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
	#
	</verb></tscreen>

<p>The names ``ftp-data'' and ``www'' refer to lines in
<tt>/etc/services</tt>.  The last command lists each of the Accounting
rules and displays the collected totals.

<p>An important point to note when analyzing IP accounting is that
<bf/totals for all rules that match will be incremented/ so that to
obtain differential figures you need to perform appropriate maths. For
example if I wanted to know how much data was not ftp nor www I would
substract the individual totals from the rule that matches all ports.

<tscreen><verb>
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       * -> 20
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            20 -> *
   10  1166 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 80
   10   572 out tcp  44.136.8.96/29       0.0.0.0/0            80 -> *
  252 10943 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  231 18831 out tcp  44.136.8.96/29       0.0.0.0/0             * -> *
    0     0 in  udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 out udp  44.136.8.96/29       0.0.0.0/0            * -> *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 20
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            20 -> *
   10  1166 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 80
   10   572 out tcp  0.0.0.0/0            0.0.0.0/0            80 -> *
  253 10983 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  231 18831 out tcp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 out udp  0.0.0.0/0            0.0.0.0/0            * -> *
</verb></tscreen>

<!--======================================================================-->
<sect1><heading>IP Accounting (for Linux-2.2)
<!-- FIXME: describe the new accounting code -->

<p>The new accounting code is accessed via ``IP Firewall Chains''.
See <htmlurl
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
name="the IP chains home page"> for more information.  Among other
things, you'll now need to use <em/ipchains/ instead of <tt/ipfwadm/
to configure your filters. (From <tt>Documentation/Changes</tt> in the
latest kernel sources).

<!--======================================================================-->
<sect1><heading>IP Aliasing

<p>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' to their
World Wide Web and ftp offerings for their customers. You can refer to
the ``IP-Alias mini-HOWTO'' for more information than you find here.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    ....
	    [*] Network aliasing
	    ....
	    <*> IP: aliasing support
	</verb></tscreen>

<p>After compiling and installing your kernel with IP_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 <tt>&lt;devname>:&lt;virtual
dev num></tt>, e.g. <tt/eth0:0/, <tt/ppp0:10/ etc. Note that the
ifname:number device can only be configured <em>after</em> the main
interface has been set up.

<p>
For example, assume you have an ethernet network that supports two different
IP subnetworks simultaneously and you wish your machine to have direct access
to both, you could use something like:

	<tscreen><verb>
	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
	</verb></tscreen>

<p>To delete an alias you simply add a `<tt/-/' to the end of its name and refer
to it and is as simple as:

	<tscreen><verb>
	root# ifconfig eth0:0- 0
	</verb></tscreen>

<p>All routes associated with that alias will also be deleted automatically.

<!--======================================================================-->
<sect1><heading>IP Firewall (for Linux-2.0)
<p>
IP Firewall and Firewalling issues are covered in more depth in the
<htmlurl url="Firewall-HOWTO.html" name="Firewall-HOWTO">. 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.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] Network firewalls
	    ....
	    [*] IP: forwarding/gatewaying
	    ....
	    [*] IP: firewalling
	    [ ] IP: firewall packet logging
	</verb></tscreen>

<p>Configuration of the IP firewall rules is performed using the <em/ipfwadm/
command. As I mentioned earlier, security is not something I am expert at,
so while I will present an example you can use, you should do your own
research and develop your own rules if security is important to you.
<p>
Probably the most common use of IP firewall is when you are using your
linux machine as a router and firewall gateway to protect your local
network from unauthorized access from outside your network.
<p>
The following configuration is based on a contribution from Arnt Gulbrandsen,
<tt>&lt;agulbra@troll.no&gt;</tt>.
<p>
The example describes the configuration of the firewall rules on the Linux
firewall/router machine illustrated in this diagram:

<tscreen><verb>
-                                   -
 \                                  | 172.16.37.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |  172.16.174.30 | Linux |      |
NET =================|  f/w  |------|    ..37.19
    |    PPP         | router|      |  --------
   /                 ---------      |--| Mail |
  /                                 |  | /DNS |
 /                                  |  --------
-                                   -
</verb></tscreen>

<p>The following commands would normally be placed in an <tt/rc/ file
so that they were 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.

	<tscreen><verb>
	#!/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
	</verb></tscreen>

<p>Good firewall configurations are a little tricky. This example
should be a reasonable starting point for you. The <em/ipfwadm/
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 and get
someone to test/sanity check your configuration from the outside.

<!--======================================================================-->
<sect1><heading>IP Firewall (for Linux-2.2)
<!-- FIXME: describe the new firewalling code -->

<p>The new firewalling code is accessed via ``IP Firewall Chains''.
See <htmlurl
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
name="the IP chanins home page"> for more information.  Among other
things, you'll now need to use <em/ipchains/ instead of <tt/ipfwadm/
to configure your filters. (From <tt>Documentation/Changes</tt> in the
latest kernel sources).
<p>
We are aware that this is a sorely out of date statement and we are
currently working on getting this section more current. You can expect a
newer version in August of 1999.


<!--======================================================================-->
<sect1><heading>IPIP Encapsulation
<p>
Why would you want to encapsulate IP datagrams within IP datagrams? It must
seem an odd thing to do if you've never seen an application of it before.
Ok, here are a couple of common places where it is used: Mobile-IP and
IP-Multicast. What is perhaps the most widely spread use of it though is
also the least well known, Amateur Radio.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] TCP/IP networking
	    [*] IP: forwarding/gatewaying
	    ....
	    <*> IP: tunneling
	</verb></tscreen>
<p>
IP tunnel devices are called `<tt/tunl0/', `<tt/tunl1/' etc.
<p>
"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, but it means that you may only use any particular
IP address while you are connected to the particular piece of network to which
it belongs. In most instances this is ok, but if you are a mobile netizen 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 some
other IP network for some time you can set up a machine on your home network
to accept datagrams to your IP address and redirect them to the address that
you will actually be using temporarily.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>A tunneled network configuration.
<p>

<tscreen><verb>
 192.168.1/24                          192.168.2/24

     -                                     -
     |      ppp0 =            ppp0 =       |
     |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |       //        |     |   |
     |---|  A  |------//---------|  B  |---|
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |                                     |
     -                                     -
</verb></tscreen>

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 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. 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 still need tricks like IP Masquerade for that.
Encapsulation is normally performed by machine functioning as routers.
<p>
Linux router `<tt/A/' would be configured with a script like the following:

	<tscreen><verb>
	#!/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
	</verb></tscreen>

<p>
Linux router `<tt/B/' would be configured with a similar script:

	<tscreen><verb>
	#!/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
	</verb></tscreen>

<p>
The command:

	<tscreen><verb>
	route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
	</verb></tscreen>

reads: `Send any datagrams destined for <tt>192.168.1.0/24</tt> inside an
IPIP encap datagram with a destination address of <tt/aaa.bbb.ccc.ddd/'.
<p>
Note that the configurations are reciprocated at either end. The tunnel device
uses the `<tt/gw/' in the route as the <em/destination/ of the IP datagram
in which it will place the datagram it has received to route. That machine
must know how to decapsulate IPIP datagrams, that is, it must also be
configured with a tunnel device.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>A tunneled host configuration.
<p>
It doesn't have to be a whole network you route. You could for example route
just a single IP address. In that instance you might configure the <tt/tunl/
device on the `remote' machine with its home IP address and at the A end just
use 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 `<tt/B/' which to 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 `<tt/A/':
<p>
<tscreen><verb>
 192.168.1/24

     -
     |      ppp0 =                ppp0 =
     |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
     |
     |   /-----\                 /-----\
     |   |     |       //        |     |
     |---|  A  |------//---------|  B  |
     |   |     |     //          |     |
     |   \-----/                 \-----/
     |                      also: 192.168.1.12
     -
</verb></tscreen>
<p>
Linux router `<tt/A/' would be configured with:

	<tscreen><verb>
	#!/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
	</verb></tscreen>

<p>Linux host `<tt/B/' would be configured with:

	<tscreen><verb>
	#!/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
	</verb></tscreen>

<p>This sort of configuration is more typical of a Mobile-IP application. Where
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 that is handled in practice.

<!--======================================================================-->
<sect1><heading>IP Masquerade
<p>
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, by causing the
other hosts to look like, hence the term masquerade, the machine supporting
the dialup connection. There is a small caveat and that is that the
masquerade function nearly always 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 <em/talk/ and others such as <em/ftp/ must be configured
to operate in passive (PASV) mode to operate. Fortunately the most common
network services such as <em/telnet/, World Wide Web and <em/irc/ do work
just fine.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Code maturity level options  --->
	    [*] Prompt for development and/or incomplete code/drivers
	Networking options  --->
	    [*] Network firewalls
	    ....
	    [*] TCP/IP networking
	    [*] IP: forwarding/gatewaying
	    ....
	    [*] IP: masquerading (EXPERIMENTAL)
	</verb></tscreen>

<p>Normally you have your linux machine supporting a slip or PPP dialup line
just as it would if it were a standalone machine. Additionally it would have
another network device configured, perhaps an ethernet, configured 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.
<p>
A typical configuration might look something like this:

<tscreen><verb>
-                                   -
 \                                  | 192.168.1.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |                | Linux | .1.1 |
NET =================| masq  |------|
    |    PPP/slip    | router|      |  --------
   /                 ---------      |--| host |
  /                                 |  |      |
 /                                  |  --------
-                                   -
</verb></tscreen>

<em>Masquerading with IPFWADM</em>
<p>The most relevant commands for this configuration are:

	<tscreen><verb>
	# 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 
	</verb></tscreen>
<p>
<em>Masquerading with IPCHAINS</em>
<p>This is similar to using IPFWADM but the command structure has changed:

 <tscreen><verb>
        # 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
        </verb></tscreen>

<p>You can get more information on the Linux IP Masquerade feature from the
<htmlurl url="http://www.hwy401.com/achau/ipmasq/"
	name="IP Masquerade Resource Page">. Also, a <em/very/
detailed document about masquesrading is the ``IP-Masquerade mini-HOWTO''
(which also intructs to configure other OS's to run with a Linux
masquerade server).
<p>
<!--======================================================================-->
<sect1><heading>IP Transparent Proxy
<p>
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.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Code maturity level options  --->
		[*] Prompt for development and/or incomplete code/drivers
	Networking options  --->
		[*] Network firewalls
		....
		[*] TCP/IP networking
		....
		[*] IP: firewalling
		....
		[*] IP: transparent proxy support (EXPERIMENTAL)
	</verb></tscreen>

<p>Configuration of the transparent proxy feature is performed using the
<em/ipfwadm/ command
<P>
An example that might be useful is as follows:

	<tscreen><verb>
	root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
	</verb></tscreen>

<p>This example will cause any connection attempts to port <tt/telnet/
(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 need.
<p>
A more interesting example is redirecting all <tt/http/ traffic
through a local cache. However, the protocol used by proxy servers is
different from native http: where a client connects to
<tt/www.server.com:80/ and asks for <tt>/path/page</tt>, when it
connects to the local cache it contacts <tt/proxy.local.domain:8080/
and asks for <tt>www.server.com/path/page</tt>.
<p>
To filter an <tt/http/ request through the local proxy, you need to
adapt the protocol by inserting a small server, called
<tt/transproxy/ (you can find it on the world wide web). You can choose
to run <tt/transproxy/ on port 8081, and issue this command:

	<tscreen><verb>
	root# ipfwadm -I -a accept -D 0/0 80 -r 8081
	</verb></tscreen>

The <tt/transproxy/ program, then, will receive all connections meant
to reach external servers and will pass them to the local proxy
after fixing protocol differences.

<!-- FIXME: talk about the cisco trick -->

<!--======================================================================-->
<sect1><heading>IPv6
<p>
<!-- FIXME: describe IPV6 -->
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 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.
<p>
Linux already has a working, but not complete, IPv6 implementation in
the <tt/2.2.*/ series kernels.
<p>
If you wish to experiment with this next generation Internet technology, or
have a requirement for it, then you should read the 
IPv6-FAQ which is available from <htmlurl url="http://www.terra.net/ipv6/"
	name="www.terra.net">.

<!--======================================================================-->
<sect1><heading>Mobile IP
<p>
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 and using IP encapsulation (tunneling) with automatic routing
to ensure that datagrams destined for it are routed to the actual IP address
it is currently using.
<p>
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 the: 
<htmlurl url="http://anchor.cs.binghamton.edu/~mobileip/"
	name="Linux Mobile IP Home Page">.

<!--======================================================================-->
<sect1><heading>Multicast
<p>
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 and other novel applications.
<p>
<bf/Kernel Compile Options/:
<tscreen><verb>
Networking options  --->
	[*] TCP/IP networking
	....
	[*] IP: multicasting
</verb></tscreen>
<p>
A suite of tools and some minor network configuration is required.
Please check the <htmlurl url="Multicast-HOWTO.html" name="Multicast-HOWTO">
for more information on Multicast support in Linux.

<!--======================================================================-->
<sect1><heading>NAT - Network Address Translation
<p>
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 that make it eminently more suitable for use in
corporate firewall router designs and larger scale installations.
<p>
An alpha implementation of NAT for Linux 2.0.29 kernel has been developed by
Michael.Hasenstein, <tt/Michael.Hasenstein@informatik.tu-chemnitz.de/. Michaels
documentation and implementation are available from:

<htmlurl name="Linux IP Network Address Web Page"
	url="http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html">
<p>
Newer Linux 2.2.x kernels also include some NAT functionality in the routing
algorithm.

<!--======================================================================-->
<sect1><heading>Traffic Shaper - Changing allowed bandwidth

<p>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 can be used as
outgoing routed for network traffic.

<p>The shaper was introduced in Linux-2.1.15 and was backported to
Linux-2.0.36 (it appeared in <tt/2.0.36-pre-patch-2/ distributed by Alan
Cox, the author of the shaper device and maintainer of Linux-2.0).

<p>The traffic shaper can only be compiled as a module and is
configured by the <em/shapecfg/ program with commands like the following:

	<tscreen><verb>
	shapecfg attach shaper0 eth1
	shapecfg speed shaper0 64000
	</verb></tscreen>

<p>The shaper device can only control the bandwidth of outgoing
traffic, as packets are transmitted via the shaper only according to
the routing tables; therefore, a ``route by source address''
functionality could help in limiting the overall bandwidth of specific
hosts using a Linux router.

<p>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
<tt/ftp.invlogic.com/. Refer to
<tt/Documentation/networking/shaper.txt for further information about
the shaper.

<p>If you want to try out a (tentative) shaping for incoming packets,
try out <tt>rshaper-1.01</tt> (or newer), from <htmlurl
url="ftp://ftp.systemy.it/pub/develop" name="ftp.systemy.it">.

<!--======================================================================-->
<sect1><heading>Routing in Linux-2.2

<p>
The latest versions of Linux, 2.2 offer a lot of flexibility in routing
policy. Unfortunately, you have to wait for the next version of this howto,
or go read the kernel sources.
<p>
<!-- FIXME: routing in linux-2.2 -->

<!--######################################################################-->
<sect><heading>Using common PC hardware
<p>
<!--======================================================================-->
<sect1><heading>ISDN
<p>
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 to establish 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 in any combination. You could for example establish 30 separate calls
to 30 different destinations at 64kbps each, or you could establish 15 calls
to 15 different destinations at 128kbps each (two channels used per call), or
just a small number of calls and leave 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 which could
deliver either telephone (via digitised voice) or data services to your home
or business without requiring you to make any special configuration changes.
<p>
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' which plugs into the
Network Terminating Unit that you telecommunications carrier will have
installed when you got your ISDN service and presents a number of serial
interfaces. One of those interfaces is used to enter commands to establish
calls and configuration and the others are actually connected to the network
devices that will 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.
Another way, which is the way the kernel ISDN support is designed for allows
you to install an ISDN card into your Linux machine and then has your Linux
software handle the protocols and make the calls itself.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	ISDN subsystem  --->
		<*> ISDN support
		[ ] Support synchronous PPP
		[ ] Support audio via ISDN
		< > ICN 2B and 4B support
		< > PCBIT-D support
		< > Teles/NICCY1016PC/Creatix support
	</verb></tscreen>

<p>The Linux implementation of ISDN supports a number of different types of
internal ISDN cards. These are those listed in the kernel configuration
options:

	<itemize>
	<item/ICN 2B and 4B/
	<item/Octal PCBIT-D/
	<item/Teles ISDN-cards and compatibles/
	</itemize>

<p>Some of these cards require software to be downloaded to them to make them
operational. There is a separate utility to do this with.
<p>
Full details on how to configure the Linux ISDN support is available from
the <tt>/usr/src/linux/Documentation/isdn/</tt> directory and an FAQ dedicated
to <em>isdn4linux</em> is available at
<htmlurl url="http://www.lrz-muenchen.de/~ui161ab/www/isdn/"
	name="www.lrz-muenchen.de">.
(You can click on the english flag to get an english version).
<p>
<bf/A note about PPP/. The PPP suite of protocols will operate over
either asynchronous or synchronous serial lines. The commonly distributed
PPP daemon for Linux `<em/pppd/' 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 it are available in the documentation
referred to above.

<!--======================================================================-->
<sect1><heading>PLIP for Linux-2.0
<p>
PLIP device names are `<tt/plip0/', `<tt/plip1/ and <tt/plip2/.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    <*> PLIP (parallel port) support
	</verb></tscreen>                            

<p><em/plip/ (Parallel Line IP), is like SLIP, in that it is used for
providing a <em/point to point/ network connection between two machines,
except that it is designed to use the parallel printer ports on your machine
instead of 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 <em/plip/ interface than with a standard serial device.
In addition, even the simplest of parallel ports, 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 and is
most certainly not a good option if you can obtain some cheap ethernet cards,
but 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.
<p>
The PLIP device drivers 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 to ensure that you are able to select which
port you want to use for PLIP and which ports you want for the printer driver.
Refer to the ``Mudules mini-HOWTO'' for more
information on kernel module configuration.
<p>
Please note that some laptops use chipsets that will not work with PLIP
because they do not allow some combinations of signals that PLIP relies on,
that printers don't use.
<p>
The Linux <em/plip/ interface is compatible with the <em/Crynwyr Packet
Driver PLIP/ and this will mean that you can connect your Linux machine
to a DOS machine running any other sort of tcp/ip software via <em/plip/.
<p>
In the 2.0.* series kernel the plip devices are mapped to i/o port and IRQ as
follows:

	<tscreen><verb>
	device	i/o	IRQ
	------	-----	---
	plip0	0x3bc	5
	plip1	0x378	7
	plip2	0x278	2
	</verb></tscreen>

<p>If your parallel ports don't match any of the above combinations then you
can change the IRQ of a port using the <em/ifconfig/ command using the
`<tt/irq/' 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 ``<tt/io=/'' annd ``<tt/irq=/'' options on the <em/insmod/
command line, if you use modules. For example:

	<tscreen><verb>
	root# insmod plip.o io=0x288 irq=5
	</verb></tscreen>

<p>PLIP operation is controlled by two timeouts, whose default values
are probably ok in most cases. You will probably need to increase them
if you have an especially slow computer, in which case the timers to
increase are actually on the <bf/other/ computer.  A program called
<em/plipconfig/ exists that allows you to change these timer settings
without recompiling your kernel. It is supplied with many Linux
distributions.

<p>To configure a <em/plip/ interface, you will need to invoke the
following commands (or <bf/add/ them to your initialization scripts):

	<tscreen><verb>
	root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
	root# /sbin/route add remoteplip plip1
	</verb></tscreen>

<p>Here, the port being used is the one at I/O address 0x378;
<em/localplip/ amd <em/remoteplip/ are the names or IP addresses used
over the PLIP cable. I personally keep them in my <tt>/etc/hosts</tt>
database:

	<tscreen><verb>
	# plip entries
	192.168.3.1   localplip
	192.168.3.2   remoteplip
	</verb></tscreen>

<p>The <em/pointopoint/ parameter has the same meaning as for SLIP,
in that it specifies the address of the machine at the other end of the
link.
<p>
In almost all respects you can treat a <em/plip/ interface as though it
were a <em/SLIP/ interface, except that neither <em/dip/ nor
<em/slattach/ need be, nor can be, used.
<p>
Further information on PLIP may be obtained from the
``PLIP mini-HOWTO''.
<!-- FIXME: where did this go? And the Modules-HOWTO? -->

<!--======================================================================-->
<sect1><heading>PLIP for Linux-2.2

<p>During development of the 2.1 kernel versions, support for the
parallel port was changed to a better setup.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	General setup  --->
	    [*] Parallel port support
	Network device support  --->
	    <*> PLIP (parallel port) support
	</verb></tscreen>                            

<p>The new code for PLIP behaves like the old one (use the same <em/ifconfig/
and <em/route/ commands as in the previous section, but initialization
of the device is different due to the advanced parallel port support.

<p>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 <tt>/proc/parport</tt>. For example,
if you have only one parallel port, you'll only have a directory
called <tt>/proc/parport/0</tt>.

<p>If your kernel didn't detect the IRQ number used by your port,
``<tt>insmod plip</tt>'' will fail; in this case just write the right
number to <tt>/proc/parport/0/irq</tt> and reinvoke <em/insmod/.

<p>Complete information about parallel port management is available in
the file <tt>Documentation/parport.txt</tt>, part of your kernel sources.

<!--======================================================================-->
<sect1><heading>PPP
<p>
PPP devices names are `<tt/ppp0/', `<tt/ppp1/, etc. Devices are numbered
sequentially with the first device configured receiving `<tt/0/'.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    <*> PPP (point-to-point) support
	</verb></tscreen>

<p>
PPP configuration is covered in detail in the
<htmlurl url="PPP-HOWTO.html" name="PPP-HOWTO">.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Maintaining a permanent connection to the net with <em/pppd/.
<p>
If you are fortunate enough to have a semi permanent connection to the net and
would like to have your machine automatically redial your PPP connection if it
is lost then here is a simple trick to do so.
<p>
Configure PPP such that it can be started by the <tt/root/ user by issuing the
command:
<tscreen><verb>
# pppd
</verb></tscreen>
<bf/Be sure/ that you have the `<tt/-detach/' option configured in your
<tt>/etc/ppp/options</tt> file. Then, insert the following line into your
<tt>/etc/inittab</tt> file, down with the <em/getty/ definitions:
<tscreen><verb>
pd:23:respawn:/usr/sbin/pppd
</verb></tscreen>
This will cause the <em/init/ program to spawn and monitor the <em/pppd/
program and automatically restart it if it dies.

<!--======================================================================-->
<sect1><heading>SLIP client
<p>
SLIP devices are named `<tt/sl0/', `<tt/sl1/' etc. with the first device
configured being assigned `<tt/0/' and the rest incrementing sequentially
as they are configured.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    [*] Network device support
	    <*> SLIP (serial line) support
	    [ ]  CSLIP compressed headers
	    [ ]  Keepalive and linefill
	    [ ]  Six bit SLIP encapsulation
	</verb></tscreen>

<p>
SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a serial
line, be that a phone line with a dialup modem, or a leased line of some sort.
Of course to use SLIP you need access to a <em>SLIP-server</em> in your
area. Many universities and businesses provide SLIP access all over the
world.
<p>
Slip uses the serial ports on your machine to carry IP datagrams. To do this
it must take control of the serial device. Slip device names are named
<em>sl0</em>, <em>sl1</em> etc. How do these correspond to your serial
devices ? The networking code uses what is called an <em>ioctl</em> (i/o
control) call to change the serial devices into SLIP devices. There are
two programs supplied that can do this, they are called <em>dip</em> and
<em>slattach</em>

<!-- -------------------------------------------------------------------- -->
<sect2><heading>dip
<p>
<em>dip</em> (Dialup IP) is a smart program that is able to 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 for them such as your IP address and
perform the <em>ioctl</em> necessary to switch your serial port into
SLIP mode. <em>dip</em> has a powerful scripting ability and it is this
that you can exploit to automate your logon procedure.
<p>
You can find it at:
<htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz" name="metalab.unc.edu">.
<p>
To install it, try the following:

	<tscreen><verb>
	user% tar xvzf dip337o-uri.tgz
	user% cd dip-3.3.7o
	user% vi Makefile
	root# make install
	</verb></tscreen>

<p>The <tt>Makefile</tt> assumes the existence of a group called <em>uucp</em>,
but you might like to change this to either <em>dip</em> or <em>SLIP</em>
depending on your configuration.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>slattach

<p>
<em>slattach</em> as contrasted with <em>dip</em> is a very simple program,
that is very easy to use, but does not have the sophistication of <em>dip</em>.
It does not have the scripting ability, all it does is configure your
serial device as a SLIP device. It assumes you have all the information you
need and the serial line is established before you invoke it. <em>slattach</em>
is ideal to use where you have a permanent connection to your server, such as
a physical cable, or a leased line.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>When do I use which ?

<p>
You would use <em>dip</em> when your link to the machine that is your SLIP
server is a dialup modem, or some other temporary link. You would use
<em>slattach</em> when you have a leased line, perhaps a cable, between your
machine and the server and there is no special action needed to get the link
working. See section `Permanent Slip connection' for more information.

<p>Configuring SLIP is much like configuring an Ethernet interface
(read section `Configuring an ethernet device' above). However there
are a few key differences.

<p>First of all, SLIP links are unlike ethernet networks in that there
is only ever two hosts on the network, one at each end of the
link. Unlike an ethernet that is available for use as soon are you are
cabled, with SLIP, depending on the type of link you have, you may
have to initialize your network connection in some special way.

<p>If you are using <em>dip</em> then this would not normally be done
at boot time, but at some time later, when you were ready to use the
link.  It is possible to automate this procedure. If you are using
<em>slattach</em> then you will probably want to add a section to your
<em>rc.inet1</em> file.  This will be described soon.

<p>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 when dialing
in. <em>dip</em> can handle logging you in automatically.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Static SLIP server with a dialup line and DIP.

<p>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
<tt>/etc/hosts</tt>. You should also configure some other files such as:
<tt>rc.inet2</tt>, <tt>host.conf</tt>, <tt>resolv.conf</tt>,
<tt>/etc/HOSTNAME</tt> and <tt>rc.local</tt>. Remember that when configuring
<tt>rc.inet1</tt>, you don't need to add any special commands for your SLIP
connection since it is <em>dip</em> that does all of the hard work for you in
configuring your interface. You will need to give <em>dip</em> the appropriate
information and it will configure the interface for you after commanding the
modem to establish the call and logging you into your SLIP server.

<p>If this is how your SLIP server works then you can move to section
`Using Dip' to learn how to configure <em>dip</em> appropriately.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Dynamic SLIP server with a dialup line and DIP.

<p>A <em>dynamic</em> 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 each time, and that 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, it finds
the first unused address, guides the caller through the login process
and then prints a welcome message that contains the IP address it has
allocated and will proceed to use that IP address for the duration of
that call.

<p>Configuring for this type of server is similar to configuring for a
static server, except that you must add a step where you obtain the IP
address that the server has allocated for you and configure your SLIP
device with that.

<p>Again, <em>dip</em> does the hard work and new versions are smart
enough to not only log you in, but to also be able to automatically
read the IP address printed in the welcome message and store it so
that you can have it configure your SLIP device with it.

<p>If this is how your SLIP server works then you can move to section
`Using Dip' to learn how to configure <em>dip</em> appropriately.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Using DIP.

<p>As explained earlier, <em>dip</em> is a powerful program that can simplify
and automate the process of dialing into the SLIP server, logging you in,
starting the connection and configuring your SLIP devices with the
appropriate <em>ifconfig</em> and <em>route</em> commands.

<p>Essentially to use <em>dip</em> you'll write a `dip script', which
is basically a list of commands that <em>dip</em> understands that
tell <em>dip</em> how to perform each of the actions you want it to
perform. See <tt>sample.dip</tt> that comes supplied with <em>dip</em>
to get an idea of how it works. <em>dip</em> is quite a powerful
program, with many options.  Instead of going into all of them here
you should look at the <em>man</em> page, README and sample files that
will have come with your version of <em>dip</em>.

<p>You may notice that the <tt>sample.dip</tt> script assumes that
you're using a static SLIP server, so you know what your IP address is
beforehand. For dynamic SLIP servers, the newer versions of
<em>dip</em> 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
<tt>sample.dip</tt> that came supplied with <em>dip337j-uri.tgz</em>
and is probably a good starting point for you.  You might like to save
it as <tt>/etc/dipscript</tt> and edit it to suit your configuration:

<tscreen><verb>
#
# 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, <waltje@uWalt.NL.Mugnet.ORG>
#

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 ---> $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
</verb></tscreen>

<p>The above example assumes you are calling a <em>dynamic</em> SLIP server, if
you are calling a <em>static</em> SLIP server, then the <tt>sample.dip</tt>
file that comes with <em>dip337j-uri.tgz</em> should work for you.
<p>
When <em>dip</em> is given the <em>get &dollar;local</em> 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 <em>dynamic</em> SLIP servers, so that the
process of reading the IP address granted by the server could be automated.
<p>
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, then remove the <em>default</em> command from the script.
After this script has finished running, if you do an <em>ifconfig</em> command,
you will see that you have a device <em>sl0</em>. This is your SLIP device.
Should you need to, you can modify its configuration manually, after the
<em>dip</em> command has finished, using the <em>ifconfig</em> and
<em>route</em> commands.

Please note that <em>dip</em> allows you to select a number of different
protocols to use with the <tt>mode</tt> command, the most common example is
<em>cSLIP</em> for SLIP with compression. Please note that both ends of the
link must agree, so you should ensure that whatever you select agrees with
what your server is set to.

The above example is fairly robust and should cope with most errors. Please
refer to the <em>dip</em> man page for more information. Naturally you could,
for example, code the script to do such things as redial the server if it
doesn't get a connection within a prescribed period of time, or even try
a series of servers if you have access to more than one.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Permanent SLIP connection using a leased line and slattach.
<p>
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 another, then you don't need to go to all the trouble of using
<em>dip</em> to set up your serial link. <em>slattach</em> is a very simple
to use utility that will allow you just enough functionality to configure your
connection.

Since your connection will be a permanent one, you will want to add some
commands to your <tt>rc.inet1</tt> file. In essence all you need to do for
a permanent connection is ensure that you configure the serial device to
the correct speed and switch the serial device into SLIP mode. <em>slattach</em>
allows you to do this with one command. <bf>Add</bf> the following to your
<tt>rc.inet1</tt> file:

	<tscreen><verb>
	#
	# Attach a leased line static SLIP connection
	#
	#  configure /dev/cua0 for 19.2kbps and cslip
	/sbin/slattach -p cslip -s 19200 /dev/cua0 &
	/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
	#
	# End static SLIP.
	</verb></tscreen>

Where:
	<descrip>
	<p><tag>IPA.IPA.IPA.IPA</tag>represents your IP address.
	<p><tag>IPR.IPR.IPR.IPR</tag>represents the IP address of the remote end.
	</descrip>

<p><em>slattach</em> allocates the first unallocated SLIP device to the serial
device specified. <em>slattach</em> starts with <em>sl0</em>. Therefore
the first <em>slattach</em> command attaches SLIP device <em>sl0</em> to
the serial device specified and <em>sl1</em> the next time, etc.

<p><em>slattach</em> allows you to configure a number of different
protocols with the <tt>-p</tt> argument. In your case you will use
either <em>SLIP</em> or <em>cSLIP</em> depending on whether you want
to use compression or not.  Note: both ends must agree on whether you
want compression or not.

<!--======================================================================-->
<sect1><heading>SLIP server.
<p>
If you have a machine that is perhaps network connected, that you'd like
other people be able to dial into and provide 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 currently 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, <em>sliplogin</em>, as it seems the easiest to
configure and understand, but I will present a summary of each, so you can
make your own decision.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Slip Server using <em/sliplogin/.
<p>
<em/sliplogin/ is a program that you can use in place of the normal login
shell for SLIP users that converts the terminal line into a SLIP line. It
allows you to configure your Linux machine as either a <em/static address
server/, users get the same address everytime they call in, or a
<em/dynamic address server/, where users get an address allocated for
them which will not necessarily be the same as the last time they called.
<p>
The caller will login as per the standard login process, entering their username
and password, but instead of being presented with a shell after their login,
<em/sliplogin/ is executed which searches its configuration file
(<tt>/etc/slip.hosts</tt>) for an entry with a login name that matches that of
the caller. If it locates one, it configures the line as an 8bit clean line,
and uses an <em/ioctl/ call to convert the line discipline to SLIP. When
this process is complete, the last stage of configuration takes place, where
<em/sliplogin/ invokes a shell script which configures the SLIP interface
with the relevant ip address, netmask and sets appropriate routing in place.
This script is usually called <tt>/etc/slip.login</tt>, but in a similar manner
to <em/getty/, if you have certain callers that require special
initialization, then you can create configuration scripts called
<tt>/etc/slip.login.loginname</tt> that will be run instead of the default
specifically for them.
<p>
There are either three or four files that you need to configure to get
<em/sliplogin/ working for you. I will detail how and where to
get the software and how each is configured in detail. The files are:

<itemize>
<item><tt>/etc/passwd</tt>, for the dialin user accounts.
<item><tt>/etc/slip.hosts</tt>, to contain the information unique to each
dial-in user.
<item><tt>/etc/slip.login</tt>, which manages the configuration of the routing
that needs to be performed for the user.
<item><tt>/etc/slip.tty</tt>, which is required only if you are configuring
your server for <em/dynamic address allocation/ and contains a table
of addresses to allocate
<item><tt>/etc/slip.logout</tt>, which contains commands to clean up after the
user has hung up or logged out.
</itemize>

<!-- .................................................................... -->
<sect3><heading>Where to get <em>sliplogin</em>
<p>
You may already have the <em/sliplogin/ package installed as part of your
distribution, if not then <em/sliplogin/ can be obtained from:
<htmlurl url="ftp://metalab.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz" name="metalab.unc.edu">.
The tar file contains both source, precompiled binaries and a <em/man/ page.
<p>
To ensure that only authorized users will be able to run <em/sliplogin/
program, you should add an entry to your <tt>/etc/group</tt> file similar to
the following:

<tscreen><verb>
 ..
slip::13:radio,fred
 ..
</verb></tscreen>

<p>When you install the <em/sliplogin/ package, the <tt/Makefile/ will
change the group ownership of the <em/sliplogin/ program to <tt/slip/,
and this will mean that only users who belong to that group will be able
to execute it. The example above will allow only users <tt/radio/ and <tt/fred/
to execute <em/sliplogin/.
<p>
To install the binaries into your <tt>/sbin</tt> directory and the <em/man/
page into section 8, do the following:

<tscreen><verb>
# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# <..edit the Makefile if you don't use shadow passwords..>
# make install
</verb></tscreen>

<p>If you want to recompile the binaries before installation, add a
<tt/make clean/ before the <tt/make install/. If you want to install
the binaries somewhere else, you will need to edit the <tt/Makefile/
<em/install/ rule.
<p>
Please read the <tt/README/ files that come with the package for more
information.

<!-- .................................................................... -->
<sect3><heading>Configuring <tt>/etc/passwd</tt> for Slip hosts.
<p>
Normally you would create some special logins for Slip callers in your
<tt>/etc/passwd</tt> file. A convention commonly followed is to use the
<em/hostname/ of the calling host with a capital `S' prefixing it. So,
for example, if the calling host is called <tt/radio/ then you could
create a <tt>/etc/passwd</tt> entry that looked like:

<tscreen><verb>
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
</verb></tscreen>

It doesn't really matter what the account is called, so long as it is
meaningful to you.
<p>
Note: the caller doesn't need any special home directory, as they will not
be presented with a shell from this machine, so <tt>/tmp</tt> is a good choice.
Also note that <em>sliplogin</em> is used in place of the normal login shell.

<!-- .................................................................... -->
<sect3><heading>Configuring <tt>/etc/slip.hosts</tt>
<p>
The <tt>/etc/slip.hosts</tt> file is the file that <em/sliplogin/
searches for entries matching the login name to obtain configuration details
for this caller. It is this file where you specify the ip address and netmask
that will be assigned to the caller and configured for their use. Sample
entries for two hosts, one a static configuration for host <tt/radio/ and
another, a dynamic configuration for user host <tt/albert/ might look like:

<tscreen><verb>
#
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
#
</verb></tscreen>

The <tt>/etc/slip.hosts</tt> file entries are:

<enum>
<item>the login name of the caller.
<item>ip address of the server machine, ie this machine.
<item>ip address that the caller will be assigned. If this field is coded
<tt/DYNAMIC/ then an ip address will be allocated based on the information
contained in your <tt>/etc/slip.tty</tt> file discussed later. <bf/Note:/
you must be using at least version 1.3 of sliplogin for this to work.
<item>the netmask assigned to the calling machine in dotted decimal notation
eg 255.255.255.0 for a Class C network mask.
<item>the slip mode setting which allows you to enable/disable compression and
slip other features. Allowable values here are "<tt/normal/" or
"<tt/compressed/".
<item>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.
<item>optional arguments.
</enum>

<p>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,
that is, your machine must be able to locate an ip address for those hostnames,
otherwise the script will fail when it is called. You can test this by
trying to telnet to the hostname, if you get the
`<em/Trying nnn.nnn.nnn.../' message then your machine has been able to find
an ip address for that name. If you get the message `<em/Unknown host/', then
it has not. If not, either use ip addresses in dotted decimal notation, or fix
up your name resolver configuration (See section <tt/Name Resolution/).
<p>
The most common slip modes are:
<descrip>
<p><tag>normal</tag>to enable normal uncompressed SLIP.
<p><tag>compressed</tag>to enable van Jacobsen header compression (cSLIP)
</descrip>

Naturally these are mutually exclusive, you can use one or the other. For more
information on the other options available, refer to the <em>man</em> pages.

<!-- .................................................................... -->
<sect3><heading>Configuring the <tt>/etc/slip.login</tt> file.
<p>
After <em>sliplogin</em> has searched the <tt>/etc/slip.hosts</tt> and found
a matching entry, it will attempt to execute the <tt>/etc/slip.login</tt> file
to actually configure the SLIP interface with its ip address and netmask.

The sample <tt>/etc/slip.login</tt> file supplied with the <em>sliplogin</em>
package looks like this:

<tscreen><verb>
#!/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 <hw_addr> pub
exit 0
#
</verb></tscreen>

You will note that this script simply uses the <em>ifconfig</em> and
<em>route</em> commands to configure the SLIP device with its ipaddress,
remote ip address and netmask and creates a route for the remote address via
the SLIP device. Just the same as you would if you were using the
<em>slattach</em> command.
<p>
Note also the use of <em>Proxy ARP</em> to ensure that other hosts on the same
ethernet as the server machine will know how to reach the dial-in host.
The <tt>&lt;hw_addr></tt> 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 leave this line out completely.

<!-- .................................................................... -->
<sect3><heading>Configuring the <tt>/etc/slip.logout</tt> file.
<p>
When the call drops out, you want to ensure that the serial device is restored
to its normal state so that future callers will be able to login correctly.
This is achieved with the use of the <tt>/etc/slip.logout</tt> file. It is
quite simple in format and is called with the same argument as the
<tt>/etc/slip.login</tt> file.

	<tscreen><verb>
	#!/bin/sh -
	#
	#               slip.logout
	#
	/sbin/ifconfig $1 down
	arp -d $6
	exit 0
	#
	</verb></tscreen>

All it does is `down' the interface which will delete the manual route
previously created. It also uses the <em>arp</em> command to delete any proxy
arp put in place, again, you don't need the <em>arp</em> command in the script
if your server machine does not have an ethernet port.

<!-- .................................................................... -->
<sect3><heading>Configuring the <tt>/etc/slip.tty</tt> file.
<p>
If you are using dynamic ip address allocation (have any hosts configured
with the <tt>DYNAMIC</tt> keyword in the <tt>/etc/slip.hosts</tt> file, then
you must configure the <tt>/etc/slip.tty</tt> 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.
<p>
The file is a table that lists the <em>tty</em> devices that will support
dial-in SLIP connections and the ip address that should be assigned to users
who call in on that port.

Its format is as follows:
<tscreen><verb>
# slip.tty    tty -> 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
#
</verb></tscreen>

<p>
What this table says is that callers that dial in on port <tt>/dev/ttyS0</tt>
who have their remote address field in the <tt>/etc/slip.hosts</tt> file
set to <tt>DYNAMIC</tt> will be assigned an address of <tt>192.168.0.100</tt>.
<p>
In this way you need only allocate one address per port for all users who do
not require an dedicated address for themselves. This helps you keep the number
of addresses you need down to a minimum to avoid wastage.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Slip Server using <em>dip</em>.
<p>
Let me start by saying that some of the information below came from the
<em>dip</em> 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 <em>dip337o-uri.tgz</em> package and probably will not apply to other
versions of <em>dip</em>.

<em>dip</em> has an input mode of operation, where it automatically locates
an entry for the user who invoked it and configures the serial line as
a SLIP link according to information it finds in the <tt>/etc/diphosts</tt>
file. This input mode of operation is activated by invoking <em>dip</em>
as <em>diplogin</em>. This therefore is how you use <em>dip</em> as a SLIP
server, by creating special accounts where <em>diplogin</em> is used as the
login shell.

The first thing you will need to do is to make a symbolic link as follows:

<tscreen><verb>
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
</verb></tscreen>

You then need to add entries to both your <tt>/etc/passwd</tt> and your
<tt>/etc/diphosts</tt> files. The entries you need to make are formatted
as follows:

To configure Linux as a SLIP server with <em>dip</em>, you need to create some
special SLIP accounts for users, where <em>dip</em> (in input mode) is used as
the login shell. A suggested convention is that of having all SLIP accounts
begin with a capital `S', eg `Sfredm'.

A sample <tt>/etc/passwd</tt> entry for a SLIP user looks like:

<tscreen><verb>
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
</verb></tscreen>

<p>After the user logs in, the <em>login</em> program, if it finds and
verifies the user ok, will execute the <em>diplogin</em>
command. <em>dip</em>, when invoked as <em>diplogin</em> knows that it
should automatically assume that it is being used a login shell. When
it is started as <em>diplogin</em> the first thing it does is use the
<em>getuid()</em> function call to get the userid of whoever has
invoked it. It then searches the <tt>/etc/diphosts</tt> file for the
first entry that matches either the userid or the name of the
<em>tty</em> device that the call has come in on and configures itself
appropriately.  By judicious decision as to whether to give a user an
entry in the <tt>diphosts</tt> file, or whether to let the user be
given the default configuration you can build your server in such a
way that you can have a mix of static and dynamically assigned address
users.

<em>dip</em> will automatically add a `Proxy-ARP' entry if invoked in input
mode, so you do not need to worry about manually adding such entries.

<!-- .................................................................... -->
<sect3><heading>Configuring <tt>/etc/diphosts</tt>

<p>
<tt>/etc/diphosts</tt> is used by <em>dip</em> 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.

The general format for <tt>/etc/diphosts</tt> is as follows:

<tscreen><verb>
 ..
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
 ..
</verb></tscreen>

The fields are:
<enum>
<item><tt>login name</tt>: as returned by getpwuid(getuid()) or tty name.
<item><tt>unused</tt>: compat. with passwd
<item><tt>Remote Address</tt>: IP address of the calling host, either numeric or by name
<item><tt>Local Address</tt>: IP address of this machine, again numeric or by name
<item><tt>Netmask</tt>: in dotted decimal notation
<item><tt>Comment field</tt>: put whatever you want here.
<item><tt>protocol</tt>: Slip, CSlip etc.
<item><tt>MTU</tt>: decimal number
</enum>

An example <tt>/etc/net/diphosts</tt> entry for a remote SLIP user might be:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
</verb></tscreen>

which specifies a SLIP link with remote address of 145.71.34.1 and MTU of 296,
or:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
</verb></tscreen>

which specifies a cSLIP-capable link with remote address 145.71.34.1 and MTU
of 1006.
<p>
Therefore, all users who you wish to be allowed a statically allocated dial-up
IP access should have an entry in the <tt>/etc/diphosts</tt>. If you want
users who call a particular port to have their details dynamically allocated
then you must have an entry for the <tt>tty</tt> device and do not configure a
user based entry. You should remember to configure at least one entry for
each <tt>tty</tt> device that your dialup users use to ensure that a suitable
configuration is available for them regardless of which modem they call in on.
<p>
When a user logs in they will receive a normal login and password prompt at
which they should enter their SLIP-login userid and password. If these verify
ok then the user will see no special messages and they should just change into
SLIP mode at their end. The user should then be able to connect ok and be
configured with the relevant parameters from the <tt>diphosts</tt> file.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>SLIP server using the <em>dSLIP</em> package.

<p>
Matt Dillon <tt>&lt;dillon@apollo.west.oic.com></tt> 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 <em>tcsh</em> installed as at least one
of the scripts requires it. Matt supplies a binary copy of the <em>expect</em>
utility as it too is needed by one of the scripts. You will most likely need
some experience with <em>expect</em> to get this package working to your
liking, but don't let that put you off.
<p>
Matt has written a good set of installation instructions in the
README file, so I won't bother repeating them.
<p>
You can get the <em>dSLIP</em> package from its home site at:

<bf>apollo.west.oic.com</bf>
<tscreen><verb>
/pub/linux/dillon_src/dSLIP203.tgz
</verb></tscreen>

or from:

<bf>metalab.unc.edu</bf>
<tscreen><verb>
/pub/Linux/system/Network/serial/dSLIP203.tgz
</verb></tscreen>

Read the <tt>README</tt> file and create the <tt>/etc/passwd</tt> and
<tt>/etc/group</tt> entries <bf>before</bf> doing a <tt>make install</tt>.


<!--######################################################################-->
<sect><heading>Other Network Technologies

<p>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.

<!--======================================================================-->
<sect1><heading>ARCNet
<p>
ARCNet device names are `<tt/arc0e/', `<tt/arc1e/', `<tt/arc2e/' etc. or
`<tt/arc0s/', `<tt/arc1s/', `<tt/arc2s/' etc. The first card detected by the
kernel is assigned `<tt/arc0e/' or `<tt/arc0s/' and the rest are assigned
sequentially in the order they are detected. The letter at the end signifies
whether you've selected ethernet encapsulation packet format or RFC1051 packet
format.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    [*] Network device support
	    <*> ARCnet support
	    [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
	    [ ]   Enable arc0s (ARCnet RFC1051 packet format)
	</verb></tscreen>

<p>
Once you have your kernel properly built to support your ethernet card then
configuration of the card is easy.
<p>
Typically you would use something like:

	<tscreen><verb>
	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
	</verb></tscreen>

Please refer to the
<tt>/usr/src/linux/Documentation/networking/arcnet.txt</tt> and
<tt>/usr/src/linux/Documentation/networking/arcnet-hardware.txt</tt> files
for further information.
<p>
ARCNet support was developed by Avery Pennarun, <tt/apenwarr@foxnet.net/.

<!--======================================================================-->
<sect1><heading>Appletalk (<tt/AF_APPLETALK/)
<p>
The Appletalk support has no special device names as it uses existing network
devices.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    <*> Appletalk DDP
	</verb></tscreen>

<p>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 both your Linux and Apple computers. Additional software is required,
this is called <em/netatalk/. Wesley Craig <tt/netatalk@umich.edu/ represents
a team called the `Research Systems Unix Group' at the University of Michigan
and they have produced the <em/netatalk/ package which provides software that
implements the Appletalk protocol stack and some useful utilities.
The <em/netatalk/ package will either have been supplied with your Linux
distribution, or you will have to ftp it from its home site at the
<htmlurl url="ftp://terminator.rs.itd.umich.edu/unix/netatalk/"
	name="University of Michigan">
<p>
To build and install the package do something like:

	<tscreen><verb>
	user% tar xvfz .../netatalk-1.4b2.tar.Z
	user% make
	root# make install
	</verb></tscreen>

<p>You may want to edit the `Makefile' before calling <em/make/ to
actually compile the software. Specifically, you might want to change
the DESTDIR variable which defines where the files will be installed
later.  The default of /usr/local/atalk is fairly safe.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Configuring the Appletalk software.
<p>
The first thing you need to do to make it all work is to ensure that the
appropriate entries in the <tt>/etc/services</tt> file are present. The
entries you need are:

  <tscreen><verb>
  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
  </verb></tscreen>

<p>The next step is to create the Appletalk configuration files in the
<tt>/usr/local/atalk/etc</tt> directory (or wherever you installed the
package).
<p>
The first file to create is the <tt>/usr/local/atalk/etc/atalkd.conf</tt> file.
Initially this file needs only one line that gives the name of the network
device that supports the network that your Apple machines are on:

  <tscreen><verb>
  eth0
  </verb></tscreen>

<p>The Appletalk daemon program will add extra details after it is run.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Exporting a Linux filesystems via Appletalk.
<p>
You can export filesystems from your linux machine to the network so that
Apple machine on the network can share them.
<p>
To do this you must configure the
<tt>/usr/local/atalk/etc/AppleVolumes.system</tt> file. There is another
configuration file called <tt>/usr/local/atalk/etc/AppleVolumes.default</tt>
which has exactly the same format and describes which filesystems users
connecting with guest privileges will receive.
<p>
Full details on how to configure these files and what the various options are
can be found in the <em>afpd</em> man page.
<p>
A simple example might look like:

  <tscreen><verb>
  /tmp Scratch
  /home/ftp/pub "Public Area"
  </verb></tscreen>

<p>Which would export your <tt>/tmp</tt> filesystem as AppleShare Volume
`Scratch' and 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.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Sharing your Linux printer across Appletalk.
<p>
You can share your linux printer with your Apple machines quite simply.
You need to run the <em>papd</em> program which is 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 for printing.
<p>
You need to edit the <tt>/usr/local/atalk/etc/papd.conf</tt> file to configure
the daemon. The syntax of this file is the same as that of your usual
<tt>/etc/printcap</tt> file. The name you give to the definition is
registered with the Appletalk naming protocol, NBP.
<p>
A sample configuration might look like:

  <tscreen><verb>
  TricWriter:\
     :pr=lp:op=cg:
  </verb></tscreen>

Which would make a printer named `TricWriter' available to your Appletalk
network and all accepted jobs would be printed to the linux printer `<tt/lp/'
(as defined in the <tt>/etc/printcap</tt> file) using <em>lpd</em>. The entry
`<tt/op=cg/' says that the linux user `<tt/cg/' is the operator of the printer.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Starting the appletalk software.
<p>
Ok, you should now be ready to test this basic configuration. There is an
<em>rc.atalk</em> file supplied with the <em>netatalk</em> package that should
work ok for you, so all you should have to do is:

	<tscreen><verb>
	root# /usr/local/atalk/etc/rc.atalk
	</verb></tscreen>

<p>and all should startup and run ok. You should see no error messages and
the software will send messages to the console indicating each stage as it
starts.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Testing the appletalk software.
<p>
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.

<!-- -------------------------------------------------------------------- -->
<sect2><heading>Caveats of the appletalk software.
<p>

	<itemize>

	<item>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
		<tt>/etc/rc.d/rc.inet1</tt> file.

	<item>The <em>afpd</em> (Apple Filing Protocol Daemon)
		severely messes up your hard disk. Below the mount
		points it creates a couple of directories called
		``<tt>.AppleDesktop</tt>'' and <tt>Network Trash
		Folder</tt>. Then, for each directory you access it
		will create a <tt>.AppleDouble</tt> below it so it can
		store resource forks, etc. So think twice before
		exporting <tt>/</tt>, you will have a great time
		cleaning up afterwards.

	<item>The <em>afpd</em> 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 have yourself to blame
		if somebody nasty does something bad.

	<item>The existing diagnostic tools such as <em>netstat</em>
		and <em>ifconfig</em> don't support Appletalk. The raw
		information is available in the <tt>/proc/net/</tt>
		directory if you need it.

	</itemize>

<!-- -------------------------------------------------------------------- -->
<sect2>More information
<p>
For a much more detailed description of how to configure Appletalk for Linux
refer to Anders Brownworth <em/Linux Netatalk-HOWTO/ page at
<htmlurl url="http://thehamptons.com/anders/netatalk/"
	name="thehamptons.com">.
<!-- FIXME: Why the Netatalk howto is not in LDP? -->

<!--======================================================================-->
<sect1><heading>ATM
<p>
Werner Almesberger <tt>&lt;werner.almesberger@lrc.di.epfl.ch&gt;</tt> is
managing a project to provide Asynchronous Transfer Mode support for Linux.
Current information on the status of the project may be obtained from:
<htmlurl url="http://lrcwww.epfl.ch/linux-atm/"
	name="lrcwww.epfl.ch">.

<!--======================================================================-->
<sect1><heading>AX25 (<tt/AF_AX25/)
<p>
AX.25 device names are `<tt/sl0/', `<tt/sl1/', etc. in <tt/2.0.*/ kernels or
`<tt/ax0/', `<tt/ax1/', etc. in <tt/2.1.*/ kernels.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] Amateur Radio AX.25 Level 2
	</verb></tscreen>

<p>The AX25, Netrom and Rose protocols are covered by the
 <htmlurl url="AX25-HOWTO.html" name="AX25-HOWTO">.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
<p>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<!--======================================================================-->
<sect1><heading>DECNet
<p>
Support for DECNet is currently being worked on. You should expect it to
appear in a late <tt/2.1.*/ kernel.

<!--======================================================================-->
<sect1><heading>FDDI
<p>
FDDI device names are `<tt/fddi0/', `<tt/fddi1/', `<tt/fddi2/' etc. The first
card detected by the kernel is assigned `<tt/fddi0/' and the rest are assigned
sequentially in the order they are detected.
<p>
Larry Stefani, <tt/lstefani@ultranet.com/, has developed a
driver for the Digital Equipment Corporation FDDI EISA and PCI cards.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    [*] FDDI driver support
	    [*] Digital DEFEA and DEFPA adapter support
	</verb></tscreen>

<p>When you have your kernel built to support the FDDI driver and installed,
configuration of the FDDI interface is almost identical to that of an ethernet
interface. You just specify the appropriate FDDI interface name in the
<em/ifconfig/ and <em/route/ commands.

<!--======================================================================-->
<sect1><heading>Frame Relay
<p>
The Frame Relay device names are `<tt/dlci00/', `<tt/dlci01/' etc for the
DLCI encapsulation devices and `<tt/sdla0/', `<tt/sdla1/' etc for the FRAD(s).
<p>
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.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
	    <*> Frame relay DLCI support (EXPERIMENTAL)
	    (24)   Max open DLCI
	    (8)   Max DLCI per device
	    <*>   SDLA (Sangoma S502/S508) support
	</verb></tscreen>
<p>
Mike McLagan, <tt/mike.mclagan@linux.org/, developed the Frame Relay support
and configuration tools.
<p>
Currently the only FRAD supported are the
<htmlurl url="http://www.sangoma.com/"
	name="Sangoma Technologies">
<tt/S502A/, <tt/S502E/ and <tt/S508/.
<p>
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
<htmlurl url="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz"
	name="ftp.invlogic.com">.
Compiling and installing the tools is straightforward, but the lack of a
top level Makefile makes it a fairly manual process:

	<tscreen><verb>
	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
	</verb></tscreen>

<p>Note that the previous commands use <em/sh/ syntax, if you use a
<em/csh/ flavour instead (like <em/tcsh/), the <em/for/ loop will look
different.

<p>After installing the tools you need to create an
<tt>/etc/frad/router.conf</tt> file. You can use this template, which
is a modified version of one of the example files:

<tscreen><verb>
# /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<devicenum>_<DLCI_Num>]
#

[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
</verb></tscreen>

<p>When you've built your <tt>/etc/frad/router.conf</tt> file the only
step remaining is to configure the actual devices themselves. This is
only a little trickier than a normal network device configuration, you
need to remember to bring up the FRAD device before the DLCI
encapsulation devices. These commands are best hosted in a shell
script, due to their number:

	<tscreen><verb>
	#!/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
	#
	</verb></tscreen>

<!--======================================================================-->
<sect1><heading>IPX (<tt/AF_IPX/)
<p>
The IPX protocol is most commonly utilized in Novell NetWare(tm) local area
network environments. Linux includes support for this protocol and may be
configured to act as a network endpoint, or as a router for IPX.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] The IPX protocol
	    [ ] Full internal IPX network
	</verb></tscreen>

<p>The IPX protocol and the NCPFS are covered in greater depth in the
<htmlurl url="IPX-HOWTO.html" name="IPX-HOWTO">.


<!--======================================================================-->
<sect1><heading>NetRom (<tt/AF_NETROM/)
<p>
NetRom device names are `<tt/nr0/', `<tt/nr1/', etc.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] Amateur Radio AX.25 Level 2
	    [*] Amateur Radio NET/ROM
	</verb></tscreen>

<p>The AX25, Netrom and Rose protocols are covered by the
 <htmlurl url="AX25-HOWTO.html" name="AX25-HOWTO">.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
<p>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<!--======================================================================-->
<sect1><heading>Rose protocol (<tt/AF_ROSE/)
<p>
Rose device names are `<tt/rs0/', `<tt/rs1/', etc. in <tt/2.1.*/ kernels.
Rose is available in the <tt/2.1.*/ kernels.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Networking options  --->
	    [*] Amateur Radio AX.25 Level 2
	    <*> Amateur Radio X.25 PLP (Rose)
	</verb></tscreen>

<p>The AX25, Netrom and Rose protocols are covered by the
 <htmlurl url="AX25-HOWTO.html" name="AX25-HOWTO">.
These protocols are used by Amateur Radio Operators world wide in packet
radio experimentation.
<p>
Most of the work for implementation of these protocols has been done by
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<!--======================================================================-->
<sect1><heading>SAMBA - `NetBEUI', `NetBios', `CIFS' support.
<p>
SAMBA is an implementation of the Session Management Block protocol. Samba
allows Microsoft and other systems to mount and use your disks and printers.
<p>
SAMBA and its configuration are covered in detail in the
<htmlurl url="SMB-HOWTO.html" name="SMB-HOWTO">.

<!--======================================================================-->
<sect1><heading>STRIP support (Starmode Radio IP)
<p>
STRIP device names are `<tt/st0/', `<tt/st1/', etc.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
		[*] Network device support
		....
		[*] Radio network interfaces
		< > STRIP (Metricom starmode radio IP)
	</verb></tscreen>

<p>STRIP is a protocol designed specifically for a range of Metricom
radio modems for a research project being conducted by Stanford
University called the <htmlurl
url="http://mosquitonet.Stanford.EDU/mosquitonet.html"
name="MosquitoNet Project">.  There is a lot of interesting reading
here, even if you aren't directly interested in the project.

<p>
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 the:
<htmlurl url="http://www.metricom.com/"
	name="Metricom Web Server">.
<p>
At present the standard network tools and utilities do not support the
STRIP driver, so you will have to download some customized tools from the
MosquitoNet web server. Details on what software you need is available at the:
<htmlurl url="http://mosquitonet.Stanford.EDU/strip.html"
	name="MosquitoNet STRIP Page">.
<p>
A summary of configuration is that you use a modified <em/slattach/ program
to set the line discipline of a serial tty device to STRIP and then configure
the resulting `<tt/st[0-9]/' 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.

<!--======================================================================-->
<sect1><heading>Token Ring
<p>
Token ring device names are `<tt/tr0/', `<tt/tr1/' 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 at a time and the station holding the
token is the only station allowed to transmit. When it has transmitted
its data it passes the token onto the next station. The token loops amongst
all active stations, hence the name `Token Ring'.

	<p><bf/Kernel Compile Options/:
	<tscreen><verb>
	Network device support  --->
		[*] Network device support
		....
		[*] Token Ring driver support
		< > IBM Tropic chipset based adaptor support
	</verb></tscreen>

Configuration of token ring is identical to that of ethernet with the exception
of the network device name to configure.

<!--======================================================================-->
<sect1><heading>X.25
<p>
X.25 is a circuit based packet switching protocol defined by the
<tt/C.C.I.T.T./ (a standards body recognized by Telecommunications companies
in most parts of the world). An implementation of X.25 and LAPB are being
worked on and recent <tt/2.1.*/ kernels include the work in progress.
<p>
Jonathon Naylor <tt>jsn@cs.nott.ac.uk</tt> is leading the development and
a mailing list has been established to discuss Linux X.25 related matters.
To subscribe send a message to: <tt/majordomo@vger.rutgers.edu/ with the
text "<tt/subscribe linux-x25/" in the body of the message.
<p>
Early versions of the configuration tools may be obtained from Jonathon's ftp
site at <htmlurl url="ftp://ftp.cs.nott.ac.uk/jsn/" name="ftp.cs.nott.ac.uk">.

<!--======================================================================-->
<sect1><heading>WaveLan Card
<p>
Wavelan device names are `<tt/eth0/', `<tt/eth1/', etc.
<p>
<bf/Kernel Compile Options/:
<tscreen><verb>
Network device support  --->
	[*] Network device support
	....
	[*] Radio network interfaces
	....
	<*> WaveLAN support
</verb></tscreen>

The WaveLAN card is a spread spectrum wireless lan card. The card looks
very like an ethernet card in practice and is configured in much the same
way.
<p>
You can get information on the Wavelan card from
<htmlurl url="http://www.wavelan.com/" name="Wavelan.com">.

<!--######################################################################-->
<sect><heading>Cables and Cabling
<p>
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 in this.

<!--======================================================================-->
<sect1><heading>Serial NULL Modem cable
<p>
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 swap transmit and receive data. This is ok but means that you
must use software flow control (XON/XOFF) which is less efficient than
hardware flow control. The following cable provides the best possible signalling
between machines and allows you to use hardware (RTS/CTS) flow control.
<tscreen><verb>
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
</verb></tscreen>

<!--======================================================================-->
<sect1><heading>Parallel port cable (PLIP cable)
<p>
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.
<tscreen><verb>
Pin Name    pin            pin
STROBE      1*
D0->ERROR   2  ----------- 15
D1->SLCT    3  ----------- 13
D2->PAPOUT  4  ----------- 12
D3->ACK     5  ----------- 10
D4->BUSY    6  ----------- 11
D5          7*
D6          8*
D7          9*
ACK->D3     10 ----------- 5
BUSY->D4    11 ----------- 6
PAPOUT->D2  12 ----------- 4
SLCT->D1    13 ----------- 3
FEED        14*
ERROR->D0   15 ----------- 2
INIT        16*
SLCTIN      17*
GROUND      25 ----------- 25
</verb></tscreen>

Notes:
<itemize>
<item>Do not connect the pins marked with an asterisk `*'.
<item>Extra grounds are 18,19,20,21,22,23 and 24.
<item>If the cable you are using has a metallic shield, it should be connected
to the metallic DB-25 shell at <bf/one end only/.
</itemize>
<bf>Warning: A miswired PLIP cable can destroy your controller card.</bf> Be
very careful and double check every connection to ensure you don't cause
yourself any unnecessary work or heartache.
<p>
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 metre 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 you really should be looking at obtaining a pair of
thin-net ethernet cards and running some coaxial cable.

<!--======================================================================-->
<sect1><heading>10base2 (thin coax) Ethernet Cabling
<p>
10base2 is an ethernet cabling standard that specifies the use of 52 ohm
coaxial cable with 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 <bf/both ends/ of the cabling.
A terminator is a 52 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 at all. Normally you'd use `T pieces' to
interconnect the machines, so that you end up with something that looks like:

<tscreen><verb>

 |==========T=============T=============T==========T==========|
            |             |             |          |
            |             |             |          |
          -----         -----         -----      -----
          |   |         |   |         |   |      |   |
          -----         -----         -----      -----

</verb></tscreen>

where the `<tt/|/' at either end represents a terminator, the
`<tt/======/' represents a length of coaxial cable with BNC plugs at either
end and the `<tt/T/' 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, ideally the `T piece' will be plugged directly into
the ethernet card.

<!--======================================================================-->
<sect1><heading>Twisted Pair Ethernet Cable
<p>
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
<htmlurl url="Ethernet-HOWTO.html" Name="Ethernet-HOWTO">

<!--######################################################################-->
<sect><heading>Glossary of Terms used in this document.
<p>
The following is a list of some of the most important terms used in this
document.
<descrip>
<p><tag>ARP</tag>This is an acronym for the <em>Address Resolution
	Protocol</em> and this is how a network machine associates an
	IP Address with a hardware address.

<p><tag>ATM</tag>This is an acronym for <em>Asynchronous Transfer
	Mode</em>.  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.

<p><tag>client</tag>This is usually the piece of software at the end
	of a system where the user is. There are exceptions to this,
	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
	<em/peer to peer/ systems such as <em/slip/ or <em/ppp/ the
	client is taken to be the end that initiates the connection
	and the remote end, being called, is taken to be the server.

<p><tag>datagram</tag>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'.

<p><tag>DLCI</tag>The DLCI is the Data Link Connection Identifier and
	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.

<p><tag>Frame Relay</tag>Frame Relay is a network technology ideally
	suited to carrying traffic that is of bursty or sporadic
	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.

<p><tag>Hardware address</tag>This is a number that uniquely
	identifies a host in a physical network at the media access
	layer. Examples of this are <em>Ethernet Addresses</em> and
	<em>AX.25 Addresses</em>.

<p><tag>ISDN</tag>This is an acronym for <em>Integrated Services
	Digital Network</em>. ISDN provides a standardized means by
	which Telecommunications companies may deliver either voice or
	data information to a customers premises.  Technically ISDN is
	a circuit switched data network.

<p><tag>ISP</tag>This is an acronym of Internet Service
	Provider. These are organizations or companies that provide
	people with network connectivity to the Internet.

<p><tag>IP address</tag>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.

<p><tag>MSS</tag>The Maximum Segment Size (<em>MSS</em>) 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.

<p><tag>MTU</tag>The Maximum Transmission Unit (<em>MTU</em>) 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 and the datagram will be
	fragmented there. Typical values are 1500 bytes for an
	ethernet interface, or 576 bytes for a SLIP interface.

<p><tag>route</tag>The <em>route</em> is the path that your datagrams
	take through the network to reach their destination.

<p><tag>server</tag>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 <em/ftp/,
	<em/Networked File System/, or <em/Domain Name Server/. In the
	case of <em/peer to peer/ systems such as <em/slip/ or
	<em/ppp/ the server is taken to be the end of the link that is
	called and the end calling is taken to be the client.

<p><tag>window</tag>The <em>window</em> is the largest amount of data
	that the receiving end can accept at a given point in time.
</descrip>
<!--######################################################################-->
<sect><heading>Linux for an ISP ?
<p>
If you are interested in using Linux for ISP purposes the I recommend you
take a look at the
<htmlurl url="http://www.anime.net/linuxisp/" name="Linux ISP homepage"> for
a good list of pointers to information you might need and use.

<!--######################################################################-->
<sect><heading>Acknowledgements
<p>
I'd like to thank the following people for their contributions to this
document (in no particular order): Terry Dawson, Axel Boldt, Arnt Gulbrandsen, Gary Allpike,
Cees de Groot, Alan Cox, Jonathon Naylor, Claes Ensson, Ron Nessim, John Minack,
Jean-Pierre Cocatrix, Erez Strauss.

<!--######################################################################-->
<sect><heading>Copyright.
<p>
<P>
<EM>Copyright Information</EM>
<P>
<P>
The NET-3-HOWTO, information on how to install and configure networking
support for Linux. Copyright (c) 1997 Terry Dawson, 1998 Alessandro Rubini,
1999 {POET} - LinuxPorts 
<P>
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. 


</article>
