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