mirror of https://github.com/tLDP/LDP
4900 lines
202 KiB
Plaintext
4900 lines
202 KiB
Plaintext
<!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/<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/<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/<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/<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/<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><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/<callahan@maths.ox.ac.uk>/
|
|
and Al Longyear <tt/<longyear@netcom.com>/ this too was critical to
|
|
increasing the number of people actively using linux for networking.
|
|
<p>
|
|
Jonathon Naylor <tt/<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[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/[-]arp/this option enables or disables use of the
|
|
address resolution protocol on this interface
|
|
|
|
<tag/[-]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 <addr>/this parameter allows you to set the network
|
|
mask of the network this device belongs to.
|
|
|
|
<tag/irq <addr>/this parameter only works on certain types of
|
|
hardware and allows you to set the IRQ of the hardware
|
|
of this device.
|
|
|
|
<tag/[-]broadcast [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/[-]pointopoint [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 <type> <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><devname>:<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><agulbra@troll.no></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 $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><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><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><werner.almesberger@lrc.di.epfl.ch></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>
|