Linux Networking-HOWTO:
Author: Joshua Drake poet@linuxports.com
v1.6.2, December 1999
A www.linuxports.com document for the Linux Documentation Project
11.. IInnttrroodduuccttiioonn..
New versions of this document can always be found first at
http://www.linuxports.com/.
Previously the document was called the Net3/4 and Net-3 Howto's. I
believe that may not have been obvious enough for certain readers. So,
I have renamed it the Networking-HOWTO.
This document has an auto contribute function located at
http://www.linuxports.com/howto/networking/updates.phtml. If you have
something that you like like to add to this document you may do so at
http://www.linuxports.com/howto/networking/updates.phtml page.
22.. DDooccuummeenntt HHiissttoorryy
The original NET-FAQ was written by Matt Welsh and Terry Dawson to
answer frequently asked questions about networking for Linux at a time
before the Linux Documentation Project had formally started. It
covered the very early development versions of the Linux Networking
Kernel. The NET-2-HOWTO superceded the NET-FAQ and was one of the
original LDP HOWTO documents, it covered what was called version 2 and
later version 3 of the Linux kernel Networking software. This document
in turn supercedes it and relates only to version 4 of the Linux
Networking Kernel or more specifically kernel releases 2.x and 2.2.x.
Previous versions of this document became quite large because of the
enormous amount of material that fell within its scope. To help reduce
this problem a number of HOWTO's dealing with specific networking
topics have been produced. This document will provide pointers to them
where relevant and cover those areas not yet covered by other
documents.
22..11.. FFeeeeddbbaacckk
We are always interested in feedback. Please contact us at:
poet@linuxports.com.
Again, if you find anything erroneous or anything you would like to
see added, please contact us.
33.. HHooww ttoo uussee tthhiiss HHOOWWTTOO..
This document is organized top-down. The first sections include
informative material and can be skipped if you are not interested;
what follows is a generic discussion of networking issues, and you
must ensure you understand this before proceeding to more specific
parts. The rest, ``technology specific'' information is grouped in
three main sections: Ethernet and IP-related information, technologies
pertaining to widespread PC hardware and seldom-used technologies.
The suggested path through the document is thus the following:
RReeaadd tthhee ggeenneerriicc sseeccttiioonnss
These sections apply to every, or nearly every, technology
described later and so are very important for you to understand.
On the other hand, I expect many of the readers to be already
confident with this material.
CCoonnssiiddeerr yyoouurr nneettwwoorrkk
You should know how your network is, or will be, designed and
exactly what hardware and technology types you will be
implementing.
RReeaadd tthhee ````EEtthheerrnneett aanndd IIPP'''' sseeccttiioonn iiff yyoouu aarree ddiirreeccttllyy ccoonnnneecctteedd
a LAN or the Internet" This section describes basic Ethernet
configuration and the various features that Linux offers for IP
networks, like firewalling, advanced routing and so on.
RReeaadd tthhee nneexxtt sseeccttiioonn iiff yyoouu aarree iinntteerreesstteedd iinn llooww--ccoosstt llooccaall
networks or dial-up connections" The section describes PLIP,
PPP, SLIP and ISDN, the widespread technologies used on personal
workstations.
RReeaadd tthhee tteecchhnnoollooggyy ssppeecciiffiicc sseeccttiioonnss rreellaatteedd ttoo yyoouurr
requirements" If your needs differ from IP and/or common
hardware, the final section covers details specific to non-IP
protocols and peculiar communication hardware.
DDoo tthhee ccoonnffiigguurraattiioonn wwoorrkk
You should actually try to configure your network and take
careful note of any problems you have.
LLooookk ffoorr ffuurrtthheerr hheellpp iiff nneeeeddeedd
If you experience problems that this document does not help you
to resolve then read the section related to where to get help or
where to report bugs.
HHaavvee ffuunn!!
Networking is fun, enjoy it.
33..11.. CCoonnvveennttiioonnss uusseedd iinn tthhiiss ddooccuummeenntt
No special convention is used here, but you must be warned about the
way commands are shown. Following the classic Unix documentation, any
command you should type to your shell is prefixed by a prompt. This
howto shows "user%" as the prompt for commands that do not require
superuser privileges, and "root#" as the prompt for commands that need
to run as root. I chose to use "root#" instead of a plain "#" to
prevent confusion with snapshots from shell scripts, where the hash
mark is used to define comment lines.
When ``Kernel Compile Options'' are shown, they are represented in the
format used by _m_e_n_u_c_o_n_f_i_g. They should be understandable even if you
(like me) are not used to _m_e_n_u_c_o_n_f_i_g. If you are in doubt about the
options' nesting, running the program once can't but help.
44.. GGeenneerraall IInnffoorrmmaattiioonn aabboouutt LLiinnuuxx NNeettwwoorrkkiinngg..
44..11.. LLiinnuuxx NNeettwwoorrkkiinngg RReessoouurrcceess..
There are a number of places where you can find good information about
Linux networking.
There are a wealth of Consultants available. A searchable listing can
be found at http://www.linuxports.com/
Alan Cox, the current maintainer of the Linux kernel networking code
maintains a world wide web page that contains highlights of current
and new developments in linux Networking at: www.uk.linux.org.
There is a newsgroup in the Linux news hierarchy dedicated to
networking and related matters, it is: comp.os.linux.networking
There is a mailing list to which you can subscribe where you may ask
questions relating to Linux networking. To subscribe you should send a
mail message:
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:
subscribe linux-net
Please remember when reporting any problem to include as much relevant
detail about the problem as you can. Specifically you should specify
the versions of software that you are using, especially the kernel
version, the version of tools such as ppppppdd// or ddiipp and the exact
nature of the problem you are experiencing. This means taking note of
the exact syntax of any error messages you receive and of any commands
that you are issuing.
44..22.. WWhheerree ttoo ggeett ssoommee nnoonn--lliinnuuxx--ssppeecciiffiicc nneettwwoorrkk iinnffoorrmmaattiioonn..
If you are after some basic tutorial information on tcp/ip networking
generally, then I recommend you take a look at the following
documents:
ttccpp//iipp iinnttrroodduuccttiioonn
this document comes as both a text version and a postscript
version.
ttccpp//iipp aaddmmiinniissttrraattiioonn
this document comes as both a text version and a postscript
version.
If you are after some more detailed information on tcp/ip networking
then I highly recommend:
_I_n_t_e_r_n_e_t_w_o_r_k_i_n_g _w_i_t_h _T_C_P_/_I_P_, _V_o_l_u_m_e _1_: _p_r_i_n_c_i_p_l_e_s_, _p_r_o_t_o_c_o_l_s
_a_n_d _a_r_c_h_i_t_e_c_t_u_r_e, by Douglas E. Comer, ISBN 0-13-227836-7,
Prentice Hall publications, Third Edition, 1995.
If you are wanting to learn about how to write network applications in
a Unix compatible environment then I also highly recommend:
_U_n_i_x _N_e_t_w_o_r_k _P_r_o_g_r_a_m_m_i_n_g, by W. Richard Stevens, ISBN
0-13-949876-1, Prentice Hall publications, 1990.
A second edition of this book is appearing on the bookshelves; the new
book is made up of three volumes: check Prenice-Hall's web site to
probe further.
You might also try the comp.protocols.tcp-ip newsgroup.
An important source of specific technical information relating to the
Internet and the tcp/ip suite of protocols are RFC's. RFC is an
acronym for `Request For Comment' and is the standard means of
submitting and documenting Internet protocol standards. There are many
RFC repositories. Many of these sites are ftp sites and other provide
World Wide Web access with an associated search engine that allows you
to search the RFC database for particular keywords.
One possible source for RFC's is at Nexor RFC database.
55.. GGeenneerriicc NNeettwwoorrkk CCoonnffiigguurraattiioonn IInnffoorrmmaattiioonn..
The following subsections you will pretty much need to know and
understand before you actually try to configure your network. They are
fundamental principles that apply regardless of the exact nature of
the network you wish to deploy.
55..11.. WWhhaatt ddoo II nneeeedd ttoo ssttaarrtt ??
Before you start building or configuring your network you will need
some things. The most important of these are:
55..11..11.. CCuurrrreenntt KKeerrnneell ssoouurrccee((OOppttiioonnaall))..
Please note:
The majority of current distributions come with networking enabled,
therefore it may not be required to recompile the kernel. If you are
running well known hardware you should be just fine. For example: 3COM
NIC, NE2000 NIC, or a Intel NIC. However if you find yourself in the
position that you do need to update the kernel, the following
information is provided.
Because the kernel you are running now might not yet have support for
the network types or cards that you wish to use you will probably need
the kernel source so that you can recompile the kernel with the
appropriate options.
For users of the major distributions such as Redhat, Caldera, Debian,
or Suse this no longer holds true. As long as you stay within the
mainstream of hardware there should be no need to recompile your
kernel unless there is a very specific feature that you need.
You can always obtain the latest kernel source from ftp.cdrom.com.
This is not the official site but they have LOTS of bandwidth and
capacity. The official site is kernel.org but please use the above if
you can. Please remember that ftp.kernel.org is seriously overloaded.
Use a mirror.
Normally the kernel source will be untarred into the /usr/src/linux
directory. For information on how to apply patches and build the
kernel you should read the Kernel-HOWTO. For information on how to
configure kernel modules you should read the ``Modules mini-HOWTO''.
Also, the README file found in the kernel sources and the
Documentation directory are very informative for the brave reader.
Unless specifically stated otherwise, I recommend you stick with the
standard kernel release (the one with the even number as the second
digit in the version number). Development release kernels (the ones
with the odd second digit) may have structural or other changes that
may cause problems working with the other software on your system. If
you are uncertain that you could resolve those sorts of problems in
addition to the potential for there being other software errors, then
don't use them.
55..11..22.. IIPP AAddddrreesssseess,, aann EExxppllaannaattiioonn..
Internet Protocol Addresses are composed of four bytes. The convention
is to write addresses in what is called `dotted decimal notation'. In
this form each byte is converted to a decimal number (0-255) dropping
any leading zero's unless the number is zero and written with each
byte separated by a `.' character. By convention each interface of a
host or router has an IP address. It is legal for the same IP address
to be used on each interface of a single machine in some circumstances
but usually each interface will have its own address.
Internet Protocol Networks are contiguous sequences of IP addresses.
All addresses within a network have a number of digits within the
address in common. The portion of the address that is common amongst
all addresses within the network is called the `network portion' of
the address. The remaining digits are called the `host portion'. The
number of bits that are shared by all addresses within a network is
called the netmask and it is role of the netmask to determine which
addresses belong to the network it is applied to and which don't. For
example, consider the following:
----------------- ---------------
Host Address 192.168.110.23
Network Mask 255.255.255.0
Network Portion 192.168.110.
Host portion .23
----------------- ---------------
Network Address 192.168.110.0
Broadcast Address 192.168.110.255
----------------- ---------------
Any address that is 'bitwise anded' with its netmask will reveal the
address of the network it belongs to. The network address is therefore
always the lowest numbered address within the range of addresses on
the network and always has the host portion of the address coded all
zeroes.
The broadcast address is a special address that every host on the
network listens to in addition to its own unique address. This address
is the one that datagrams are sent to if every host on the network is
meant to receive it. Certain types of data like routing information
and warning messages are transmitted to the broadcast address so that
every host on the network can receive it simultaneously. There are two
commonly used standards for what the broadcast address should be. The
most widely accepted one is to use the highest possible address on the
network as the broadcast address. In the example above this would be
192.168.110.255. For some reason other sites have adopted the
convention of using the network address as the broadcast address. In
practice it doesn't matter very much which you use but you must make
sure that every host on the network is configured with the same
broadcast address.
For administrative reasons some time early in the development of the
IP protocol some arbitrary groups of addresses were formed into
networks and these networks were grouped into what are called classes.
These classes provide a number of standard size networks that could be
allocated. The ranges allocated are:
--------------------------------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
--------------------------------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
--------------------------------------------------------------------------------
What addresses you should use depends on exactly what it is that you
are doing. You may have to use a combination of the following
activities to get all the addresses you need:
IInnssttaalllliinngg aa lliinnuuxx mmaacchhiinnee oonn aann eexxiissttiinngg IIPP nneettwwoorrkk
If you wish to install a linux machine onto an existing IP
network then you should contact whoever administers the network
and ask them for the following information:
+o Host IP Address
+o IP network address
+o IP broadcast address
+o IP netmask
+o Router address
+o Domain Name Server Address
You should then configure your linux network device with those
details. You can not make them up and expect your configuration
to work.
BBuuiillddiinngg aa bbrraanndd nneeww nneettwwoorrkk tthhaatt wwiillll nneevveerr ccoonnnneecctt ttoo tthhee
Internet" If you are building a private network and you never
intend that network to be connected to the Internet then you can
choose whatever addresses you like. However, for safety and
consistency reasons there have been some IP network addresses
that have been reserved specifically for this purpose. These are
specified in RFC1597 and are as follows:
-----------------------------------------------------------
| RESERVED PRIVATE NETWORK ALLOCATIONS |
-----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
-----------------------------------------------------------
| A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 |
| B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 |
| C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
You should first decide how large you want your network to be and
then choose as many of the addresses as you require.
55..22.. WWhheerree sshhoouulldd II ppuutt tthhee ccoonnffiigguurraattiioonn ccoommmmaannddss ??
There are a few different approaches to Linux system boot procedures.
After the kernel boots, it always executes a program called `_i_n_i_t'.
The _i_n_i_t program then reads its configuration file called /etc/inittab
and commences the boot process. There are a few different flavours of
_i_n_i_t around, although everyone is now converging to the System V
(Five) flavor, developed by Miguel van Smoorenburg.
Despite the fact that the _i_n_i_t program is always the same, the setup
of system boot is organized in a different way by each distribution.
Usually the /etc/inittab file contains an entry looking something
like:
si::sysinit:/etc/init.d/boot
This line specifies the name of the shell script file that actually
manages the boot sequence. This file is somewhat equivalent to the
AUTOEXEC.BAT file in MS-DOS.
There are usually other scripts that are called by the boot script and
often the network is configured within one of many of these.
The following table may be used as a guide for your system:
---------------------------------------------------------------------------
Distrib. | Interface Config/Routing | Server Initialization
---------------------------------------------------------------------------
Debian | /etc/init.d/network | /etc/rc2.d/*
---------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2
---------------------------------------------------------------------------
RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/*
---------------------------------------------------------------------------
Note that Debian and Red Hat use a whole directory to host scripts
that fire up system services (and usually information does not lie
within these files, for example Red Hat systems store all of system
configuration in files under /etc/sysconfig, whence it is retrieved by
boot scripts). If you want to grasp the details of the boot process,
my suggestion is to check _/_e_t_c_/_i_n_i_t_t_a_b and the documentation that
accompanies _i_n_i_t. Linux Journal is also going to publish an article
about system initialization, and this document will point to it as
soon as it is available on the web.
Most modern distributions include a program that will allow you to
configure many of the common sorts of network interfaces. If you have
one of these then you should see if it will do what you want before
attempting a manual configuration.
-----------------------------------------
Distrib | Network configuration program
-----------------------------------------
RedHat | /usr/bin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
55..33.. CCrreeaattiinngg yyoouurr nneettwwoorrkk iinntteerrffaacceess..
In many Unix operating systems the network devices have appearances in
the _/_d_e_v directory. This is not so in Linux. In Linux the network
devices are created dynamically in software and do not require device
files to be present.
In the majority of cases the network device is automatically created
by the device driver while it is initializing and has located your
hardware. For example, the ethernet device driver creates eth[0..n]
interfaces sequentially as it locates your ethernet hardware. The
first ethernet card found becomes eth0, the second eth1 etc.
In some cases though, notably _s_l_i_p and _p_p_p, 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 _s_l_i_p or _p_p_p devices may vary
during the uptime of the machine. These cases will be covered in more
detail in later sections.
55..44.. CCoonnffiigguurriinngg aa nneettwwoorrkk iinntteerrffaaccee.. KKeerrnneellss 22..00 aanndd 22..22
When you have all of the programs you need and your address and
network information you can configure your network interfaces. When we
talk about configuring a network interface we are talking about the
process of assigning appropriate addresses to a network device and to
setting appropriate values for other configurable parameters of a
network device. The program most commonly used to do this is the
_i_f_c_o_n_f_i_g (interface configure) command.
Typically you would use a command similar to the following:
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
In this case I'm configuring an ethernet interface `eth0' with the IP
address `192.168.0.1' and a network mask of `255.255.255.0'. The `_u_p'
that trails the command tells the interface that it should become
active, but can usually be omitted, as it is the default. To shutdown
an interface, you can just call ``ifconfig eth0 down''.
The kernel assumes certain defaults when configuring interfaces. For
example, you may specify the network address and broadcast address for
an interface, but if you don't, as in my example above, then the
kernel will make reasonable guesses as to what they should be based on
the netmask you supply and if you don't supply a netmask then on the
network class of the IP address configured. In my example the kernel
would assume that it is a class-C network being configured on the
interface and configure a network address of `192.168.0.0' and a
broadcast address of `192.168.0.255' for the interface.
There are many other options to the _i_f_c_o_n_f_i_g command. The most
important of these are:
uupp this option activates an interface (and is the default).
ddoowwnn
this option deactivates an interface.
[[--]]aarrpp
this option enables or disables use of the address resolution
protocol on this interface
[[--]]aallllmmuullttii
this option enables or disables the reception of all hardware
multicast packets. Hardware multicast enables groups of hosts to
receive packets addressed to special destinations. This may be
of importance if you are using applications like desktop
videoconferencing but is normally not used.
mmttuu NN
this parameter allows you to set the _M_T_U of this device.
nneettmmaasskk <>
this parameter allows you to set the network mask of the network
this device belongs to.
iirrqq <>
this parameter only works on certain types of hardware and
allows you to set the IRQ of the hardware of this device.
[[--]]bbrrooaaddccaasstt [[aaddddrr]]
this parameter allows you to enable and set the accepting of
datagrams destined to the broadcast address, or to disable
reception of these datagrams.
[[--]]ppooiinnttooppooiinntt [[aaddddrr]]
this parameter allows you to set the address of the machine at
the remote end of a point to point link such as for _s_l_i_p or _p_p_p.
hhww <>
this parameter allows you to set the hardware address of certain
types of network devices. This is not often useful for ethernet,
but is useful for other network types such as AX.25.
With the release of Kernel 2.2 there are a number of options available
that are not listed above. Some of the most interesting are tunneling
and IPV6 options. The ifconfig paramaters for kernel 2.2 are listed
below.
iinntteerrffaaccee
The name of the interface. This is usually a driver name
followed by a unit number, for example eth0 for the first
Ethernet interface.
uupp This flag causes the interface to be activated. It is implicitly
specified if an address is assigned to the interface.
ddoowwnn
This flag causes the driver for this interface to be shut
down.
[[--]]aarrpp
Enable or disable the use of the ARP protocol on this
interface.
[[--]]pprroommiisscc
Enable or disable the promiscuous mode of the interface.
If selected, all packets on the network will be received by the
interface.
[[--]]aallllmmuullttii
Enable or disable all-multicast mode. If selected, all
multicast packets on the network will be received by the
interface.
mmeettrriicc NN
This parameter sets the interface metric.
mmttuu NN
This parameter sets the Maximum Transfer Unit (MTU) of an
interface.
ddssttaaddddrr aaddddrr
Set the remote IP address for a point-to-point link (such as
PPP). This keyword is now obsolete; use the pointopoint keyword
instead.
nneettmmaasskk aaddddrr
Set the IP network mask for this interface. This value
defaults to the usual class A, B or C network mask (as derived
from the interface IP address), but it can be set to any
value.
aadddd aaddddrr pprreeffiixxlleenn
Add an IPv6 address to an interface.
ddeell aaddddrr pprreeffiixxlleenn
Remove an IPv6 address from an interface.
ttuunnnneell aaaa..bbbb..cccc..dddd
Create a new SIT (IPv6-in-IPv4) device, tunnelling to the given
destination.
iirrqq aaddddrr
Set the interrupt line used by this device. Not all devices
can dynamically change their IRQ set- ting.
iioo__aaddddrr aaddddrr
Set the start address in I/O space for this device.
mmeemm__ssttaarrtt aaddddrr
Set the start address for shared memory used by this device.
Only a few devices need this.
mmeeddiiaa ttyyppee
Set the physical port or medium type to be used by the device.
Not all devices can change this set- ting, and those that can
vary in what values they support. Typical values for type are
10base2 (thin Ethernet), 10baseT (twisted-pair 10Mbps
Ethernet), AUI (external transceiver) and so on. The special
medium type of auto can be used to tell the driver to auto-
sense the media. Again, not all drivers can do this.
[[--]]bbrrooaaddccaasstt [[aaddddrr]]
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.
[[--]]ppooiinnttooppooiinntt [[aaddddrr]]
This keyword enables the point-to-point mode of an interface,
meaning that it is a direct link between two machines with
nobody else listening on it. If the address argument is also
given, set the pro- tocol address of the other side of the
link, just like the obsolete dstaddr keyword does. Otherwise,
set or clear the IFF_POINTOPOINT flag for the interface.
hhww ccllaassss aaddddrreessss
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).
mmuullttiiccaasstt
Set the multicast flag on the interface. This should not
normally be needed as the drivers set the flag correctly
themselves.
aaddddrreessss
The IP address to be assigned to this interface.
ttxxqquueeuueelleenn lleennggtthh
Set the length of the transmit queue of the device. It is
useful to set this to small values for slower devices with a
high latency (modem links, ISDN) to prevent fast bulk transfers
from disturbing inter- active traffic like telnet too much.
You may use the _i_f_c_o_n_f_i_g command on any network interface. Some
user programs such as _p_p_p_d and _d_i_p automatically configure the
network devices as they create them, so manual use of _i_f_c_o_n_f_i_g
is unnecessary.
55..55.. CCoonnffiigguurriinngg yyoouurr NNaammee RReessoollvveerr..
The `_N_a_m_e _R_e_s_o_l_v_e_r' is a part of the linux standard library. Its prime
function is to provide a service to convert human-friendly hostnames
like `ftp.funet.fi' into machine friendly IP addresses such as
128.214.248.6.
55..55..11.. WWhhaatt''ss iinn aa nnaammee ??
You will probably be familiar with the appearance of Internet host
names, but may not understand how they are constructed, or
deconstructed. Internet domain names are hierarchical in nature, that
is, they have a tree-like structure. A `_d_o_m_a_i_n' is a family, or group
of names. A `_d_o_m_a_i_n' may be broken down into `_s_u_b_d_o_m_a_i_n'. A `_t_o_p_l_e_v_e_l
_d_o_m_a_i_n' 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:
CCOOMM
Commercial Organizations
EEDDUU
Educational Organizations
GGOOVV
Government Organizations
MMIILL
Military Organizations
OORRGG
Other organizations
NNEETT
Internet-Related Organizations
CCoouunnttrryy DDeessiiggnnaattoorr
these are two letters codes that represent a particular country.
For historical reasons most domains belonging to one of the non-
country based top level domains were used by organizations within the
United States, although the United States also has its own country
code `.us'. This is not true any more for .com and .org domains, which
are commonly used by non-us companies.
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 com, edu, gov, mil and org domains. So for example you end up
with: com.au and gov.au for commercial and government organizations in
Australia; note that this is not a general rule, as actual policies
depend on the naming authority for each domain.
The next level of division usually represents the name of the
organization. Further subdomains vary in nature, often the next level
of subdomain is based on the departmental structure of the
organization but it may be based on any criterion considered
reasonable and meaningful by the network administrators for the
organization.
The very left-most portion of the name is always the unique name
assigned to the host machine and is called the `_h_o_s_t_n_a_m_e', the portion
of the name to the right of the hostname is called the `_d_o_m_a_i_n_n_a_m_e'
and the complete name is called the `_F_u_l_l_y _Q_u_a_l_i_f_i_e_d _D_o_m_a_i_n _N_a_m_e'.
To use Terry's host as an example, the fully qualified domain name is
`perf.no.itg.telstra.com.au'. This means that the host name is `perf'
and the domain name is `no.itg.telstra.com.au'. The domain name is
based on a top level domain based on his country, Australia and as his
email address belongs to a commercial organization, `.com' is there as
the next level domain. The name of the company is (was) `telstra' and
their internal naming structure is based on organizational structure,
in this case the machine belongs to the Information Technology Group,
Network Operations section.
Usually, the names are fairly shorter; for example, my ISP is called
``systemy.it'' and my non-profit organization is called ``linux.it'',
without any com and org subdomain, so that my own host is just called
``morgana.systemy.it'' and rubini@linux.it is a valid email address.
Note that the owner of a domain has the rights to register hostnames
as well as subdomains; for example, the LUG I belong to uses the
domain pluto.linux.it, because the owners of linux.it agreed to open a
subdomain for the LUG.
55..55..22.. WWhhaatt iinnffoorrmmaattiioonn yyoouu wwiillll nneeeedd..
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 `_D_o_m_a_i_n _N_a_m_e _S_e_r_v_e_r', so you will need to know
the IP address of a local nameserver that you can use.
There are three files you need to edit, I'll cover each of these in
turn.
55..55..33.. //eettcc//rreessoollvv..ccoonnff
The /etc/resolv.conf is the main configuration file for the name
resolver code. Its format is quite simple. It is a text file with one
keyword per line. There are three keywords typically used, they are:
ddoommaaiinn
this keyword specifies the local domain name.
sseeaarrcchh
this keyword specifies a list of alternate domain names to
search for a hostname
nnaammeesseerrvveerr
this keyword, which may be used many times, specifies an IP
address of a domain name server to query when resolving names
An example /etc/resolv.conf might look something like:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
This example specifies that the default domain name to append to
unqualified names (ie hostnames supplied without a domain) is
maths.wu.edu.au and that if the host is not found in that domain to
also try the wu.edu.au domain directly. Two nameservers entry are
supplied, each of which may be called upon by the name resolver code
to resolve the name.
55..55..44.. //eettcc//hhoosstt..ccoonnff
The /etc/host.conf file is where you configure some items that govern
the behaviour of the name resolver code. The format of this file is
described in detail in the `resolv+' man page. In nearly all
circumstances the following example will work for you:
order hosts,bind
multi on
This configuration tells the name resolver to check the /etc/hosts
file before attempting to query a nameserver and to return all valid
addresses for a host found in the /etc/hosts file instead of just the
first.
55..55..55.. //eettcc//hhoossttss
The /etc/hosts file is where you put the name and IP address of local
hosts. If you place a host in this file then you do not need to query
the domain name server to get its IP Address. The disadvantage of
doing this is that you must keep this file up to date yourself if the
IP address for that host changes. In a well managed system the only
hostnames that usually appear in this file are an entry for the
loopback interface and the local hosts name.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
You may specify more than one host name per line as demonstrated by
the first entry, which is a standard entry for the loopback interface.
55..55..66.. RRuunnnniinngg aa nnaammee sseerrvveerr
If you want to run a local nameserver, you can do it easily. Please
refer to the DNS-HOWTO and to any documents included in your version
of _B_I_N_D (Berkeley Internet Name Domain).
55..66.. CCoonnffiigguurriinngg yyoouurr llooooppbbaacckk iinntteerrffaaccee..
The `loopback' interface is a special type of interface that allows
you to make connections to yourself. There are various reasons why you
might want to do this, for example, you may wish to test some network
software without interfering with anybody else on your network. By
convention the IP address `127.0.0.1' has been assigned specifically
for loopback. So no matter what machine you go to, if you open a
telnet connection to 127.0.0.1 you will always reach the local host.
Configuring the loopback interface is simple and you should ensure you
do (but note that this task is usually performed by the standard
initialization scripts).
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
We'll talk more about the _r_o_u_t_e command in the next section.
55..77.. RRoouuttiinngg..
Routing is a big topic. It is easily possible to write large volumes
of text about it. Most of you will have fairly simple routing
requirements, some of you will not. I will cover some basic
fundamentals of routing only. If you are interested in more detailed
information then I suggest you refer to the references provided at the
start of the document.
Let's start with a definition. What is IP routing ? Here is one that
I'm using:
IP Routing is the process by which a host with multiple net-
work connections decides where to deliver IP datagrams it
has received.
It might be useful to illustrate this with an example. Imagine a
typical office router, it might have a PPP link off the Internet, a
number of ethernet segments feeding the workstations and another PPP
link off to another office. When the router receives a datagram on any
of its network connections, routing is the mechanism that it uses to
determine which interface it should send the datagram to next. Simple
hosts also need to route, all Internet hosts have two network devices,
one is the loopback interface described above and the other is the one
it uses to talk to the rest of the network, perhaps an ethernet,
perhaps a PPP or SLIP serial interface.
Ok, so how does routing work ? Each host keeps a special list of
routing rules, called a routing table. This table contains rows which
typically contain at least three fields, the first is a destination
address, the second is the name of the interface to which the datagram
is to be routed and the third is optionally the IP address of another
machine which will carry the datagram on its next step through the
network. In linux you can see this table by using the following
command:
user% cat /proc/net/route
or by using either of the following commands:
user% /sbin/route -n
user% netstat -r
The routing process is fairly simple: an incoming datagram is
received, the destination address (who it is for) is examined and
compared with each entry in the table. The entry that best matches
that address is selected and the datagram is forwarded to the
specified interface. If the gateway field is filled then the datagram
is forwarded to that host via the specified interface, otherwise the
destination address is assumed to be on the network supported by the
interface.
To manipulate this table a special command is used. This command takes
command line arguments and converts them into kernel system calls that
request the kernel to add, delete or modify entries in the routing
table. The command is called `_r_o_u_t_e'.
A simple example. Imagine you have an ethernet network. You've been
told it is a class-C network with an address of 192.168.1.0. You've
been supplied with an IP address of 192.168.1.10 for your use and have
been told that 192.168.1.1 is a router connected to the Internet.
The first step is to configure the interface as described earlier. You
would use a command like:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
You now need to add an entry into the routing table to tell the kernel
that datagrams for all hosts with addresses that match 192.168.1.*
should be sent to the ethernet device. You would use a command similar
to:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Note the use of the `-net' argument to tell the route program that
this entry is a network route. Your other choice here is a `-host'
route which is a route that is specific to one IP address.
This route will enable you to establish IP connections with all of the
hosts on your ethernet segment. But what about all of the IP hosts
that aren't on your ethernet segment ?
It would be a very difficult job to have to add routes to every
possible destination network, so there is a special trick that is used
to simplify this task. The trick is called the `default' route. The
default route matches every possible destination, but poorly, so that
if any other entry exists that matches the required address it will be
used instead of the default route. The idea of the default route is
simply to enable you to say "and everything else should go here". In
the example I've contrived you would use an entry like:
root# route add default gw 192.168.1.1 eth0
The `gw' argument tells the route command that the next argument is
the IP address, or name, of a gateway or router machine which all
datagrams matching this entry should be directed to for further
routing.
So, your complete configuration would look like:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
If you take a close look at your network `rc' files you will find that
at least one of them looks very similar to this. This is a very common
configuration.
Let's now look at a slightly more complicated routing configuration.
Let's imagine we are configuring the router we looked at earlier, the
one supporting the PPP link to the Internet and the lan segments
feeding the workstations in the office. Lets imagine the router has
three ethernet segments and one PPP link. Our routing configuration
would look something like:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
Each of the workstations would use the simpler form presented above,
only the router needs to specify each of the network routes separately
because for the workstations the default route mechanism will capture
all of them letting the router worry about splitting them up
appropriately. You may be wondering why the default route presented
doesn't specify a `gw'. The reason for this is simple, serial link
protocols such as PPP and slip only ever have two hosts on their
network, one at each end. To specify the host at the other end of the
link as the gateway is pointless and redundant as there is no other
choice, so you do not need to specify a gateway for these types of
network connections. Other network types such as ethernet, arcnet or
token ring do require the gateway to be specified as these networks
support large numbers of hosts on them.
55..77..11.. SSoo wwhhaatt ddooeess tthhee rroouutteedd pprrooggrraamm ddoo ??
The routing configuration described above is best suited to simple
network arrangements where there are only ever single possible paths
to destinations. When you have a more complex network arrangement
things get a little more complicated. Fortunately for most of you this
won't be an issue.
The big problem with `manual routing' or `static routing' as
described, is that if a machine or link fails in your network then the
only way you can direct your datagrams another way, if another way
exists, is by manually intervening and executing the appropriate
commands. Naturally this is clumsy, slow, impractical and hazard
prone. Various techniques have been developed to automatically adjust
routing tables in the event of network failures where there are
alternate routes, all of these techniques are loosely grouped by the
term `dynamic routing protocols'.
You may have heard of some of the more common dynamic routing
protocols. The most common are probably RIP (Routing Information
Protocol) and OSPF (Open Shortest Path First Protocol). The Routing
Information Protocol is very common on small networks such as small-
medium sized corporate networks or building networks. OSPF is more
modern and more capable at handling large network configurations and
better suited to environments where there is a large number of
possible paths through the network. Common implementations of these
protocols are: `_r_o_u_t_e_d' - RIP and `_g_a_t_e_d' - RIP, OSPF and others. The
`_r_o_u_t_e_d' program is normally supplied with your Linux distribution or
is included in the `NetKit' package detailed above.
An example of where and how you might use a dynamic routing protocol
might look something like the following:
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
We have three routers A, B and C. Each supports one ethernet segment
with a Class C IP network (netmask 255.255.255.0). Each router also
has a PPP link to each of the other routers. The network forms a
triangle.
It should be clear that the routing table at router A could look like:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
This would work just fine until the link between router A and B should
fail. If that link failed then with the routing entry shown above
hosts on the ethernet segment of A could not reach hosts on the
ethernet segment on B because their datagram would be directed to
router A's ppp0 link which is broken. They could still continue to
talk to hosts on the ethernet segment of C and hosts on the C's
ethernet segment could still talk to hosts on B's ethernet segment
because the link between B and C is still intact.
But wait, if A can talk to C and C can still talk to B, why shouldn't
A route its datagrams for B via C and let C send them to B ? This is
exactly the sort of problem that dynamic routing protocols like RIP
were designed to solve. If each of the routers A, B and C were running
a routing daemon then their routing tables would be automatically
adjusted to reflect the new state of the network should any one of the
links in the network fail. To configure such a network is simple, at
each router you need only do two things. In this case for Router A:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
The `_r_o_u_t_e_d' routing daemon automatically finds all active network
ports when it starts and sends and listens for messages on each of the
network devices to allow it to determine and update the routing table
on the host.
This has been a very brief explanation of dynamic routing and where
you would use it. If you want more information then you should refer
to the suggested references listed at the top of the document.
The important points relating to dynamic routing are:
1. You only need to run a dynamic routing protocol daemon when your
Linux machine has the possibility of selecting multiple possible
routes to a destination. An example of this would be if you plan
to use IP Masquerading.
2. The dynamic routing daemon will automatically modify your routing
table to adjust to changes in your network.
3. RIP is suited to small to medium sized networks.
55..88.. CCoonnffiigguurriinngg yyoouurr nneettwwoorrkk sseerrvveerrss aanndd sseerrvviicceess..
Network servers and services are those programs that allow a remote
user to make user of your Linux machine. Server programs listen on
network ports. Network ports are a means of addressing a particular
service on any particular host and are how a server knows the
difference between an incoming telnet connection and an incoming ftp
connection. The remote user establishes a network connection to your
machine and the server program, the network daemon program, listening
on that port accepts the connection and executes. There are two ways
that network daemons may operate. Both are commonly employed in
practice. The two ways are:
ssttaannddaalloonnee
the network daemon program listens on the designated network
port and when an incoming connection is made it manages the
network connection itself to provide the service.
ssllaavvee ttoo tthhee _i_n_e_t_d sseerrvveerr
the _i_n_e_t_d server is a special network daemon program that
specializes in managing incoming network connections. It has a
configuration file which tells it what program needs to be run
when an incoming connection is received. Any service port may be
configured for either of the tcp or udp protcols. The ports are
described in another file that we will talk about soon.
There are two important files that we need to configure. They are the
/etc/services file which assigns names to port numbers and the
/etc/inetd.conf file which is the configuration file for the _i_n_e_t_d
network daemon.
55..88..11.. //eettcc//sseerrvviicceess
The /etc/services file is a simple database that associates a human
friendly name to a machine friendly service port. Its format is quite
simple. The file is a text file with each line representing and entry
in the database. Each entry is comprised of three fields separated by
any number of whitespace (tab or space) characters. The fields are:
name port/protocol aliases # comment
nnaammee
a single word name that represents the service being described.
ppoorrtt//pprroottooccooll
this field is split into two subfields.
ppoorrtt
a number that specifies the port number the named service will
be available on. Most of the common services have assigned
service numbers. These are described in RFC-1340.
pprroottooccooll
this subfield may be set to either tcp or udp.
It is important to note that an entry of 18/tcp is very
different from an entry of 18/udp and that there is no technical
reason why the same service needs to exist on both. Normally
common sense prevails and it is only if a particular service is
available via both tcp and udp that you will see an entry for
both.
aalliiaasseess
other names that may be used to refer to this service entry.
Any text appearing in a line after a `#' character is ignored and
treated as a comment.
55..88..11..11.. AAnn eexxaammppllee //eettcc//sseerrvviicceess ffiillee..
All modern linux distributions provide a good /etc/services file.
Just in case you happen to be building a machine from the ground up,
here is a copy of the /etc/services file supplied with an old Debian
distribution:
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 - private
smtp 25/tcp mail
# 26 - unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 - reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman's Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin' (v5)
kshell 544/tcp krcmd # Kerberized `rsh' (v5)
kerberos-adm 749/tcp # Kerberos `kadmin' (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations. For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined. This list specifies the port used by the server process as its
#> contact port. While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually uses UDP only
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos "passwd"
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot
# Local services
In the real world, the actual file is always growing as new services
are being created. If you fear your own copy is incomplete, I'd
suggest to copy a new /etc/services from a recent distribution.
55..88..22.. //eettcc//iinneettdd..ccoonnff
The /etc/inetd.conf file is the configuration file for the _i_n_e_t_d
server daemon. Its function is to tell _i_n_e_t_d what to do when it
receives a connection request for a particular service. For each
service that you wish to accept connections for you must tell _i_n_e_t_d
what network server daemon to run and how to run it.
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 `#' is ignored and considered a comment. Each line
contains seven fields separated by any number of whitespace (tab or
space) characters. The general format is as follows:
service socket_type proto flags user server_path server_args
sseerrvviiccee
is the service relevant to this configuration as taken from the
/etc/services file.
ssoocckkeett__ttyyppee
this field describes the type of socket that this entry will
consider relevant, allowable values are: stream, dgram, raw,
rdm, or seqpacket. This is a little technical in nature, but as
a rule of thumb nearly all tcp based services use stream and
nearly all udp based services use dgram. It is only very special
types of server daemons that would use any of the other values.
pprroottoo
the protocol to considered valid for this entry. This should
match the appropriate entry in the /etc/services file and will
typically be either tcp or udp. Sun RPC (Remote Procedure Call)
based servers will use rpc/tcp or rpc/udp.
ffllaaggss
there are really only two possible settings for this field.
This field setting tells _i_n_e_t_d whether the network server
program frees the socket after it has been started and therefore
whether _i_n_e_t_d can start another one on the next connection
request, or whether _i_n_e_t_d should wait and assume that any server
daemon already running will handle the new connection request.
Again this is a little tricky to work out, but as a rule of
thumb all tcp servers should have this entry set to nowait and
most udp servers should have this entry set to wait. Be warned
there are some notable exceptions to this, so let the example
guide you if you are not sure.
uusseerr
this field describes which user account from /etc/passwd will be
set as the owner of the network daemon when it is started. This
is often useful if you want to safeguard against security risks.
You can set the user of an entry to the nobody user so that if
the network server security is breached the possible damage is
minimized. Typically this field is set to root though, because
many servers require root privileges in order to function
correctly.
sseerrvveerr__ppaatthh
this field is pathname to the actual server program to execute
for this entry.
sseerrvveerr__aarrggss
this field comprises the rest of the line and is optional. This
field is where you place any command line arguments that you
wish to pass to the server daemon program when it is launched.
55..88..22..11.. AAnn eexxaammppllee //eettcc//iinneettdd..ccoonnff
As for the /etc/services file all modern distributions will include a
good /etc/inetd.conf file for you to work with. Here, for completeness
is the /etc/inetd.conf file from the Debian distribution.
# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias
#
#
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i
55..99.. OOtthheerr mmiisscceellllaanneeoouuss nneettwwoorrkk rreellaatteedd ccoonnffiigguurraattiioonn ffiilleess..
There are a number of miscellaneous files relating to network
configuration under linux that you might be interested in. You may
never have to modify these files, but it is worth describing them so
you know what they contain and what they are for.
55..99..11.. //eettcc//pprroottooccoollss
The /etc/protocols file is a database that maps protocol id numbers
against protocol names. This is used by programmers to allow them to
specify protocols by name in their programs and also by some programs
such as _t_c_p_d_u_m_p to allow them to display names instead of numbers in
their output. The general syntax of the file is:
protocolname number aliases
The /etc/protocols file supplied with the Debian distribution is as
follows:
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # Internet Group Management
ggp 3 GGP # gateway-gateway protocol
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
st 5 ST # ST datagram mode
tcp 6 TCP # transmission control protocol
egp 8 EGP # exterior gateway protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hmp 20 HMP # host monitoring protocol
xns-idp 22 XNS-IDP # Xerox NS IDP
rdp 27 RDP # "reliable datagram" protocol
iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4
xtp 36 XTP # Xpress Tranfer Protocol
ddp 37 DDP # Datagram Delivery Protocol
idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport
rspf 73 RSPF # Radio Shortest Path First.
vmtp 81 VMTP # Versatile Message Transport
ospf 89 OSPFIGP # Open Shortest Path First IGP
ipip 94 IPIP # Yet Another IP encapsulation
encap 98 ENCAP # Yet Another IP encapsulation
55..99..22.. //eettcc//nneettwwoorrkkss
The /etc/networks file has a similar function to that of the
/etc/hosts file. It provides a simple database of network names
against network addresses. Its format differs in that there may be
only two fields per line and that the fields are coded as:
networkname networkaddress
An example might look like:
loopnet 127.0.0.0
localnet 192.168.0.0
amprnet 44.0.0.0
When you use commands like the _r_o_u_t_e command, if a destination is a
network and that network has an entry in the /etc/networks file then
the route command will display that network name instead of its
address.
55..1100.. NNeettwwoorrkk SSeeccuurriittyy aanndd aacccceessss ccoonnttrrooll..
Let me start this section by warning you that securing your machine
and network against malicious attack is a complex art. I do not
consider myself an expert in this field at all and while the following
mechanisms I describe will help, if you are serious about security
then I recommend you do some research of your own into the subject.
There are many good references on the Internet relating to the
subject, including the Security-HOWTO
An important rule of thumb is: `DDoonn''tt rruunn sseerrvveerrss yyoouu ddoonn''tt iinntteenndd ttoo
uussee'. Many distributions come configured with all sorts of services
configured and automatically started. To ensure even a minimum level
of safety you should go through your /etc/inetd.conf file and comment
out (_p_l_a_c_e _a _`_#_' _a_t _t_h_e _s_t_a_r_t _o_f _t_h_e _l_i_n_e) any entries for services
you don't intend to use. Good candidates are services such as: shell,
login, exec, uucp, ftp and informational services such as finger,
netstat and systat.
There are all sorts of security and access control mechanisms, I'll
describe the most elementary of them.
55..1100..11.. //eettcc//ffttppuusseerrss
The /etc/ftpusers file is a simple mechanism that allows you to deny
certain users from logging into your machine via ftp. The
/etc/ftpusers file is read by the ftp daemon program (_f_t_p_d) when an
incoming ftp connection is received. The file is a simple list of
those users who are disallowed from logging in. It might looks
something like:
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
55..1100..22.. //eettcc//sseeccuurreettttyy
The /etc/securetty file allows you to specify which tty devices root
is allowed to login on. The /etc/securetty file is read by the login
program (usually _/_b_i_n_/_l_o_g_i_n). Its format is a list of the tty devices
names allowed, on all others root login is disallowed:
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
55..1100..33.. TThhee ttccppdd hhoossttss aacccceessss ccoonnttrrooll mmeecchhaanniissmm..
The _t_c_p_d program you will have seen listed in the same /etc/inetd.conf
provides logging and access control mechanisms to services it is
configured to protect.
When it is invoked by the _i_n_e_t_d program it reads two files containing
access rules and either allows or denies access to the server it is
protecting accordingly.
It will search the rules files until the first match is found. If no
match is found then it assumes that access should be allowed to
anyone. The files it searches in sequence are: /etc/hosts.allow,
/etc/hosts.deny. I'll describe each of these in turn. For a complete
description of this facility you should refer to the appropriate _m_a_n
pages (hosts_access(5) is a good starting point).
55..1100..33..11.. //eettcc//hhoossttss..aallllooww
The /etc/hosts.allow file is a configuration file of the
_/_u_s_r_/_s_b_i_n_/_t_c_p_d program. The hosts.allow file contains rules describing
which hosts are _a_l_l_o_w_e_d access to a service on your machine.
The file format is quite simple:
# /etc/hosts.allow
#
# : [: command]
service list
is a comma delimited list of server names that this rule applies
to. Example server names are: ftpd, telnetd and fingerd.
host list
is a comma delimited list of host names. You may also use IP
addresses here. You may additionally specify hostnames or
addresses using wildcard characters to match groups of hosts.
Examples include: gw.vk2ktj.ampr.org to match a specific host,
.uts.edu.au to match any hostname ending in that string, 44. to
match any IP address commencing with those digits. There are
some special tokens to simplify configuration, some of these
are: ALL matches every host, LOCAL matches any host whose name
does not contain a `.' ie is in the same domain as your machine
and PARANOID matches any host whose name does not match its
address (name spoofing). There is one last token that is also
useful. The EXCEPT token allows you to provide a list with
exceptions. This will be covered in an example later.
command
is an optional parameter. This parameter is the full pathname of
a command that would be executed everytime this rule is matched.
It could for example run a command that would attempt to
identify who is logged onto the connecting host, or to generate
a mail message or some other warning to a system administrator
that someone is attempting to connect. There are a number of
expansions that may be included, some common examples are: %h
expands to the name of the connecting host or address if it
doesn't have a name, %d the daemon name being called.
An example:
# /etc/hosts.allow
#
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
55..1100..33..22.. //eettcc//hhoossttss..ddeennyy
The /etc/hosts.deny file is a configuration file of the _/_u_s_r_/_s_b_i_n_/_t_c_p_d
program. The hosts.deny file contains rules describing which hosts are
_d_i_s_a_l_l_o_w_e_d access to a service on your machine.
A simple sample would look something like this:
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
The PARANOID entry is really redundant because the other entry traps
everything in any case. Either of these entry would make a reasonable
default depending on your particular requirement.
Having an ALL: ALL default in the /etc/hosts.deny and then
specifically enabling on those services and hosts that you want in the
/etc/hosts.allow file is the safest configuration.
55..1100..44.. //eettcc//hhoossttss..eeqquuiivv
The hosts.equiv file is used to grant certain hosts and users access
rights to accounts on your machine without having to supply a
password. This is useful in a secure environment where you control all
machines, but is a security hazard otherwise. Your machine is only as
secure as the least secure of the trusted hosts. To maximize security,
don't use this mechanism and encourage your users not to use the
.rhosts file as well.
55..1100..55.. CCoonnffiigguurree yyoouurr ffttpp ddaaeemmoonn pprrooppeerrllyy..
Many sites will be interested in running an anonymous _f_t_p 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 _f_t_p daemon properly for anonymous access. Most _m_a_n pages
for ftpd(8) describe in some length how to go about this. You should
always ensure that you follow these instructions. An important tip is
to not use a copy of your /etc/passwd file in the anonymous account
/etc directory, make sure you strip out all account details except
those that you must have, otherwise you will be vulnerable to brute
force password cracking techniques.
55..1100..66.. NNeettwwoorrkk FFiirreewwaalllliinngg..
Not allowing datagrams to even reach your machine or servers is an
excellent means of security. This is covered in depth in the Firewall-
HOWTO, and (more concisely) in a later section of this document.
55..1100..77.. OOtthheerr ssuuggggeessttiioonnss..
Here are some other, potentially religious suggestions for you to
consider.
sseennddmmaaiill
despite its popularity the _s_e_n_d_m_a_i_l daemon appears with
frightening regularity on security warning announcements. Its up
to you, but I choose not to run it.
NNFFSS aanndd ootthheerr SSuunn RRPPCC sseerrvviicceess
be wary of these. There are all sorts of possible exploits for
these services. It is difficult finding an option to services
like NFS, but if you configure them, make sure you are careful
with who you allow mount rights to.
66.. EEtthheerrnneett IInnffoorrmmaattiioonn
This section covers information specific to Ethernet and the
configuring of Ethernet Cards.
66..11.. SSuuppppoorrtteedd EEtthheerrnneett CCaarrddss
66..11..11.. 33CCoomm
+o 3Com 3c501 - `avoid like the plague'' (3c501 driver)
+o 3Com 3c503 (3c503 driver), 3c505 (3c505 driver), 3c507 (3c507
driver), 3c509/3c509B (ISA) / 3c579 (EISA)
+o 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)
+o 3Com 3ccfe575 Cyclone Cardbus (3c59x driver)
+o 3Com 3c575 series Cardbus (3c59x driver) (ALL PCMCIA ??)
66..11..22.. AAMMDD,, AATTTT,, AAlllliieedd TTeelleessiiss,, AAnnsseell,, AApprriiccoott
+o AMD LANCE (79C960) / PCnet-ISA/PCI (AT1500, HP J2405A,
NE1500/NE2100)
+o ATT GIS WaveLAN
+o Allied Telesis AT1700
+o Allied Telesis LA100PCI-T
+o Allied Telesyn AT2400T/BT ("ne" module)
+o Ansel Communications AC3200 (EISA)
+o Apricot Xen-II / 82596
66..11..33.. CCaabblleettrroonn,, CCooggeenntt,, CCrryyssttaall LLaann
+o Cabletron E21xx
+o Cogent EM110
+o Crystal Lan CS8920, Cs8900
66..11..44.. DDaannppeexx,, DDEECC,, DDiiggii,, DDLLiinnkk
+o Danpex EN-9400
+o DEC DE425 (EISA) / DE434/DE435 (PCI) / DE450/DE500 (DE4x5 driver)
+o DEC DE450/DE500-XA (dc21x4x) (Tulip driver)
+o DEC DEPCA and EtherWORKS
+o DEC EtherWORKS 3 (DE203, DE204, DE205)
+o DECchip DC21x4x "Tulip"
+o DEC QSilver's (Tulip driver)
+o Digi International RightSwitch
+o DLink DE-220P, DE-528CT, DE-530+, DFE-500TX, DFE-530TX
66..11..55.. FFuujjiittssuu,, HHPP,, IICCLL,, IInntteell
+o Fujitsu FMV-181/182/183/184
+o HP PCLAN (27245 and 27xxx series)
+o HP PCLAN PLUS (27247B and 27252A)
+o HP 10/100VG PCLAN (J2577, J2573, 27248B, J2585) (ISA/EISA/PCI)
+o ICL EtherTeam 16i / 32 (EISA)
+o Intel EtherExpress
+o Intel EtherExpress Pro
66..11..66.. KKTTII,, MMaaccrroommaattee,, NNCCRR NNEE22000000//11000000,, NNeettggeeaarr,, NNeeww MMeeddiiaa
+o KTI ET16/P-D2, ET16/P-DC ISA (work jumperless and with hardware-
configuration options)
+o Macromate MN-220P (PnP or NE2000 mode)
+o NCR WaveLAN
+o NE2000/NE1000 (be careful with clones)
+o Netgear FA-310TX (Tulip chip)
+o New Media Ethernet
66..11..77.. PPuurreeDDaattaa,, SSEEEEQQ,, SSMMCC
+o PureData PDUC8028, PDI8023
+o SEEQ 8005
+o SMC Ultra / EtherEZ (ISA)
+o SMC 9000 series
+o SMC PCI EtherPower 10/100 (DEC Tulip driver)
+o SMC EtherPower II (epic100.c driver)
66..11..88.. SSuunn LLaannccee,, SSuunn IInntteell,, SScchhnneeiiddeerr,, WWDD,, ZZeenniitthh,, IIBBMM,, EEnnyyxx
+o Sun LANCE adapters (kernel 2.2 and newer)
+o Sun Intel adapters (kernel 2.2 and newer)
+o Schneider and Koch G16
+o Western Digital WD80x3
+o Zenith Z-Note / IBM ThinkPad 300 built-in adapter
+o Znyx 312 etherarray (Tulip driver)
66..22.. GGeenneerraall EEtthheerrnneett IInnffoorrmmaattiioonn
Ethernet devices names are `eth0', `eth1', `eth2' etc. The first card
detected by the kernel is assigned `eth0' and the rest are assigned
sequentially in the order they are detected.
Once you have your kernel properly built to support your ethernet card
then configuration of the card is easy.
Typically you would use something like (which most distributions
already do for you, if you configured them to support your ethernet):
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
Most of the ethernet drivers were developed by Donald Becker
66..33.. UUssiinngg 22 oorr mmoorree EEtthheerrnneett CCaarrddss iinn tthhee ssaammee mmaacchhiinnee
66..33..11.. IIff yyoouurr ddrriivveerr iiss aa mmoodduullee ((NNoorrmmaall wwiitthh nneewweerr ddiissttrrooss))
The module will typically can detect all of the installed cards.
Information fromt he detection is stored in the file:
_/_e_t_c_/_c_o_n_f_._m_o_d_u_l_e_s_.
Consider that a user has 3 NE2000 cards, one at 0x300 one at 0x240,
and one at 0x220. You would add the following lines to the
/etc/conf.modules file:
alias eth0 ne
alias eth1 ne
alias eth2 ne
options ne io=0x220,0x240,0x300
What this does is tell the program _m_o_d_p_r_o_b_e to look for 3 NE based
cards at the following addresses. It also states in which order they
should be found and the device they should be assigned.
Most ISA modules can take multiple comma separated I/O values. For
example:
alias eth0 3c501
alias eth1 3c501
options eth0 -o 3c501-0 io=0x280 irq=5
options eth1 -o 3c501-1 io=0x300 irq=7
The -o option allows for a unique name to be assigned to each module.
The reason for this is that you can not have two copies of the same
module loaded.
The irq= option is used to specify the hardware IRQ and the io= to
specify the different io ports.
By default, the Linux kernel only probes for one Ethernet device, you
need to pass command line arguments to the kernel in order to force
detection of furter boards.
To learn how to make your ethernet card(s) working under Linux you
should refer to the Ethernet-HOWTO.
77.. IIPP RReellaatteedd IInnffoorrmmaattiioonn
This section covers information specific to IP.
77..11.. DDHHCCPP aanndd DDHHCCPPDD
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 commonly used parameters by the hosts using
a DHCP server.
Each time the host boots up it will broadcast a packet to the network.
This packet is a call to any DHCP servers that are located on the same
segment to configure the host.
DHCP is extermely useful in assigning items such as the IP address,
Netmask, and gateway of each host.
77..22.. DDHHCCPP CClliieenntt SSeettuupp ffoorr uusseerrss ooff LLiinnuuxxCCoonnff
Under linux as the user root start the program linuxconf. This
program comes with all versions of redhat and works with X as well as
the console. It also works for SuSe, and Caldera.
Select Networking
----------------->Basic Host Information
----------------->Select Enable
----------------->Set Config Mode DHCP
77..33.. DDHHCCPP SSeerrvveerr SSeettuupp ffoorr LLiinnuuxx
RReettrriieevvee DDHHCCPPDD iiff yyoouurr mmaacchhiinnee ddooeess nnoott aallrreeaaddyy hhaavvee iitt iinnssttaalllleedd..
Get DHCPD
_Q_u_i_c_k _N_o_t_e_: _M_A_K_E _S_U_R_E _Y_O_U _H_A_V_E _M_U_L_T_I_C_A_S_T _E_N_A_B_L_E_D _I_N _T_H_E _K_E_R_N_E_L_.
_I_f _t_h_e_r_e _i_s _n_o_t _a _b_i_n_a_r_y _d_i_s_t_r_i_b_u_t_i_o_n _f_o_r _y_o_u_r _v_e_r_s_i_o_n _o_f _l_i_n_u_x _y_o_u
_w_i_l_l _h_a_v_e _t_o _c_o_m_p_i_l_e _D_H_C_P_D_.
Edit your /etc/rc.d/rc.local to reflect an addition of a route for
255.255.255.255.
_Q_u_o_t_e_d _f_r_o_m _D_H_C_P_d _R_E_A_D_M_E_:
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 (here, that's
192.5.5.223). This results in a DHCP protocol violation, and while
many DHCP clients don't notice the problem, some (e.g., all Microsoft
DHCP clients) do. Clients that have this problem will appear not to
see DHCPOFFER messages from the server.
Type the following as root:
route add -host 255.255.255.255 dev eth0
If the message appears:
255.255.255.255: Unknown host
Try adding the following entry to your /etc/hosts file:
255.255.255.255 dhcp
Then, try:
route add -host dhcp dev eth0
77..33..11.. OOppttiioonnss ffoorr DDHHCCPPDD
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 linuxconf. This makes configuring and
managing DHCPD extremely simple.
If you want to configure it by hand follow instructions below. I
suggest configuring it by hand at least once. It will help in the
diagnostics that a GUI can't give you. Unfortunately Micrsoft doesn't
believe this.
The easiest thing to do is assign IP addresses randomly. Below is a
sample configuration file that shows this type of setup.
# 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;
}
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.
It will lease an IP address for 1200 seconds if the client doesn't
request a longer time frame. Otherwise the maximum (allowed) lease the
server will allow is 9200 seconds. The server send the following
paramaters to the client:
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.
If you specify a WINS server for your Windows clients you need to
include the following option in the dhcpd.conf file.
option netbios-name-servers 192.168.1.1;
You can also assign specific IP addresses based on clients ethernet
MMAACC address e.g.
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 192.168.1.222;
}
This will assign IP address 192.168.1.222 to a client with ethernet
MMAACC address of 08:00:2b:4c:59:23.
77..33..22.. SSttaarrttiinngg tthhee sseerrvveerr
In most cases the DHCP installation doesn't create a dhcpd.leases
file. Therefore before you start the server you must type to create
an empty file:
_t_o_u_c_h _/_v_a_r_/_s_t_a_t_e_/_d_h_c_p_/_d_h_c_p_d_._l_e_a_s_e_s
To start the DHCP server, simply type (or include in the bootup
scripts)
_/_u_s_r_/_s_b_i_n_/_d_h_c_p_d
This will start dhcpd on eth0 device. If you need to start it on
another device simply supply it on the command line e.g.
_/_u_s_r_/_s_b_i_n_/_d_h_c_p_d _e_t_h_1
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.
_/_u_s_r_/_s_b_i_n_/_d_h_c_p_d _-_d _-_f
BBoooott uupp aa cclliieenntt take a look at the console of the server. You will
see a number of debugging messages come up.
_Y_o_u_r _d_o_n_e
77..44.. EEQQLL -- mmuullttiippllee lliinnee ttrraaffffiicc eeqquuaalliisseerr
The EQL device name is `eql'. With the standard kernel source you may
have only one EQL device per machine. EQL provides a means of
utilizing multiple point to point lines such as PPP, slip or plip as a
single logical link to carry tcp/ip. Often it is cheaper to use
multiple lower speed lines than to have one high speed line installed.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
<*> EQL (serial line load balancing) support
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.
To configure EQL you will need the eql tools which are available from:
metalab.unc.edu.
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 _i_f_c_o_n_f_i_g
utility, so something like:
root# ifconfig eql 192.168.10.1 mtu 1006
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.
Lastly you need to associate the serial link with the EQL device, this
is called `enslaving' and is done with the _e_q_l___e_n_s_l_a_v_e command as
shown:
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
The `_e_s_t_i_m_a_t_e_d _s_p_e_e_d' parameter you supply _e_q_l___e_n_s_l_a_v_e doesn't do
anything directly. It is used by the EQL driver to determine what
share of the datagrams that device should receive, so you can fine
tune the balancing of the lines by playing with this value.
To disassociate a line from an EQL device you use the _e_q_l___e_m_a_n_c_i_p_a_t_e
command as shown:
root# eql_emancipate eql sl0
You add routing as you would for any other point to point link, except
your routes should refer to the eql device rather than the actual
serial devices themselves, typically you would use:
root# route add default eql
The EQL driver was developed by Simon Janes, simon@ncm.com.
77..55.. IIPP AAccccoouunnttiinngg ((ffoorr LLiinnuuxx--22..00))
The IP accounting features of the Linux kernel allow you to collect
and analyze some network usage data. The data collected comprises the
number of packets and the number of bytes accumulated since the
figures were last reset. You may specify a variety of rules to
categorize the figures to suit whatever purpose you may have. This
option has been removed in kernel 2.1.102, because the old ipfwadm-
based firewalling was replaced by ``ipfwchains''.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] IP: accounting
After you have compiled and installed the kernel you need to use the
_i_p_f_w_a_d_m command to configure IP accounting. There are many different
ways of breaking down the accounting information that you might
choose. I've picked a simple example of what might be useful to use,
you should read the _i_p_f_w_a_d_m man page for more information.
Scenario: You have a ethernet network that is linked to the internet
via a PPP link. On the ethernet you have a machine that offers a
number of services and that you are interested in knowing how much
traffic is generated by each of ftp and world wide web traffic, as
well as total tcp and udp traffic.
You might use a command set that looks like the following, which is
shown as a shell script:
#!/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
#
The names ``ftp-data'' and ``www'' refer to lines in /etc/services.
The last command lists each of the Accounting rules and displays the
collected totals.
An important point to note when analyzing IP accounting is that ttoottaallss
ffoorr aallll rruulleess tthhaatt mmaattcchh wwiillll bbee iinnccrreemmeenntteedd so that to obtain
differential figures you need to perform appropriate maths. For
example if I wanted to know how much data was not ftp nor www I would
substract the individual totals from the rule that matches all ports.
root# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> *
231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 out udp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
77..55..11.. IIPP AAccccoouunnttiinngg ((ffoorr LLiinnuuxx--22..22))
The new accounting code is accessed via ``IP Firewall Chains''. See
the IP chains home page for more information. Among other things,
you'll now need to use _i_p_c_h_a_i_n_s instead of ipfwadm to configure your
filters. (From Documentation/Changes in the latest kernel sources).
77..66.. IIPP AAlliiaassiinngg
There are some applications where being able to configure multiple IP
addresses to a single network device is useful. Internet Service
Providers often use this facility to provide a `customized' to their
World Wide Web and ftp offerings for their customers. You can refer to
the ``IP-Alias mini-HOWTO'' for more information than you find here.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
....
[*] Network aliasing
....
<*> IP: aliasing support
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 :,
e.g. eth0:0, ppp0:10 etc. Note that the the ifname:number device can
only be configured _a_f_t_e_r the main interface has been set up.
For example, assume you have an ethernet network that supports two
different IP subnetworks simultaneously and you wish your machine to
have direct access to both, you could use something like:
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
To delete an alias you simply add a `-' to the end of its name and
refer to it and is as simple as:
root# ifconfig eth0:0- 0
All routes associated with that alias will also be deleted
automatically.
77..77.. IIPP FFiirreewwaallll ((ffoorr LLiinnuuxx--22..00))
IP Firewall and Firewalling issues are covered in more depth in the
Firewall-HOWTO. IP Firewalling allows you to secure your machine
against unauthorized network access by filtering or allowing datagrams
from or to IP addresses that you nominate. There are three different
classes of rules, incoming filtering, outgoing filtering and
forwarding filtering. Incoming rules are applied to datagrams that are
received by a network device. Outgoing rules are applied to datagrams
that are to be transmitted by a network device. Forwarding rules are
applied to datagrams that are received and are not for this machine,
ie datagrams that would be routed.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
Configuration of the IP firewall rules is performed using the _i_p_f_w_a_d_m
command. As I mentioned earlier, security is not something I am expert
at, so while I will present an example you can use, you should do your
own research and develop your own rules if security is important to
you.
Probably the most common use of IP firewall is when you are using your
linux machine as a router and firewall gateway to protect your local
network from unauthorized access from outside your network.
The following configuration is based on a contribution from Arnt
Gulbrandsen, .
The example describes the configuration of the firewall rules on the
Linux firewall/router machine illustrated in this diagram:
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
The following commands would normally be placed in an rc file so that
they were automatically started each time the system boots. For
maximum security they would be performed after the network interfaces
are configured, but before the interfaces are actually brought up to
prevent anyone gaining access while the firewall machine is rebooting.
#!/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
Good firewall configurations are a little tricky. This example should
be a reasonable starting point for you. The _i_p_f_w_a_d_m manual page offers
some assistance in how to use the tool. If you intend to configure a
firewall, be sure to ask around and get as much advice from sources
you consider reliable and get someone to test/sanity check your
configuration from the outside.
77..77..11.. IIPP FFiirreewwaallll ((ffoorr LLiinnuuxx--22..22))
The new firewalling code is accessed via ``IP Firewall Chains''. See
the IP chanins home page for more information. Among other things,
you'll now need to use _i_p_c_h_a_i_n_s instead of ipfwadm to configure your
filters. (From Documentation/Changes in the latest kernel sources).
We are aware that this is a sorely out of date statement and we are
currently working on getting this section more current. You can expect
a newer version in sometime 1999.
77..88.. IIPPIIPP EEnnccaappssuullaattiioonn
Why would you want to encapsulate IP datagrams within IP datagrams? It
must seem an odd thing to do if you've never seen an application of it
before. Ok, here are a couple of common places where it is used:
Mobile-IP and IP-Multicast. What is perhaps the most widely spread use
of it though is also the least well known, Amateur Radio.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
<*> IP: tunneling
IP tunnel devices are called `tunl0', `tunl1' etc.
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
network comprises a network address and a network mask. This produces
a series of contiguous addresses that may all be routed via a single
routing entry. This is very convenient, but it means that you may
only use any particular IP address while you are connected to the
particular piece of network to which it belongs. In most instances
this is ok, but if you are a mobile netizen then you may not be able
to stay connected to the one place all the time. IP/IP encapsulation
(IP tunneling) allows you to overcome this restriction by allowing
datagrams destined for your IP address to be wrapped up and redirected
to another IP address. If you know that you're going to be operating
from some other IP network for some time you can set up a machine on
your home network to accept datagrams to your IP address and redirect
them to the address that you will actually be using temporarily.
77..88..11.. AA ttuunnnneelleedd nneettwwoorrkk ccoonnffiigguurraattiioonn..
192.168.1/24 192.168.2/24
- -
| ppp0 = ppp0 = |
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii |
| |
| /-----\ /-----\ |
| | | // | | |
|---| A |------//---------| B |---|
| | | // | | |
| \-----/ \-----/ |
| |
- -
The diagram illustrates another possible reason to use IPIP encapsula-
tion, virtual private networking. This example presupposes that you
have two machines each with a simple dial up internet connection. Each
host is allocated just a single IP address. Behind each of these
machines are some private local area networks configured with reserved
IP network addresses. Suppose that you want to allow any host on net-
work A to connect to any host on network B, just as if they were prop-
erly connected to the Internet with a network route. IPIP encapsula-
tion will allow you to do this. Note, encapsulation does not solve the
problem of how you get the hosts on networks A and B to talk to any
other on the Internet, you still need tricks like IP Masquerade for
that. Encapsulation is normally performed by machine functioning as
routers.
Linux router `A' would be configured with a script like the following:
#!/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
Linux router `B' would be configured with a similar script:
#!/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
The command:
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP
encap datagram with a destination address of aaa.bbb.ccc.ddd'.
Note that the configurations are reciprocated at either end. The
tunnel device uses the `gw' in the route as the _d_e_s_t_i_n_a_t_i_o_n of the IP
datagram in which it will place the datagram it has received to route.
That machine must know how to decapsulate IPIP datagrams, that is, it
must also be configured with a tunnel device.
77..88..22.. AA ttuunnnneelleedd hhoosstt ccoonnffiigguurraattiioonn..
It doesn't have to be a whole network you route. You could for example
route just a single IP address. In that instance you might configure
the tunl device on the `remote' machine with its home IP address and
at the A end just use a host route (and Proxy Arp) rather than a
network route via the tunnel device. Let's redraw and modify our
configuration appropriately. Now we have just host `B' which to want
to act and behave as if it is both fully connected to the Internet and
also part of the remote network supported by host `A':
192.168.1/24
-
| ppp0 = ppp0 =
| aaa.bbb.ccc.ddd fff.ggg.hhh.iii
|
| /-----\ /-----\
| | | // | |
|---| A |------//---------| B |
| | | // | |
| \-----/ \-----/
| also: 192.168.1.12
-
Linux router `A' would be configured with:
#!/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
Linux host `B' would be configured with:
#!/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
This sort of configuration is more typical of a Mobile-IP application.
Where a single host wants to roam around the Internet and maintain a
single usable IP address the whole time. You should refer to the
Mobile-IP section for more information on how that is handled in
practice.
77..99.. IIPP MMaassqquueerraaddee
Many people have a simple dialup account to connect to the Internet.
Nearly everybody using this sort of configuration is allocated a
single IP address by the Internet Service Provider. This is normally
enough to allow only one host full access to the network. IP
Masquerade is a clever trick that enables you to have many machines
make use of that one IP address, by causing the other hosts to look
like, hence the term masquerade, the machine supporting the dialup
connection. There is a small caveat and that is that the masquerade
function nearly always works only in one direction, that is the
masqueraded hosts can make calls out, but they cannot accept or
receive network connections from remote hosts. This means that some
network services do not work such as _t_a_l_k and others such as _f_t_p must
be configured to operate in passive (PASV) mode to operate.
Fortunately the most common network services such as _t_e_l_n_e_t, World
Wide Web and _i_r_c do work just fine.
KKeerrnneell CCoommppiillee OOppttiioonnss:
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)
Normally you have your linux machine supporting a slip or PPP dialup
line just as it would if it were a standalone machine. Additionally it
would have another network device configured, perhaps an ethernet,
configured with one of the reserved network addresses. The hosts to be
masqueraded would be on this second network. Each of these hosts would
have the IP address of the ethernet port of the linux machine set as
their default gateway or router.
A typical configuration might look something like this:
- -
\ | 192.168.1.0
\ | /255.255.255.0
\ --------- |
| | Linux | .1.1 |
NET =================| masq |------|
| PPP/slip | router| | --------
/ --------- |--| host |
/ | | |
/ | --------
- -
77..99..11.. MMaassqquueerraaddiinngg wwiitthh IIPPFFWWAADDMM
The most relevant commands for this configuration are:
# 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
77..99..22.. MMaassqquueerraaddiinngg wwiitthh IIPPCCHHAAIINNSS
This is similar to using IPFWADM but the command structure has
changed:
# 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
You can get more information on the Linux IP Masquerade feature from
the IP Masquerade Resource Page. Also, a _v_e_r_y detailed document about
masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs
to configure other OS's to run with a Linux masquerade server).
77..1100.. IIPP TTrraannssppaarreenntt PPrrooxxyy
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.
KKeerrnneell CCoommppiillee OOppttiioonnss:
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)
Configuration of the transparent proxy feature is performed using the
_i_p_f_w_a_d_m command
An example that might be useful is as follows:
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
This example will cause any connection attempts to port telnet (23) on
any host to be redirected to port 2323 on this host. If you run a
service on that port, you could forward telnet connections, log them
or do whatever fits your need.
A more interesting example is redirecting all http traffic through a
local cache. However, the protocol used by proxy servers is different
from native http: where a client connects to www.server.com:80 and
asks for /path/page, when it connects to the local cache it contacts
proxy.local.domain:8080 and asks for www.server.com/path/page.
To filter an http request through the local proxy, you need to adapt
the protocol by inserting a small server, called transproxy (you can
find it on the world wide web). You can choose to run transproxy on
port 8081, and issue this command:
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
The transproxy program, then, will receive all connections meant to
reach external servers and will pass them to the local proxy after
fixing protocol differences.
77..1111.. IIPPvv66
Just when you thought you were beginning to understand IP networking
the rules get changed! IPv6 is the shorthand notation for version 6 of
the Internet Protocol. IPv6 was developed primarily to overcome the
concerns in the Internet community that there would soon be a shortage
of IP addresses to allocate. IPv6 addresses are 16 bytes long (128
bits). IPv6 incorporates a number of other changes, mostly
simplifications, that will make IPv6 networks more managable than IPv4
networks.
Linux already has a working, but not complete, IPv6 implementation in
the 2.2.* series kernels.
If you wish to experiment with this next generation Internet
technology, or have a requirement for it, then you should read the
IPv6-FAQ which is available from www.terra.net.
77..1122.. MMoobbiillee IIPP
The term "IP mobility" describes the ability of a host that is able to
move its network connection from one point on the Internet to another
without changing its IP address or losing connectivity. Usually when
an IP host changes its point of connectivity it must also change its
IP address. IP Mobility overcomes this problem by allocating a fixed
IP address to the mobile host and using IP encapsulation (tunneling)
with automatic routing to ensure that datagrams destined for it are
routed to the actual IP address it is currently using.
A project is underway to provide a complete set of IP mobility tools
for Linux. The Status of the project and tools may be obtained from
the: Linux Mobile IP Home Page.
77..1133.. MMuullttiiccaasstt
IP Multicast allows an arbitrary number of IP hosts on disparate IP
networks to have IP datagrams simultaneously routed to them. This
mechanism is exploited to provide Internet wide "broadcast" material
such as audio and video transmissions and other novel applications.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] TCP/IP networking
....
[*] IP: multicasting
A suite of tools and some minor network configuration is required.
Please check the Multicast-HOWTO for more information on Multicast
support in Linux.
77..1144.. TTrraaffffiicc SShhaappeerr -- CChhaannggiinngg aalllloowweedd bbaannddwwiiddtthh
The traffic shaper is a driver that creates new interface devices,
those devices are traffic-limited in a user-defined way, they rely on
physical network devices for actual transmission and can be used as
outgoing routed for network traffic.
The shaper was introduced in Linux-2.1.15 and was backported to
Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan
Cox, the author of the shaper device and maintainer of Linux-2.0).
The traffic shaper can only be compiled as a module and is configured
by the _s_h_a_p_e_c_f_g program with commands like the following:
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
The shaper device can only control the bandwidth of outgoing traffic,
as packets are transmitted via the shaper only according to the
routing tables; therefore, a ``route by source address'' functionality
could help in limiting the overall bandwidth of specific hosts using a
Linux router.
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 ftp.invlogic.com.
Refer to Documentationnetworking/shaper.txt for further information
about the shaper.
If you want to try out a (tentative) shaping for incoming packets, try
out rshaper-1.01 (or newer), from ftp.systemy.it.
88.. AAddvvaanncceedd NNeettwwoorrkkiinngg wwiitthh KKeerrnneell 22..22
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.
I have put some time into it and have been able to do a little with
it. I will add more as I have time and help to figure out what it all
means.
In kernel 2.0 and below Linux used the standard _r_o_u_t_e command to place
routes in a single routing table. If you were to type _n_e_t_s_t_a_t _-_r_n at
the Linux prompt you could see and example.
In the newer kernels (2.1 and above) you have another option. This
option is rule based and 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 the source address, TOS, or incoming device.
88..11.. TThhee BBaassiiccss
LLiissttiinngg tthhee RRoouuttiinngg TTaabbllee::
ip route
Now on my machine this equates to the following output:
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
The first line:
220077..114499..4433..6622 ddeevv eetthh00 ssccooppee lliinnkk is the route for the interface
The second line:
220077..114499..4433..00//2244 ddeevv eetthh00 pprroottoo kkeerrnneell ssccooppee lliinnkk ssrrcc 220077..114499..4433..6622 Is
the route that says _e_v_e_r_y_t_h_i_n_g _t_h_a_t _g_o_e_s _t_o _2_0_7_._1_4_9_._4_3_._0 _n_e_e_d_s _t_o _g_o
_o_u_t _2_0_7_._1_4_9_._4_3_._6_2.
The third line:
ddeeffaauulltt vviiaa 220077..114499..4433..11 ddeevv eetthh00 is the default route.
88..11..11.. UUssiinngg tthhee iinnffoorrmmaattiioonn
Now that we have walked through a basic routing table. Lets see how we
use it. First read the Policy routing text. 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 do.
88..22.. AAddddiinngg aa rroouuttee wwiitthh tthhee nneeww iipp ttoooollss
In the previous section we spoke about listing the routing table and
what the basics of that listing meant. Well, luckily the output is
very similar to the syntax that you would use to implement that exact
routing table on your own.
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
As you can see the output and input are almost exact except for the
adding of the _i_p _r_o_u_t_e _a_d_d in front of the line.
NNoottee:: We are aware that the documentation on Routing with 2.2 is
sorely lacking. In fact, I think EVERYONE is aware of it. If you have
any experience in this please contact us at poet@linuxports.com we
would like to get information you have to help further document this.
88..33.. UUssiinngg NNAATT wwiitthh KKeerrnneell 22..22
The IP Network Address Translation facility is pretty much the
standardized big brother of the Linux IP Masquerade facility. It is
specified in some detail in RFC-1631 at your nearest RFC archive. NAT
provides features that IP-Masquerade does not that make it eminently
more suitable for use in corporate firewall router designs and larger
scale installations.
An alpha implementation of NAT for Linux 2.0.29 kernel has been
developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu-
chemnitz.de. Michaels documentation and implementation are available
from:
Linux IP Network Address Web Page
The much improved TCP/IP stack of Linux 2.2 kernel has NAT
functionality built-in. This facility seems to obsolete the work by
Michael Hasenstein (Michael.Hasenstein@informatik.tu-chemnitz.de).
To get it work you need kernel with enabled CONFIG_IP_ADVANCED_ROUTER,
CONFIG_IP_MULTIPLE_TABLES (aka policy routing) and CONFIG_IP_ROUTE_NAT
(aka fast NAT). Also, 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/.
Incoming datagrams NAT
Now, to translate addresses of incoming datagrams, following command
is used:
ip route add nat [/] via
This will make 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 further according
local routing table. You can translate either single host addresses,
or complete blocks. EExxaammpplleess::
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
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.
99.. UUssiinngg ccoommmmoonn PPCC hhaarrddwwaarree
99..11.. IISSDDNN
The Integrated Services Digital Network (ISDN) is a series of
standards that specify a general purpose switched digital data
network. An ISDN `call' creates a synchronous point to point data
service to the destination. ISDN is generally delivered on a high
speed link that is broken down into a number of discrete channels.
There are two different types of channels, the `B Channels' which will
actually carry the user data and a single channel called the `D
channel' which is used to send control information to the ISDN
exchange to establish calls and other functions. In Australia for
example, ISDN may be delivered on a 2Mbps link that is broken into 30
discrete 64kbps B channels with one 64kbps D channel. Any number of
channels may be used at a time and in any combination. You could for
example establish 30 separate calls to 30 different destinations at
64kbps each, or you could establish 15 calls to 15 different
destinations at 128kbps each (two channels used per call), or just a
small number of calls and leave the rest idle. A channel may be used
for either incoming or outgoing calls. The original intention of ISDN
was to allow Telecommunications companies to provide a single data
service which could deliver either telephone (via digitised voice) or
data services to your home or business without requiring you to make
any special configuration changes.
There are a few different ways to connect your computer to an ISDN
service. One way is to use a device called a `Terminal Adaptor' which
plugs into the Network Terminating Unit that you telecommunications
carrier will have installed when you got your ISDN service and
presents a number of serial interfaces. One of those interfaces is
used to enter commands to establish calls and configuration and the
others are actually connected to the network devices that will use the
data circuits when they are established. Linux will work in this sort
of configuration without modification, you just treat the port on the
Terminal Adaptor like you would treat any other serial device.
Another way, which is the way the kernel ISDN support is designed for
allows you to install an ISDN card into your Linux machine and then
has your Linux software handle the protocols and make the calls
itself.
KKeerrnneell CCoommppiillee OOppttiioonnss:
ISDN subsystem --->
<*> ISDN support
[ ] Support synchronous PPP
[ ] Support audio via ISDN
< > ICN 2B and 4B support
< > PCBIT-D support
< > Teles/NICCY1016PC/Creatix support
The Linux implementation of ISDN supports a number of different types
of internal ISDN cards. These are those listed in the kernel
configuration options:
+o ICN 2B and 4B
+o Octal PCBIT-D
+o Teles ISDN-cards and compatibles
Some of these cards require software to be downloaded to them to make
them operational. There is a separate utility to do this with.
Full details on how to configure the Linux ISDN support is available
from the /usr/src/linux/Documentation/isdn/ directory and an FAQ
dedicated to _i_s_d_n_4_l_i_n_u_x is available at www.lrz-muenchen.de. (You can
click on the english flag to get an english version).
AA nnoottee aabboouutt PPPPPP. The PPP suite of protocols will operate over either
asynchronous or synchronous serial lines. The commonly distributed PPP
daemon for Linux `_p_p_p_d' supports only asynchronous mode. If you wish
to run the PPP protocols over your ISDN service you need a specially
modified version. Details of where to find it are available in the
documentation referred to above.
99..22.. PPLLIIPP ffoorr LLiinnuuxx--22..00
PLIP device names are `plip0', `plip1 and plip2.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
<*> PLIP (parallel port) support
_p_l_i_p (Parallel Line IP), is like SLIP, in that it is used for
providing a _p_o_i_n_t _t_o _p_o_i_n_t network connection between two machines,
except that it is designed to use the parallel printer ports on your
machine instead of the serial ports (a cabling diagram in included in
the cabling diagram section later in this document). Because it is
possible to transfer more than one bit at a time with a parallel port,
it is possible to attain higher speeds with the _p_l_i_p interface than
with a standard serial device. In addition, even the simplest of
parallel ports, printer ports, can be used in lieu of you having to
purchase comparatively expensive 16550AFN UART's for your serial
ports. PLIP uses a lot of CPU compared to a serial link and is most
certainly not a good option if you can obtain some cheap ethernet
cards, but it will work when nothing else is available and will work
quite well. You should expect a data transfer rate of about 20
kilobytes per second when a link is running well.
The PLIP device drivers competes with the parallel device driver for
the parallel port hardware. If you wish to use both drivers then you
should compile them both as modules to ensure that you are able to
select which port you want to use for PLIP and which ports you want
for the printer driver. Refer to the ``Mudules mini-HOWTO'' for more
information on kernel module configuration.
Please note that some laptops use chipsets that will not work with
PLIP because they do not allow some combinations of signals that PLIP
relies on, that printers don't use.
The Linux _p_l_i_p interface is compatible with the _C_r_y_n_w_y_r _P_a_c_k_e_t _D_r_i_v_e_r
_P_L_I_P and this will mean that you can connect your Linux machine to a
DOS machine running any other sort of tcp/ip software via _p_l_i_p.
In the 2.0.* series kernel the plip devices are mapped to i/o port and
IRQ as follows:
device i/o IRQ
------ ----- ---
plip0 0x3bc 5
plip1 0x378 7
plip2 0x278 2
If your parallel ports don't match any of the above combinations then
you can change the IRQ of a port using the _i_f_c_o_n_f_i_g command using the
`irq' parameter (be sure to enable IRQ's on your printer ports in your
ROM BIOS if it supports this option). As an alternative, you can
specify ``io='' annd ``irq='' options on the _i_n_s_m_o_d command line, if
you use modules. For example:
root# insmod plip.o io=0x288 irq=5
PLIP operation is controlled by two timeouts, whose default values are
probably ok in most cases. You will probably need to increase them if
you have an especially slow computer, in which case the timers to
increase are actually on the ootthheerr computer. A program called
_p_l_i_p_c_o_n_f_i_g exists that allows you to change these timer settings
without recompiling your kernel. It is supplied with many Linux
distributions.
To configure a _p_l_i_p interface, you will need to invoke the following
commands (or aadddd them to your initialization scripts):
root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
root# /sbin/route add remoteplip plip1
Here, the port being used is the one at I/O address 0x378; _l_o_c_a_l_p_l_i_p
amd _r_e_m_o_t_e_p_l_i_p are the names or IP addresses used over the PLIP cable.
I personally keep them in my /etc/hosts database:
# plip entries
192.168.3.1 localplip
192.168.3.2 remoteplip
The _p_o_i_n_t_o_p_o_i_n_t parameter has the same meaning as for SLIP, in that it
specifies the address of the machine at the other end of the link.
In almost all respects you can treat a _p_l_i_p interface as though it
were a _S_L_I_P interface, except that neither _d_i_p nor _s_l_a_t_t_a_c_h need be,
nor can be, used.
Further information on PLIP may be obtained from the ``PLIP mini-
HOWTO''.
99..22..11.. PPLLIIPP ffoorr LLiinnuuxx--22..22
During development of the 2.1 kernel versions, support for the
parallel port was changed to a better setup.
KKeerrnneell CCoommppiillee OOppttiioonnss:
General setup --->
[*] Parallel port support
Network device support --->
<*> PLIP (parallel port) support
The new code for PLIP behaves like the old one (use the same _i_f_c_o_n_f_i_g
and _r_o_u_t_e commands as in the previous section, but initialization of
the device is different due to the advanced parallel port support.
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 /proc/parport. For example, if you have
only one parallel port, you'll only have a directory called
/proc/parport/0.
If your kernel didn't detect the IRQ number used by your port,
``insmod plip'' will fail; in this case just write the right number to
/proc/parport/0/irq and reinvoke _i_n_s_m_o_d.
Complete information about parallel port management is available in
the file Documentation/parport.txt, part of your kernel sources.
99..33.. PPPPPP
Many people have problems with Linux and PPP, with the increasing
amount of technologies being used to authenticate it is becoming more
difficult to manage PPP links. Although the following information is
detailed it may be overdone if you are just looking to set up a basic
dialup link. The majority of ISP's out there use PAP (Plain Text
Authentication Protocol). Since this is the case I _S_T_R_O_N_G_L_Y suggest
that you look at the following programs to help manage your links.
Linuxconf COAS
Both of these programs provide menu based configuration for PPP. I
again _s_u_g_g_e_s_t that you use the programs listed above. It will make
your life much easier. LinuxConf works with most distributions and it
is distributed with RedHat. COAS comes with Caldera and SUSE has a
program called YAST. I have no experience with YAST, if someone sends
me a (blatant hint)machine I will load SUSE and document YAST.
PPP devices names are `ppp0', `ppp1, etc. Devices are numbered
sequentially with the first device configured receiving `0'.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
<*> PPP (point-to-point) support
PPP configuration is covered in detail in the PPP-HOWTO. The PPP Howto
is severly outdated and I will try to get more information for the
manual PPP configuration as soon as I can.
99..33..11.. MMaaiinnttaaiinniinngg aa ppeerrmmaanneenntt ccoonnnneeccttiioonn ttoo tthhee nneett wwiitthh ppppppdd ..
If you are fortunate enough to have a semi permanent connection to the
net and would like to have your machine automatically redial your PPP
connection if it is lost then here is a simple trick to do so.
Configure PPP such that it can be started by the root user by issuing
the command:
# pppd
BBee ssuurree that you have the `-detach' option configured in your
/etc/ppp/options file. Then, insert the following line into your
/etc/inittab file, down with the _g_e_t_t_y definitions:
pd:23:respawn:/usr/sbin/pppd
This will cause the _i_n_i_t program to spawn and monitor the _p_p_p_d program
and automatically restart it if it dies.
99..44.. SSLLIIPP cclliieenntt -- ((AAnnttiiqquuaatteedd))
SLIP devices are named `sl0', `sl1' etc. with the first device
configured being assigned `0' and the rest incrementing sequentially
as they are configured.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
<*> SLIP (serial line) support
[ ] CSLIP compressed headers
[ ] Keepalive and linefill
[ ] Six bit SLIP encapsulation
SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a
serial line, be that a phone line with a dialup modem, or a leased
line of some sort. Of course to use SLIP you need access to a _S_L_I_P_-
_s_e_r_v_e_r in your area. Many universities and businesses provide SLIP
access all over the world.
Slip uses the serial ports on your machine to carry IP datagrams. To
do this it must take control of the serial device. Slip device names
are named _s_l_0, _s_l_1 etc. How do these correspond to your serial devices
? The networking code uses what is called an _i_o_c_t_l (i/o control) call
to change the serial devices into SLIP devices. There are two programs
supplied that can do this, they are called _d_i_p and _s_l_a_t_t_a_c_h
99..44..11.. ddiipp
_d_i_p (Dialup IP) is a smart program that is able to set the speed of
the serial device, command your modem to dial the remote end of the
link, automatically log you into the remote server, search for
messages sent to you by the server and extract information for them
such as your IP address and perform the _i_o_c_t_l necessary to switch your
serial port into SLIP mode. _d_i_p has a powerful scripting ability and
it is this that you can exploit to automate your logon procedure.
You can find it at: metalab.unc.edu.
To install it, try the following:
user% tar xvzf dip337o-uri.tgz
user% cd dip-3.3.7o
user% vi Makefile
root# make install
The Makefile assumes the existence of a group called _u_u_c_p, but you
might like to change this to either _d_i_p or _S_L_I_P depending on your
configuration.
99..44..22.. ssllaattttaacchh
_s_l_a_t_t_a_c_h as contrasted with _d_i_p is a very simple program, that is very
easy to use, but does not have the sophistication of _d_i_p. It does not
have the scripting ability, all it does is configure your serial
device as a SLIP device. It assumes you have all the information you
need and the serial line is established before you invoke it. _s_l_a_t_t_a_c_h
is ideal to use where you have a permanent connection to your server,
such as a physical cable, or a leased line.
99..44..33.. WWhheenn ddoo II uussee wwhhiicchh ??
You would use _d_i_p when your link to the machine that is your SLIP
server is a dialup modem, or some other temporary link. You would use
_s_l_a_t_t_a_c_h when you have a leased line, perhaps a cable, between your
machine and the server and there is no special action needed to get
the link working. See section `Permanent Slip connection' for more
information.
Configuring SLIP is much like configuring an Ethernet interface (read
section `Configuring an ethernet device' above). However there are a
few key differences.
First of all, SLIP links are unlike ethernet networks in that there is
only ever two hosts on the network, one at each end of the link.
Unlike an ethernet that is available for use as soon are you are
cabled, with SLIP, depending on the type of link you have, you may
have to initialize your network connection in some special way.
If you are using _d_i_p then this would not normally be done at boot
time, but at some time later, when you were ready to use the link. It
is possible to automate this procedure. If you are using _s_l_a_t_t_a_c_h then
you will probably want to add a section to your _r_c_._i_n_e_t_1 file. This
will be described soon.
There are two major types of SLIP servers: Dynamic IP address servers
and static IP address servers. Almost every SLIP server will prompt
you to login using a username and password when dialing in. _d_i_p can
handle logging you in automatically.
99..44..44.. SSttaattiicc SSLLIIPP sseerrvveerr wwiitthh aa ddiiaalluupp lliinnee aanndd DDIIPP..
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 /etc/hosts. You should also
configure some other files such as: rc.inet2, host.conf, resolv.conf,
/etc/HOSTNAME and rc.local. Remember that when configuring rc.inet1,
you don't need to add any special commands for your SLIP connection
since it is _d_i_p that does all of the hard work for you in configuring
your interface. You will need to give _d_i_p the appropriate information
and it will configure the interface for you after commanding the modem
to establish the call and logging you into your SLIP server.
If this is how your SLIP server works then you can move to section
`Using Dip' to learn how to configure _d_i_p appropriately.
99..44..55.. DDyynnaammiicc SSLLIIPP sseerrvveerr wwiitthh aa ddiiaalluupp lliinnee aanndd DDIIPP..
A _d_y_n_a_m_i_c SLIP server is one which allocates you an IP address
randomly, from a pool of addresses, each time you logon. This means
that there is no guarantee that you will have any particular address
each time, and that address may well be used by someone else after you
have logged off. The network administrator who configured the SLIP
server will have assigned a pool of address for the SLIP server to
use, when the server receives a new incoming call, it finds the first
unused address, guides the caller through the login process and then
prints a welcome message that contains the IP address it has allocated
and will proceed to use that IP address for the duration of that call.
Configuring for this type of server is similar to configuring for a
static server, except that you must add a step where you obtain the IP
address that the server has allocated for you and configure your SLIP
device with that.
Again, _d_i_p does the hard work and new versions are smart enough to not
only log you in, but to also be able to automatically read the IP
address printed in the welcome message and store it so that you can
have it configure your SLIP device with it.
If this is how your SLIP server works then you can move to section
`Using Dip' to learn how to configure _d_i_p appropriately.
99..44..66.. UUssiinngg DDIIPP..
As explained earlier, _d_i_p is a powerful program that can simplify and
automate the process of dialing into the SLIP server, logging you in,
starting the connection and configuring your SLIP devices with the
appropriate _i_f_c_o_n_f_i_g and _r_o_u_t_e commands.
Essentially to use _d_i_p you'll write a `dip script', which is basically
a list of commands that _d_i_p understands that tell _d_i_p how to perform
each of the actions you want it to perform. See sample.dip that comes
supplied with _d_i_p to get an idea of how it works. _d_i_p is quite a
powerful program, with many options. Instead of going into all of
them here you should look at the _m_a_n page, README and sample files
that will have come with your version of _d_i_p.
You may notice that the sample.dip script assumes that you're using a
static SLIP server, so you know what your IP address is beforehand.
For dynamic SLIP servers, the newer versions of _d_i_p 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 sample.dip that came
supplied with _d_i_p_3_3_7_j_-_u_r_i_._t_g_z and is probably a good starting point
for you. You might like to save it as /etc/dipscript and edit it to
suit your configuration:
#
# 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,
#
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
The above example assumes you are calling a _d_y_n_a_m_i_c SLIP server, if
you are calling a _s_t_a_t_i_c SLIP server, then the sample.dip file that
comes with _d_i_p_3_3_7_j_-_u_r_i_._t_g_z should work for you.
When _d_i_p is given the _g_e_t _$_l_o_c_a_l 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 _d_y_n_a_m_i_c SLIP servers, so that the process of
reading the IP address granted by the server could be automated.
The example above will automatically create a default route via your
SLIP link, if this is not what you want, you might have an ethernet
connection that should be your default route, then remove the _d_e_f_a_u_l_t
command from the script. After this script has finished running, if
you do an _i_f_c_o_n_f_i_g command, you will see that you have a device _s_l_0.
This is your SLIP device. Should you need to, you can modify its
configuration manually, after the _d_i_p command has finished, using the
_i_f_c_o_n_f_i_g and _r_o_u_t_e commands.
Please note that _d_i_p allows you to select a number of different
protocols to use with the mode command, the most common example is
_c_S_L_I_P for SLIP with compression. Please note that both ends of the
link must agree, so you should ensure that whatever you select agrees
with what your server is set to.
The above example is fairly robust and should cope with most errors.
Please refer to the _d_i_p man page for more information. Naturally you
could, for example, code the script to do such things as redial the
server if it doesn't get a connection within a prescribed period of
time, or even try a series of servers if you have access to more than
one.
99..44..77.. PPeerrmmaanneenntt SSLLIIPP ccoonnnneeccttiioonn uussiinngg aa lleeaasseedd lliinnee aanndd ssllaattttaacchh..
If you have a cable between two machines, or are fortunate enough to
have a leased line, or some other permanent serial connection between
your machine and another, then you don't need to go to all the trouble
of using _d_i_p to set up your serial link. _s_l_a_t_t_a_c_h is a very simple to
use utility that will allow you just enough functionality to configure
your connection.
Since your connection will be a permanent one, you will want to add
some commands to your rc.inet1 file. In essence all you need to do for
a permanent connection is ensure that you configure the serial device
to the correct speed and switch the serial device into SLIP mode.
_s_l_a_t_t_a_c_h allows you to do this with one command. AAdddd the following to
your rc.inet1 file:
#
# 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.
Where:
IIPPAA..IIPPAA..IIPPAA..IIPPAA
represents your IP address.
IIPPRR..IIPPRR..IIPPRR..IIPPRR
represents the IP address of the remote end.
_s_l_a_t_t_a_c_h allocates the first unallocated SLIP device to the serial
device specified. _s_l_a_t_t_a_c_h starts with _s_l_0. Therefore the first
_s_l_a_t_t_a_c_h command attaches SLIP device _s_l_0 to the serial device
specified and _s_l_1 the next time, etc.
_s_l_a_t_t_a_c_h allows you to configure a number of different protocols with
the -p argument. In your case you will use either _S_L_I_P or _c_S_L_I_P
depending on whether you want to use compression or not. Note: both
ends must agree on whether you want compression or not.
99..44..88.. SSLLIIPP sseerrvveerr..
If you have a machine that is perhaps network connected, that you'd
like other people be able to dial into and provide network services,
then you will need to configure your machine as a server. If you want
to use SLIP as the serial line protocol, then currently you have three
options as to how to configure your Linux machine as a SLIP server. My
preference would be to use the first presented, _s_l_i_p_l_o_g_i_n, as it seems
the easiest to configure and understand, but I will present a summary
of each, so you can make your own decision.
99..44..99.. SSlliipp SSeerrvveerr uussiinngg sslliippllooggiinn ..
_s_l_i_p_l_o_g_i_n is a program that you can use in place of the normal login
shell for SLIP users that converts the terminal line into a SLIP line.
It allows you to configure your Linux machine as either a _s_t_a_t_i_c
_a_d_d_r_e_s_s _s_e_r_v_e_r, users get the same address everytime they call in, or
a _d_y_n_a_m_i_c _a_d_d_r_e_s_s _s_e_r_v_e_r, where users get an address allocated for
them which will not necessarily be the same as the last time they
called.
The caller will login as per the standard login process, entering
their username and password, but instead of being presented with a
shell after their login, _s_l_i_p_l_o_g_i_n is executed which searches its
configuration file (/etc/slip.hosts) for an entry with a login name
that matches that of the caller. If it locates one, it configures the
line as an 8bit clean line, and uses an _i_o_c_t_l call to convert the line
discipline to SLIP. When this process is complete, the last stage of
configuration takes place, where _s_l_i_p_l_o_g_i_n invokes a shell script
which configures the SLIP interface with the relevant ip address,
netmask and sets appropriate routing in place. This script is usually
called /etc/slip.login, but in a similar manner to _g_e_t_t_y, if you have
certain callers that require special initialization, then you can
create configuration scripts called /etc/slip.login.loginname that
will be run instead of the default specifically for them.
There are either three or four files that you need to configure to get
_s_l_i_p_l_o_g_i_n working for you. I will detail how and where to get the
software and how each is configured in detail. The files are:
+o /etc/passwd, for the dialin user accounts.
+o /etc/slip.hosts, to contain the information unique to each dial-in
user.
+o /etc/slip.login, which manages the configuration of the routing
that needs to be performed for the user.
+o /etc/slip.tty, which is required only if you are configuring your
server for _d_y_n_a_m_i_c _a_d_d_r_e_s_s _a_l_l_o_c_a_t_i_o_n and contains a table of
addresses to allocate
+o /etc/slip.logout, which contains commands to clean up after the
user has hung up or logged out.
99..44..1100.. WWhheerree ttoo ggeett sslliippllooggiinn
You may already have the _s_l_i_p_l_o_g_i_n package installed as part of your
distribution, if not then _s_l_i_p_l_o_g_i_n can be obtained from:
metalab.unc.edu. The tar file contains both source, precompiled
binaries and a _m_a_n page.
To ensure that only authorized users will be able to run _s_l_i_p_l_o_g_i_n
program, you should add an entry to your /etc/group file similar to
the following:
..
slip::13:radio,fred
..
When you install the _s_l_i_p_l_o_g_i_n package, the _M_a_k_e_f_i_l_e will change the
group ownership of the _s_l_i_p_l_o_g_i_n program to slip, and this will mean
that only users who belong to that group will be able to execute it.
The example above will allow only users radio and fred to execute
_s_l_i_p_l_o_g_i_n.
To install the binaries into your /sbin directory and the _m_a_n page
into section 8, do the following:
# 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
If you want to recompile the binaries before installation, add a make
clean before the make install. If you want to install the binaries
somewhere else, you will need to edit the Makefile _i_n_s_t_a_l_l _r_u_l_e_.
99..44..1111.. CCoonnffiigguurriinngg //eettcc//ppaasssswwdd ffoorr SSlliipp hhoossttss..
Normally you would create some special logins for Slip callers in your
/etc/passwd file. A convention commonly followed is to use the
_h_o_s_t_n_a_m_e of the calling host with a capital `S' prefixing it. So, for
example, if the calling host is called radio then you could create a
/etc/passwd entry that looked like:
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
It doesn't really matter what the account is called, so long as it is
meaningful to you.
Note: the caller doesn't need any special home directory, as they will
not be presented with a shell from this machine, so /tmp is a good
choice. Also note that _s_l_i_p_l_o_g_i_n is used in place of the normal login
shell.
99..44..1122.. CCoonnffiigguurriinngg //eettcc//sslliipp..hhoossttss
The /etc/slip.hosts file is the file that _s_l_i_p_l_o_g_i_n searches for
entries matching the login name to obtain configuration details for
this caller. It is this file where you specify the ip address and
netmask that will be assigned to the caller and configured for their
use. Sample entries for two hosts, one a static configuration for host
radio and another, a dynamic configuration for user host albert might
look like:
#
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
#
The /etc/slip.hosts file entries are:
1. the login name of the caller.
2. ip address of the server machine, ie this machine.
3. ip address that the caller will be assigned. If this field is coded
DYNAMIC then an ip address will be allocated based on the
information contained in your /etc/slip.tty file discussed later.
NNoottee:: you must be using at least version 1.3 of sliplogin for this
to work.
4. the netmask assigned to the calling machine in dotted decimal
notation eg 255.255.255.0 for a Class C network mask.
5. the slip mode setting which allows you to enable/disable
compression and slip other features. Allowable values here are
"normal" or "compressed".
6. 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.
7. optional arguments.
Note: You can use either hostnames or IP addresses in dotted decimal
notation for fields 2 and 3. If you use hostnames then those hosts
must be resolvable, that is, your machine must be able to locate an ip
address for those hostnames, otherwise the script will fail when it is
called. You can test this by trying trying to telnet to the hostname,
if you get the `_T_r_y_i_n_g _n_n_n_._n_n_n_._n_n_n_._._.' message then your machine has
been able to find an ip address for that name. If you get the message
`_U_n_k_n_o_w_n _h_o_s_t', then it has not. If not, either use ip addresses in
dotted decimal notation, or fix up your name resolver configuration
(See section Name Resolution).
The most common slip modes are:
nnoorrmmaall
to enable normal uncompressed SLIP.
ccoommpprreesssseedd
to enable van Jacobsen header compression (cSLIP)
Naturally these are mutually exclusive, you can use one or the other.
For more information on the other options available, refer to the _m_a_n
pages.
99..44..1133.. CCoonnffiigguurriinngg tthhee //eettcc//sslliipp..llooggiinn ffiillee..
After _s_l_i_p_l_o_g_i_n has searched the /etc/slip.hosts and found a matching
entry, it will attempt to execute the /etc/slip.login file to actually
configure the SLIP interface with its ip address and netmask.
The sample /etc/slip.login file supplied with the _s_l_i_p_l_o_g_i_n package
looks like this:
#!/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 pub
exit 0
#
You will note that this script simply uses the _i_f_c_o_n_f_i_g and _r_o_u_t_e com-
mands to configure the SLIP device with its ipaddress, remote ip
address and netmask and creates a route for the remote address via the
SLIP device. Just the same as you would if you were using the _s_l_a_t_t_a_c_h
command.
Note also the use of _P_r_o_x_y _A_R_P to ensure that other hosts on the same
ethernet as the server machine will know how to reach the dial-in
host. The field should be the hardware address of the
ethernet card in the machine. If your server machine isn't on an
ethernet network then you can leave this line out completely.
99..44..1144.. CCoonnffiigguurriinngg tthhee //eettcc//sslliipp..llooggoouutt ffiillee..
When the call drops out, you want to ensure that the serial device is
restored to its normal state so that future callers will be able to
login correctly. This is achieved with the use of the
/etc/slip.logout file. It is quite simple in format and is called with
the same argument as the /etc/slip.login file.
#!/bin/sh -
#
# slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#
All it does is `down' the interface which will delete the manual route
previously created. It also uses the _a_r_p command to delete any proxy
arp put in place, again, you don't need the _a_r_p command in the script
if your server machine does not have an ethernet port.
99..44..1155.. CCoonnffiigguurriinngg tthhee //eettcc//sslliipp..ttttyy ffiillee..
If you are using dynamic ip address allocation (have any hosts
configured with the DYNAMIC keyword in the /etc/slip.hosts file, then
you must configure the /etc/slip.tty 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.
The file is a table that lists the _t_t_y devices that will support dial-
in SLIP connections and the ip address that should be assigned to
users who call in on that port.
Its format is as follows:
# 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
#
What this table says is that callers that dial in on port /dev/ttyS0
who have their remote address field in the /etc/slip.hosts file set to
DYNAMIC will be assigned an address of 192.168.0.100.
In this way you need only allocate one address per port for all users
who do not require an dedicated address for themselves. This helps you
keep the number of addresses you need down to a minimum to avoid
wastage.
99..44..1166.. SSlliipp SSeerrvveerr uussiinngg ddiipp ..
Let me start by saying that some of the information below came from
the _d_i_p 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 _d_i_p_3_3_7_o_-_u_r_i_._t_g_z package and probably will not apply to other
versions of _d_i_p.
_d_i_p has an input mode of operation, where it automatically locates an
entry for the user who invoked it and configures the serial line as a
SLIP link according to information it finds in the /etc/diphosts file.
This input mode of operation is activated by invoking _d_i_p as _d_i_p_l_o_g_i_n.
This therefore is how you use _d_i_p as a SLIP server, by creating
special accounts where _d_i_p_l_o_g_i_n is used as the login shell.
The first thing you will need to do is to make a symbolic link as
follows:
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
You then need to add entries to both your /etc/passwd and your
/etc/diphosts files. The entries you need to make are formatted as
follows:
To configure Linux as a SLIP server with _d_i_p, you need to create some
special SLIP accounts for users, where _d_i_p (in input mode) is used as
the login shell. A suggested convention is that of having all SLIP
accounts begin with a capital `S', eg `Sfredm'.
A sample /etc/passwd entry for a SLIP user looks like:
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
After the user logs in, the _l_o_g_i_n program, if it finds and verifies
the user ok, will execute the _d_i_p_l_o_g_i_n command. _d_i_p, when invoked as
_d_i_p_l_o_g_i_n knows that it should automatically assume that it is being
used a login shell. When it is started as _d_i_p_l_o_g_i_n the first thing it
does is use the _g_e_t_u_i_d_(_) function call to get the userid of whoever
has invoked it. It then searches the /etc/diphosts file for the first
entry that matches either the userid or the name of the _t_t_y device
that the call has come in on and configures itself appropriately. By
judicious decision as to whether to give a user an entry in the
diphosts file, or whether to let the user be given the default
configuration you can build your server in such a way that you can
have a mix of static and dynamically assigned address users.
_d_i_p will automatically add a `Proxy-ARP' entry if invoked in input
mode, so you do not need to worry about manually adding such entries.
99..44..1177.. CCoonnffiigguurriinngg //eettcc//ddiipphhoossttss
/etc/diphosts is used by _d_i_p to lookup preset configurations for
remote hosts. These remote hosts might be users dialing into your
linux machine, or they might be for machines that you dial into with
your linux machine.
The general format for /etc/diphosts is as follows:
..
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
..
The fields are:
1. login name: as returned by getpwuid(getuid()) or tty name.
2. unused: compat. with passwd
3. Remote Address: IP address of the calling host, either numeric or
by name
4. Local Address: IP address of this machine, again numeric or by name
5. Netmask: in dotted decimal notation
6. Comment field: put whatever you want here.
7. protocol: Slip, CSlip etc.
8. MTU: decimal number
An example /etc/net/diphosts entry for a remote SLIP user might be:
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
which specifies a SLIP link with remote address of 145.71.34.1 and MTU
of 296, or:
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
which specifies a cSLIP-capable link with remote address 145.71.34.1
and MTU of 1006.
Therefore, all users who you wish to be allowed a statically allocated
dial-up IP access should have an entry in the /etc/diphosts. If you
want users who call a particular port to have their details
dynamically allocated then you must have an entry for the tty device
and do not configure a user based entry. You should remember to
configure at least one entry for each tty device that your dialup
users use to ensure that a suitable configuration is available for
them regardless of which modem they call in on.
When a user logs in they will receive a normal login and password
prompt at which they should enter their SLIP-login userid and
password. If these verify ok then the user will see no special
messages and they should just change into SLIP mode at their end. The
user should then be able to connect ok and be configured with the
relevant parameters from the diphosts file.
99..44..1188.. SSLLIIPP sseerrvveerr uussiinngg tthhee ddSSLLIIPP ppaacckkaaggee..
Matt Dillon 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 _t_c_s_h installed as at least one of the
scripts requires it. Matt supplies a binary copy of the _e_x_p_e_c_t utility
as it too is needed by one of the scripts. You will most likely need
some experience with _e_x_p_e_c_t to get this package working to your
liking, but don't let that put you off.
Matt has written a good set of installation instructions in the README
file, so I won't bother repeating them.
You can get the _d_S_L_I_P package from its home site at:
aappoolllloo..wweesstt..ooiicc..ccoomm
/pub/linux/dillon_src/dSLIP203.tgz
or from:
mmeettaallaabb..uunncc..eedduu
/pub/Linux/system/Network/serial/dSLIP203.tgz
Read the README file and create the /etc/passwd and /etc/group entries
bbeeffoorree doing a make install.
1100.. OOtthheerr NNeettwwoorrkk TTeecchhnnoollooggiieess
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.
1100..11.. AARRCCNNeett
ARCNet device names are `arc0e', `arc1e', `arc2e' etc. or `arc0s',
`arc1s', `arc2s' etc. The first card detected by the kernel is
assigned `arc0e' or `arc0s' and the rest are assigned sequentially in
the order they are detected. The letter at the end signifies whether
you've selected ethernet encapsulation packet format or RFC1051 packet
format.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
<*> ARCnet support
[ ] Enable arc0e (ARCnet "Ether-Encap" packet format)
[ ] Enable arc0s (ARCnet RFC1051 packet format)
Once you have your kernel properly built to support your ethernet card
then configuration of the card is easy.
Typically you would use something like:
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
Please refer to the /usr/src/linux/Documentation/networking/arcnet.txt
and /usr/src/linux/Documentation/networking/arcnet-hardware.txt files
for further information.
ARCNet support was developed by Avery Pennarun, apenwarr@foxnet.net.
1100..22.. AApppplleettaallkk (( AAFF__AAPPPPLLEETTAALLKK ))
The Appletalk support has no special device names as it uses existing
network devices.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
<*> Appletalk DDP
Appletalk support allows your Linux machine to interwork with Apple
networks. An important use for this is to share resources such as
printers and disks between both your Linux and Apple computers.
Additional software is required, this is called _n_e_t_a_t_a_l_k. Wesley Craig
netatalk@umich.edu represents a team called the `Research Systems Unix
Group' at the University of Michigan and they have produced the
_n_e_t_a_t_a_l_k package which provides software that implements the Appletalk
protocol stack and some useful utilities. The _n_e_t_a_t_a_l_k package will
either have been supplied with your Linux distribution, or you will
have to ftp it from its home site at the University of Michigan
To build and install the package do something like:
user% tar xvfz .../netatalk-1.4b2.tar.Z
user% make
root# make install
You may want to edit the `Makefile' before calling _m_a_k_e to actually
compile the software. Specifically, you might want to change the
DESTDIR variable which defines where the files will be installed
later. The default of /usr/local/atalk is fairly safe.
1100..22..11.. CCoonnffiigguurriinngg tthhee AApppplleettaallkk ssooffttwwaarree..
The first thing you need to do to make it all work is to ensure that
the appropriate entries in the /etc/services file are present. The
entries you need are:
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
The next step is to create the Appletalk configuration files in the
/usr/local/atalk/etc directory (or wherever you installed the
package).
The first file to create is the /usr/local/atalk/etc/atalkd.conf file.
Initially this file needs only one line that gives the name of the
network device that supports the network that your Apple machines are
on:
eth0
The Appletalk daemon program will add extra details after it is run.
1100..22..22.. EExxppoorrttiinngg aa LLiinnuuxx ffiilleessyysstteemmss vviiaa AApppplleettaallkk..
You can export filesystems from your linux machine to the network so
that Apple machine on the network can share them.
To do this you must configure the
/usr/local/atalk/etc/AppleVolumes.system file. There is another
configuration file called /usr/local/atalk/etc/AppleVolumes.default
which has exactly the same format and describes which filesystems
users connecting with guest privileges will receive.
Full details on how to configure these files and what the various
options are can be found in the _a_f_p_d man page.
A simple example might look like:
/tmp Scratch
/home/ftp/pub "Public Area"
Which would export your /tmp filesystem as AppleShare Volume `Scratch'
and your ftp public directory as AppleShare Volume `Public Area'. The
volume names are not mandatory, the daemon will choose some for you,
but it won't hurt to specify them anyway.
1100..22..33.. SShhaarriinngg yyoouurr LLiinnuuxx pprriinntteerr aaccrroossss AApppplleettaallkk..
You can share your linux printer with your Apple machines quite
simply. You need to run the _p_a_p_d program which is the Appletalk
Printer Access Protocol Daemon. When you run this program it will
accept requests from your Apple machines and spool the print job to
your local line printer daemon for printing.
You need to edit the /usr/local/atalk/etc/papd.conf file to configure
the daemon. The syntax of this file is the same as that of your usual
/etc/printcap file. The name you give to the definition is registered
with the Appletalk naming protocol, NBP.
A sample configuration might look like:
TricWriter:\
:pr=lp:op=cg:
Which would make a printer named `TricWriter' available to your
Appletalk network and all accepted jobs would be printed to the linux
printer `lp' (as defined in the /etc/printcap file) using _l_p_d. The
entry `op=cg' says that the linux user `cg' is the operator of the
printer.
1100..22..44.. SSttaarrttiinngg tthhee aapppplleettaallkk ssooffttwwaarree..
Ok, you should now be ready to test this basic configuration. There is
an _r_c_._a_t_a_l_k file supplied with the _n_e_t_a_t_a_l_k package that should work
ok for you, so all you should have to do is:
root# /usr/local/atalk/etc/rc.atalk
and all should startup and run ok. You should see no error messages
and the software will send messages to the console indicating each
stage as it starts.
1100..22..55.. TTeessttiinngg tthhee aapppplleettaallkk ssooffttwwaarree..
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.
1100..22..66.. CCaavveeaattss ooff tthhee aapppplleettaallkk ssooffttwwaarree..
+o 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 /etc/rc.d/rc.inet1 file.
+o The _a_f_p_d (Apple Filing Protocol Daemon) severely messes up your
hard disk. Below the mount points it creates a couple of
directories called ``.AppleDesktop'' and Network Trash Folder.
Then, for each directory you access it will create a .AppleDouble
below it so it can store resource forks, etc. So think twice before
exporting /, you will have a great time cleaning up afterwards.
+o The _a_f_p_d program expects clear text passwords from the Macs.
Security could be a problem, so be very careful when you run this
daemon on a machine connected to the Internet, you have yourself to
blame if somebody nasty does something bad.
+o The existing diagnostic tools such as _n_e_t_s_t_a_t and _i_f_c_o_n_f_i_g don't
support Appletalk. The raw information is available in the
/proc/net/ directory if you need it.
1100..22..77.. MMoorree iinnffoorrmmaattiioonn
For a much more detailed description of how to configure Appletalk for
Linux refer to Anders Brownworth _L_i_n_u_x _N_e_t_a_t_a_l_k_-_H_O_W_T_O page at
thehamptons.com.
1100..33.. AATTMM
Werner Almesberger is managing a
project to provide Asynchronous Transfer Mode support for Linux.
Current information on the status of the project may be obtained from:
lrcwww.epfl.ch.
1100..44.. AAXX2255 (( AAFF__AAXX2255 ))
AX.25 device names are `sl0', `sl1', etc. in 2.0.* kernels or `ax0',
`ax1', etc. in 2.1.* kernels.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] Amateur Radio AX.25 Level 2
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO.
These protocols are used by Amateur Radio Operators world wide in
packet radio experimentation.
Most of the work for implementation of these protocols has been done
by Jonathon Naylor, jsn@cs.nott.ac.uk.
1100..55.. DDEECCNNeett
Support for DECNet is currently being worked on. You should expect it
to appear in a late 2.1.* kernel.
1100..66.. FFDDDDII
FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card
detected by the kernel is assigned `fddi0' and the rest are assigned
sequentially in the order they are detected.
Larry Stefani, lstefani@ultranet.com, has developed a driver for the
Digital Equipment Corporation FDDI EISA and PCI cards.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] FDDI driver support
[*] Digital DEFEA and DEFPA adapter support
When you have your kernel built to support the FDDI driver and
installed, configuration of the FDDI interface is almost identical to
that of an ethernet interface. You just specify the appropriate FDDI
interface name in the _i_f_c_o_n_f_i_g and _r_o_u_t_e commands.
1100..77.. FFrraammee RReellaayy
The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
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.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
<*> Frame relay DLCI support (EXPERIMENTAL)
(24) Max open DLCI
(8) Max DLCI per device
<*> SDLA (Sangoma S502/S508) support
Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
support and configuration tools.
Currently the only FRAD I know of that are supported are the
Sangoma Technologies S502A, S502E and S508. and the Emerging
Technologies. The Emerging Technologies website is here.
_I _w_o_u_l_d _l_i_k_e _t_o _s_t_a_t_e _s_o_m_e_t_h_i_n_g _h_e_r_e_. _I _h_a_v_e _p_e_r_s_o_n_a_l _e_x_p_e_r_i_e_n_c_e
_w_i_t_h _E_m_e_r_g_i_n_g _T_e_c_h_n_o_l_o_g_i_e_s _a_n_d _I _d_o _n_o_t _r_e_c_c_o_m_e_n_d _t_h_e_m_. _I _f_o_u_n_d
_t_h_e_m _t_o _b_e _v_e_r_y _u_n_p_r_o_f_e_s_s_i_o_n_a_l _a_n_d _e_x_t_r_e_m_e_l_y _r_u_d_e_. _I_f _a_n_y_o_n_e _e_l_s_e
_h_a_s _h_a_d _a _g_o_o_d _e_x_p_e_r_i_e_n_c_e _w_i_t_h _t_h_e_m _I _w_o_u_l_d _l_i_k_e _t_o _k_n_o_w_. _I _w_i_l_l
_s_a_y _t_h_i_s _f_o_r _t_h_e_m_, _t_h_e_i_r _p_r_o_d_u_c_t _i_s _f_l_e_x_i_b_l_e _a_n_d _a_p_p_e_a_r_s _t_o _b_e
_s_t_a_b_l_e_.
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 ftp.invlogic.com.
Compiling and installing the tools is straightforward, but the lack
of a top level Makefile makes it a fairly manual process:
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
Note that the previous commands use _s_h syntax, if you use a _c_s_h
flavour instead (like _t_c_s_h), the _f_o_r loop will look different.
After installing the tools you need to create an
/etc/frad/router.conf file. You can use this template, which is a
modified version of one of the example files:
# /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_]
#
[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
When you've built your /etc/frad/router.conf file the only step
remaining is to configure the actual devices themselves. This is
only a little trickier than a normal network device configuration,
you need to remember to bring up the FRAD device before the DLCI
encapsulation devices. These commands are best hosted in a shell
script, due to their number:
#!/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
#
1100..88.. IIPPXX (( AAFF__IIPPXX ))
The IPX protocol is most commonly utilized in Novell NetWare(tm) local
area network environments. Linux includes support for this protocol
and may be configured to act as a network endpoint, or as a router for
IPX.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] The IPX protocol
[ ] Full internal IPX network
The IPX protocol and the NCPFS are covered in greater depth in the
IPX-HOWTO.
1100..99.. NNeettRRoomm (( AAFF__NNEETTRROOMM ))
NetRom device names are `nr0', `nr1', etc.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] Amateur Radio AX.25 Level 2
[*] Amateur Radio NET/ROM
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO.
These protocols are used by Amateur Radio Operators world wide in
packet radio experimentation.
Most of the work for implementation of these protocols has been done
by Jonathon Naylor, jsn@cs.nott.ac.uk.
1100..1100.. RRoossee pprroottooccooll (( AAFF__RROOSSEE ))
Rose device names are `rs0', `rs1', etc. in 2.1.* kernels. Rose is
available in the 2.1.* kernels.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Networking options --->
[*] Amateur Radio AX.25 Level 2
<*> Amateur Radio X.25 PLP (Rose)
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO.
These protocols are used by Amateur Radio Operators world wide in
packet radio experimentation.
Most of the work for implementation of these protocols has been done
by Jonathon Naylor, jsn@cs.nott.ac.uk.
1100..1111.. SSAAMMBBAA -- ``NNeettBBEEUUII'',, ``NNeettBBiiooss'',, ``CCIIFFSS'' ssuuppppoorrtt..
SAMBA is an implementation of the Session Management Block protocol.
Samba allows Microsoft and other systems to mount and use your disks
and printers.
SAMBA and its configuration are covered in detail in the SMB-HOWTO.
1100..1122.. SSTTRRIIPP ssuuppppoorrtt ((SSttaarrmmooddee RRaaddiioo IIPP))
STRIP device names are `st0', `st1', etc.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
....
[*] Radio network interfaces
< > STRIP (Metricom starmode radio IP)
STRIP is a protocol designed specifically for a range of Metricom
radio modems for a research project being conducted by Stanford
University called the MosquitoNet Project. There is a lot of
interesting reading here, even if you aren't directly interested in
the project.
The Metricom radios connect to a serial port, employ spread spectrum
technology and are typically capable of about 100kbps. Information on
the Metricom radios is available from the: Metricom Web Server.
At present the standard network tools and utilities do not support the
STRIP driver, so you will have to download some customized tools from
the MosquitoNet web server. Details on what software you need is
available at the: MosquitoNet STRIP Page.
A summary of configuration is that you use a modified _s_l_a_t_t_a_c_h program
to set the line discipline of a serial tty device to STRIP and then
configure the resulting `st[0-9]' device as you would for ethernet
with one important exception, for technical reasons STRIP does not
support the ARP protocol, so you must manually configure the ARP
entries for each of the hosts on your subnet. This shouldn't prove too
onerous.
1100..1133.. TTookkeenn RRiinngg
Token ring device names are `tr0', `tr1' etc. Token Ring is an IBM
standard LAN protocol that avoids collisions by providing a mechanism
that allows only one station on the LAN the right to transmit at a
time. A `token' is held by one station at a time and the station
holding the token is the only station allowed to transmit. When it has
transmitted its data it passes the token onto the next station. The
token loops amongst all active stations, hence the name `Token Ring'.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
....
[*] Token Ring driver support
< > IBM Tropic chipset based adaptor support
Configuration of token ring is identical to that of ethernet with the
exception of the network device name to configure.
1100..1144.. XX..2255
X.25 is a circuit based packet switching protocol defined by the
C.C.I.T.T. (a standards body recognized by Telecommunications
companies in most parts of the world). An implementation of X.25 and
LAPB are being worked on and recent 2.1.* kernels include the work in
progress.
Jonathon Naylor jsn@cs.nott.ac.uk is leading the development and a
mailing list has been established to discuss Linux X.25 related
matters. To subscribe send a message to: majordomo@vger.rutgers.edu
with the text "subscribe linux-x25" in the body of the message.
Early versions of the configuration tools may be obtained from
Jonathon's ftp site at ftp.cs.nott.ac.uk.
1100..1155.. WWaavveeLLaann CCaarrdd
Wavelan device names are `eth0', `eth1', etc.
KKeerrnneell CCoommppiillee OOppttiioonnss:
Network device support --->
[*] Network device support
....
[*] Radio network interfaces
....
<*> WaveLAN support
The WaveLAN card is a spread spectrum wireless lan card. The card
looks very like an ethernet card in practice and is configured in much
the same way.
You can get information on the Wavelan card from Wavelan.com.
1111.. CCaabblleess aanndd CCaabblliinngg
Those of you handy with a soldering iron may want to build your own
cables to interconnect two linux machines. The following cabling
diagrams should assist you in this.
1111..11.. SSeerriiaall NNUULLLL MMooddeemm ccaabbllee
Not all NULL modem cables are alike. Many null modem cables do little
more than trick your computer into thinking all the appropriate
signals are present and swap transmit and receive data. This is ok but
means that you must use software flow control (XON/XOFF) which is less
efficient than hardware flow control. The following cable provides the
best possible signalling between machines and allows you to use
hardware (RTS/CTS) flow control.
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
1111..22.. PPaarraalllleell ppoorrtt ccaabbllee ((PPLLIIPP ccaabbllee))
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.
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
Notes:
+o Do not connect the pins marked with an asterisk `*'.
+o Extra grounds are 18,19,20,21,22,23 and 24.
+o If the cable you are using has a metallic shield, it should be
connected to the metallic DB-25 shell at oonnee eenndd oonnllyy.
WWaarrnniinngg:: AA mmiisswwiirreedd PPLLIIPP ccaabbllee ccaann ddeessttrrooyy yyoouurr ccoonnttrroolllleerr ccaarrdd.. Be
very careful and double check every connection to ensure you don't
cause yourself any unnecessary work or heartache.
While you may be able to run PLIP cables for long distances, you
should avoid it if you can. The specifications for the cable allow for
a cable length of about 1 metre or so. Please be very careful when
running long plip cables as sources of strong electromagnetic fields
such as lightning, power lines and radio transmitters can interfere
with and sometimes even damage your controller. If you really want to
connect two of your computers over a large distance you really should
be looking at obtaining a pair of thin-net ethernet cards and running
some coaxial cable.
1111..33.. 1100bbaassee22 ((tthhiinn ccooaaxx)) EEtthheerrnneett CCaabblliinngg
10base2 is an ethernet cabling standard that specifies the use of 50
ohm coaxial cable with a diameter of about 5 millimeters. There are a
couple of important rules to remember when interconnecting machines
with 10base2 cabling. The first is that you must use terminators at
bbootthh eennddss 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
at all. Normally you'd use `T pieces' to interconnect the machines, so
that you end up with something that looks like:
|==========T=============T=============T==========T==========|
| | | |
| | | |
----- ----- ----- -----
| | | | | | | |
----- ----- ----- -----
where the `|' at either end represents a terminator, the `======' rep-
resents a length of coaxial cable with BNC plugs at either end and the
`T' represents a `T piece' connector. You should keep the length of
cable between the `T piece' and the actual ethernet card in the PC as
short as possible, ideally the `T piece' will be plugged directly into
the ethernet card.
1111..44.. TTwwiisstteedd PPaaiirr EEtthheerrnneett CCaabbllee
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 Ethernet-HOWTO
1122.. GGlloossssaarryy ooff TTeerrmmss uusseedd iinn tthhiiss ddooccuummeenntt..
The following is a list of some of the most important terms used in
this document.
AARRPP
This is an acronym for the _A_d_d_r_e_s_s _R_e_s_o_l_u_t_i_o_n _P_r_o_t_o_c_o_l and this
is how a network machine associates an IP Address with a
hardware address.
AATTMM
This is an acronym for _A_s_y_n_c_h_r_o_n_o_u_s _T_r_a_n_s_f_e_r _M_o_d_e. 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.
cclliieenntt
This is usually the piece of software at the end of a system
where the user is. There are exceptions to this, for example, in
the X11 window system it is actually the server with the user
and the client runs on the remote machine. The client is the
program or end of a system that is receiving the service
provided by the server. In the case of _p_e_e_r _t_o _p_e_e_r systems such
as _s_l_i_p or _p_p_p the client is taken to be the end that initiates
the connection and the remote end, being called, is taken to be
the server.
ddaattaaggrraamm
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'.
DDLLCCII
The DLCI is the Data Link Connection Identifier and is used to
identify a unique virtual point to point connection via a Frame
Relay network. The DLCI's are normally assigned by the Frame
Relay network provider.
FFrraammee RReellaayy
Frame Relay is a network technology ideally suited to carrying
traffic that is of bursty or sporadic nature. Network costs are
reduced by having many Frame Relay customer sharing the same
network capacity and relying on them wanting to make use of the
network at slightly different times.
HHaarrddwwaarree aaddddrreessss
This is a number that uniquely identifies a host in a physical
network at the media access layer. Examples of this are _E_t_h_e_r_n_e_t
_A_d_d_r_e_s_s_e_s and _A_X_._2_5 _A_d_d_r_e_s_s_e_s.
IISSDDNN
This is an acronym for _I_n_t_e_g_r_a_t_e_d _S_e_r_v_i_c_e_s _D_i_g_i_t_a_l _N_e_t_w_o_r_k. ISDN
provides a standardized means by which Telecommunications
companies may deliver either voice or data information to a
customers premises. Technically ISDN is a circuit switched data
network.
IISSPP
This is an acronym of Internet Service Provider. These are
organizations or companies that provide people with network
connectivity to the Internet.
IIPP aaddddrreessss
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.
MMSSSS
The Maximum Segment Size (_M_S_S) 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.
MMTTUU
The Maximum Transmission Unit (_M_T_U) is a parameter that
determines the largest datagram than can be transmitted by an IP
interface without it needing to be broken down into smaller
units. The MTU should be larger than the largest datagram you
wish to transmit unfragmented. Note, this only prevents
fragmentation locally, some other link in the path may have a
smaller MTU and the datagram will be fragmented there. Typical
values are 1500 bytes for an ethernet interface, or 576 bytes
for a SLIP interface.
rroouuttee
The _r_o_u_t_e is the path that your datagrams take through the
network to reach their destination.
sseerrvveerr
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 _f_t_p, _N_e_t_w_o_r_k_e_d _F_i_l_e
_S_y_s_t_e_m, or _D_o_m_a_i_n _N_a_m_e _S_e_r_v_e_r. In the case of _p_e_e_r _t_o _p_e_e_r
systems such as _s_l_i_p or _p_p_p the server is taken to be the end of
the link that is called and the end calling is taken to be the
client.
wwiinnddooww
The _w_i_n_d_o_w is the largest amount of data that the receiving end
can accept at a given point in time.
1133.. CCooppyyrriigghhtt..
_C_o_p_y_r_i_g_h_t _I_n_f_o_r_m_a_t_i_o_n
Original Authors: Terry Dawson (main author), VK2KTJ; Alessandro
Rubini (maintainer)
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 Joshua D. Drake {POET} -
http://www.linuxports.com/
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.