2158 lines
87 KiB
Plaintext
2158 lines
87 KiB
Plaintext
Newsgroups: comp.os.linux.announce,comp.os.linux.help,comp.os.linux.admin,news.answers,comp.answers
|
|
From: terryd@extro.ucc.su.oz.au (Terry Dawson)
|
|
Subject: Linux NET-2 HOWTO
|
|
Keywords: Linux, Networking, TCP/IP, NET-2, SLIP
|
|
Summary: HOWTO configure TCP/IP networking, SLIP, PLIP, and PPP under Linux.
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-name: linux/howto/networking
|
|
Last-modified: 21 Feb 94
|
|
|
|
This is the Linux NET-2 HOWTO (previously known as the NET-2-FAQ).
|
|
This document explains how to configure TCP/IP and SLIP with the new
|
|
``NET-2'' networking code in Linux kernels 0.99.pl10 and above.
|
|
Please mail me if you have questions or comments. --terryd
|
|
|
|
This is the Linux NET-2 HOWTO v1.11, 26 January 1994
|
|
By Terry Dawson <terryd@extro.ucc.su.oz.au> and
|
|
Matt Welsh <mdw@sunsite.unc.edu>
|
|
|
|
(c)1994 by Terry Dawson, Matt Welsh
|
|
|
|
CHANGES from previous version:
|
|
Added the NFS questions and answers that Alan posted, thanks Alan.
|
|
Added dynamic slip server script - thanks Paul Mossip!
|
|
Added dip-i source, thanks Karl, kkeyte@esoc.bitnet
|
|
Added copyright message. Ack.
|
|
|
|
*** FTP site maintainers: This document should be stored in the docs/HOWTO
|
|
*** directory on your Linux archive as ``NET-2-HOWTO''. You may also wish
|
|
*** to link this file to ``NET-2-FAQ'' (its previous name). This document
|
|
*** also supercedes the old Linux NET-FAQ.
|
|
|
|
'Real Programmers don't write documentation.' -- Ancient Proverb
|
|
|
|
INDEX for this version
|
|
|
|
To search for a particular section, search for '^N.S' where
|
|
N is the section, and S is the Subsection.
|
|
|
|
0. Introduction.
|
|
0.1 Disclaimer.
|
|
0.2 Questions already ?
|
|
0.3 Related documentation.
|
|
0.4 New versions of this document.
|
|
0.5 Feedback.
|
|
1. NET-2 Supported Functionality.
|
|
1.1 Supported Ethernet cards.
|
|
2. Getting the NET-2 Software.
|
|
2.1 Unpacking the software.
|
|
2.2 Putting things in the right place.
|
|
2.3 Creating the device interfaces.
|
|
3. Building the Kernel.
|
|
3.1 Configuring the NET-2 kernel code.
|
|
3.2 Building the kernel.
|
|
4. Configuring NET-2 TCP/IP.
|
|
4.1 Before you begin.
|
|
4.2 /etc/rc.d/rc.inet1 and /etc/rc.d/rc.inet2
|
|
4.2.1 Editing rc.inet1
|
|
4.2.2 Editing rc.inet2
|
|
4.2.2.1 "To named or not to named... that is the question."
|
|
4.3 /etc/hosts
|
|
4.3.1 Important note regarding /etc/hosts from NET-032.
|
|
4.4 /etc/networks
|
|
4.5 /etc/host.conf
|
|
4.6 /etc/resolv.conf
|
|
4.7 /etc/HOSTNAME
|
|
4.8 /etc/rc.local
|
|
4.9 Other files.
|
|
5. Configuring SLIP.
|
|
5.1 Static SLIP server connections using a dialup line.
|
|
5.2 Static SLIP server connections using a leased line or cable.
|
|
5.3 Dynamic SLIP server connections using a dialup line.
|
|
5.4 Using DIP.
|
|
5.5 Configuring your Linux Machine as a SLIP Server.
|
|
5.6 /etc/net/diphosts
|
|
5.7 Configuring PLIP interfaces.
|
|
5.7.1 PLIP Cabling Diagram.
|
|
6. PPP (Under construction).
|
|
7. AX.25 (Under construction).
|
|
8. Are You Stuck ?
|
|
9. Common Problems and Solutions.
|
|
9.1 Not so common problems and solutions (Mostly NFS).
|
|
10. Known bugs.
|
|
11. Copyright Message. (We're not ogres, nor are we silly).
|
|
12. Miscellaneous.
|
|
13. Change History.
|
|
|
|
------------------------------------------------------------------------------
|
|
0. Introduction.
|
|
|
|
This is the NET-2 HOWTO, which is a rewrite of the earlier NET-FAQ for
|
|
the new NET-2 TCP/IP code in Linux kernels 0.99.pl10 and above.
|
|
|
|
The NET-2 code is the new kernel-based networking support for Linux,
|
|
written by Fred van Kempen <waltje@uwalt.nl.mugnet.org>. It is based
|
|
on the NET-1 code by Ross Biro <bir7@leland.stanford.edu>, ethernet
|
|
drivers by Donald Becker <becker@super.org>, SLIP drivers by
|
|
Laurence Culhane <loz@holmes.demon.co.uk>, and the D-Link driver by
|
|
Bj0rn Ekwall <bj0rn@blox.se>. The NET-2debugged code is maintained
|
|
by Alan Cox <iiitac@pyr.swan.ac.uk>. Many others too numerous to
|
|
mention have provided support, bug fixes, and help.
|
|
|
|
This NET-2 HOWTO is by Terry Dawson and Matt Welsh. It covers setup
|
|
and configuration of TCP/IP under Linux using NET-2. It also hopefully
|
|
answers some of the many questions about the NET-2 code and common
|
|
problems that people have. It does not cover using TCP/IP (i.e.
|
|
using telnet, FTP, etc.), other documents are available which will
|
|
describe these much better than I am able to.
|
|
|
|
0.1 Disclaimer.
|
|
|
|
The NET-2 code is under development, which means that it may
|
|
not be as stable and easy to configure as you may like it to be.
|
|
code is relatively new and bug fixes are being posted every day, so if
|
|
you run into a large number of problems just hang in there. The
|
|
software is in two stages of development at the moment. The version
|
|
currently supplied in the standard kernel distribution is version
|
|
NET-2D(ebugged), and is being progressively debugged and made more
|
|
stable by Alan Cox, until NET-2E, which is currently undergoing Beta
|
|
testing, is ready for general release.
|
|
|
|
We do not, and cannot know everything there is to know about the
|
|
Linux networking code. Please accept that this document may, and
|
|
probably does contain errors. Please read any README files that
|
|
are bundled with any of the various pieces of software described
|
|
in this document for more detailed and accurate information. We
|
|
will attempt to keep this document as error free as possible.
|
|
|
|
NOTE: In this document, 'NET-2' does not refer to the Berkeley
|
|
Software Distribution NET-2 release of BSD UNIX. Yes, the names
|
|
are conflicting. In this HOWTO, 'NET-2' refers only to the new
|
|
generation of TCP/IP code in the Linux kernel.
|
|
|
|
0.2 Questions already ?
|
|
|
|
'The only stupid question is the unasked one.' - One of my own Motto's
|
|
|
|
If you have general configuration questions, and you have been unable
|
|
to find the answers after reading the other various HOWTO and FAQ
|
|
files, then you would be best served to post them comp.os.linux.help,
|
|
or, if you believe it to be specifically related the NET-2 kernel
|
|
code, then you could post it to the NET mailing list. Please include
|
|
as much relevant information as possible, there is nothing more
|
|
annoying than to have a bug or problem reported without sufficient
|
|
information to even begin searching for it.
|
|
|
|
Version numbers and revisons of code, a detailed account of the
|
|
problem, and the circumstances that caused it to happen are essential.
|
|
Traces and debug messages where available should also be considered
|
|
mandatory.
|
|
|
|
If you have a question relating to the configuration of, or problems
|
|
experienced with, _any_ linux distribution, regardless of
|
|
whether it be SLS, Slackware, Yggadsril, TAMU, MCC, Pro, or other,
|
|
please contact the people who created the distribution for support
|
|
before attempting to report it to the list or the NET-2 developers
|
|
directly. The developers of the NET-2 code _cannot_ and _will not_
|
|
offer support for NET-2 as distributed in any form, other than as
|
|
specified in this document, or as per distributed Alpha/Beta test
|
|
instructions.
|
|
|
|
Please do NOT bug the NET-2 developers directly unless you have a
|
|
_development_-related issue (especially Fred: he has to pay $$$ for
|
|
his e-mail access).
|
|
|
|
To join the NET channel of the Linux-activists mailing list
|
|
send mail to
|
|
linux-activists-request@niksula.hut.fi
|
|
with the line
|
|
X-Mn-Admin: join NET
|
|
at the top of the message body (not the subject).
|
|
|
|
Note that the SLIP channel of the mailing list has been disabled and
|
|
the NET channel should be used for SLIP discussions as well.
|
|
Remember, keep in mind that the NET channel is for development
|
|
discussions only.
|
|
|
|
Note also that a PPP list has been established. To join it, use the
|
|
same procedure as for joining the NET list, except specify PPP in
|
|
place of NET.
|
|
|
|
|
|
0.3 Related documentation.
|
|
|
|
There is now a book from the Linux Documentation Project entitled
|
|
`Linux Network Administration Guide' by Olaf Kirch. It covers all
|
|
aspects of setting up and using networking under Linux, including
|
|
TCP/IP, NFS, UUCP, mail, news, etc.
|
|
|
|
This book supplements the NET-2 HOWTO and covers all of the
|
|
other aspects of using TCP/IP. This guide simply covers setup of
|
|
NET-2, i.e., "How to put your machine on the net". If you are new
|
|
to unix networking, then I strongly urge you to obtain a copy and
|
|
read it first. It will answer a lot of questions for you that are
|
|
not within the scope of this document.
|
|
|
|
The current version is available in:
|
|
|
|
sunsite.unc.edu:/pub/Linux/docs/linux-doc-project/network-guide
|
|
|
|
There are various versions of the file available. The most common
|
|
formats are supported, being plain ascii, Postscript, DVI, Latex
|
|
and groff.
|
|
|
|
The Linux Network Administrators Guide is Copyright (c) by Olaf Kirch.
|
|
|
|
You should read the Ethernet HOWTO (from sunsite.unc.edu:
|
|
/pub/Linux/docs/HOWTO) if you are using an Ethernet network
|
|
with NET-2. The Ethernet HOWTO explains all of the ins and outs
|
|
of using and configuring Ethernet devices for Linux, and should
|
|
be considered the definitive source of information relating to same.
|
|
That is, if the Ethernet HOWTO and this HOWTO differ, then believe
|
|
the Ethernet HOWTO.
|
|
|
|
This NET-2 HOWTO supercedes the earlier 'Linux NET-FAQ' by Phil
|
|
Copeland and Matt Welsh. The NET-FAQ is for Linux kernels previous
|
|
to 0.99.pl10, running the older version of the TCP/IP code.
|
|
|
|
This document used to be called the NET-2-FAQ, before the Linux HOWTO
|
|
project was underway. Thus, the NET-2-FAQ and the NET-2 HOWTO are
|
|
the same.
|
|
|
|
0.4 New versions of this document.
|
|
|
|
New versions of this document can be retrieved via anonymous
|
|
FTP from sunsite.unc.edu:/pub/Linux/docs/HOWTO/NET-2-HOWTO
|
|
or directly from me (terryd@extro.ucc.su.oz.au). It will also be
|
|
posted to the newsgroups comp.os.linux.announce, comp.os.linux.help,
|
|
and news.answers periodically.
|
|
|
|
You can find news.answers FAQ postings, including this one, archived
|
|
on rtfm.mit.edu:/pub/usenet.
|
|
|
|
0.5 Feedback.
|
|
|
|
Please send any comments, updates, or suggestions to me,
|
|
terryd@extro.ucc.su.oz.au. The sooner I get feedback about this
|
|
document, the sooner I can update and correct it. If you find any
|
|
problems with it, please mail me, instead of posting to one of the
|
|
newsgroups. I may miss your corrections. Thanks.
|
|
|
|
Please send any money or interesting pieces of hardware to either
|
|
Fred, Linus, or the Free Software Foundation. They made this happen.
|
|
|
|
|
|
1. NET-2 Supported Functionality.
|
|
|
|
The NET-2 code is a complete kernel implementation of TCP/IP for
|
|
Linux, including many features not found in the original networking
|
|
code. NET-2 supports most popular Ethernet cards, real IP routing,
|
|
SLIP (Serial Line IP) for TCP/IP connections over a serial line, such
|
|
as the phone line via modem, and PLIP (Parallel Line IP) for local
|
|
connection of two machines using your printer ports.
|
|
|
|
NET-2 does not yet include:
|
|
|
|
- SPX(SPP)/IPX(IDP)/NCP support, though it is being worked on.
|
|
- PPP support, this is being worked on, and an ALPHA version exists.
|
|
read on for more details.
|
|
- AX.25 support natively, though Alan Cox has some experimental code
|
|
available for pl14+ for you to try. Fred has the start of fully
|
|
integrated DDI based AX25 support in NET-2EB2+
|
|
- LAN types other than Ethernet, this means no Token Ring, no
|
|
FDDI, no ARCNET, etc. An experimental Token Ring driver is being
|
|
quietly developed.
|
|
- ISDN support, though I understand it too is being worked on.
|
|
|
|
1.1 Supported Ethernet cards.
|
|
|
|
NET-2 supports the following Ethernet cards (and more):
|
|
|
|
3com 3c503, 3c503/16
|
|
Novell NE1000, NE2000
|
|
Western Digital WD8003, WD8013
|
|
Hewlett Packard HP27245, HP27247, HP27250
|
|
|
|
The following clones are reported to work:
|
|
WD-80x3 clones: LANNET LEC-45
|
|
NE2000 clones: Alta Combo, Artisoft LANtastic AE-2, Asante Etherpak
|
|
2001/2003, D-Link Ethernet II, LTC E-NET/16 P/N 8300-200-002,
|
|
Network Solutions HE-203, SVEC 4 Dimension Ethernet, 4-Dimension
|
|
FD0490 EtherBoard 16, D-Link DE-600, SMC Elite 16.
|
|
|
|
** Please see the Ethernet HOWTO for more complete information. **
|
|
|
|
As mentioned above, NET-2 also supports SLIP in the kernel. Therefore
|
|
if you don't have an Ethernet connection you can do TCP/IP over the
|
|
phone line, provided you have a SLIP server nearby (many universities
|
|
and businesses provide SLIP access to employees/students) and a
|
|
compatible modem (usually 14.4 v.42bis, depending on your SLIP server).
|
|
Two possible modems are the US Robotics Sportster, or the Infotel
|
|
144DF Internal.
|
|
|
|
|
|
2. Getting the NET-2 Software.
|
|
|
|
Before you can configure TCP/IP on your system you need to get the
|
|
appropriate software. This includes the current version of the Linux
|
|
kernel (0.99.pl14 or above), TCP/IP configuration programs and files
|
|
(e.g., /etc/ifconfig, /etc/hosts), and finally a set of network
|
|
application programs (such as telnet, ftp, rlogin, etc.).
|
|
|
|
You may already have all of the items below. Check and make
|
|
sure that you do. For example, some distributions come with all
|
|
of the NET-2 configuration files, binaries, libraries, and kernel
|
|
installed, so there's no reason to get the following files.
|
|
Note: they may not be in the places specified in this HOWTO.
|
|
|
|
If you DO have the NET-2 software already, skip to section 3 on
|
|
configuration. If you do NOT have the NET-2 software, follow the
|
|
directions below.
|
|
|
|
The current kernel version is found in
|
|
nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus/linux-0.99.14.tar.gz.
|
|
This is a gzipped tar file; .gz is the new extension used by gzip.
|
|
If you have the old version of gzip, "zcat foo.gz | tar xvf -" works.
|
|
|
|
The current libraries (libc-4.4.4), can be found in
|
|
sunsite.unc.edu:/pub/Linux/GCC/image-4.4.4.tar.z. (You'll probably
|
|
want to install the include files in inc-4.4.4.tar.z as well! See the
|
|
READMEs there for details.) You'll need at least ver 4.4.2 to use
|
|
NET-2, as there were problems with earlier versions that affected
|
|
routing and netmasks.
|
|
|
|
The current NET-2 configuration file distribution is in
|
|
|
|
sunacm.swan.ac.uk:
|
|
/pub/misc/Linux/Networking/Programs/System/net032/net-0.32.tar.gz
|
|
|
|
This package includes network configuration programs such as
|
|
ifconfig, route, netstat etc.
|
|
|
|
The TCP/IP application binaries and setup files are found in:
|
|
|
|
tsx-11.mit.edu:/pub/linux/packages/net/net-2/binaries/net-base.tar.z
|
|
" " " " " " " /net-std.tar.z
|
|
" " " " " " " /net-ext.tar.z
|
|
|
|
As some of the internals of the networking code have changed, you will
|
|
also need to get and install the files that are in the:
|
|
|
|
tsx-11.mit.edu:/pub/linux/packages/net/new-net-2
|
|
|
|
directory, as they correct some problems you will experience if you
|
|
opt _not_ to get and install them :)
|
|
|
|
If you use shadowed password (Most SLS users do), then you may find
|
|
that the standard network programs do not support them. There used
|
|
to be a specially modified package of binaries about, but these were
|
|
intended as a short term fix, and have been removed. Recent work on
|
|
the standard libraries will mean that as of version 4.5.8 of libc,
|
|
the shadow password handling will no longer need to be in the
|
|
application, and will be handled externally. At the time of writing
|
|
libc.4.5.8 has just been released. If you use shadowed passwords
|
|
you will most certainly want a copy of this.
|
|
|
|
2.1 Unpacking the software.
|
|
|
|
You don't need to unpack any of the following if you already have all
|
|
of the NET-2 software installed.
|
|
|
|
First, unpack the kernel sources in /usr/src. This will put all
|
|
of the kernel sources under /usr/src/linux (the usual place).
|
|
|
|
# cd /usr/src
|
|
# zcat linux-0.99.14.tar.z | tar xvf -
|
|
|
|
Next, unpack the libraries.
|
|
(The following is a summary, please read the detailed instructions
|
|
that come with the libraries for complete installation details)
|
|
|
|
# cd /
|
|
# zcat image-4.4.4.tar.z | tar xvf -
|
|
|
|
Now, make the links to the new libraries in /lib. BE VERY CAREFUL
|
|
that you do not delete the previous links. Do everything in
|
|
one step, as so:
|
|
|
|
# ln -sf /lib/libc.so.4.4.4 /lib/libc.so.4
|
|
# ln -sf /lib/libm.so.4.4.4 /lib/libm.so.4
|
|
|
|
Next, unpack the net-base package, which contains the basic
|
|
utils and configuration files in /etc. Note that net-base makes
|
|
symlinks in /etc for all of your TCP/IP configuration files to /conf.
|
|
|
|
Therefore, BE WARNED: Before you unpack the following tar files,
|
|
make a backup of your files in /etc. Unpacking net-base will overwrite
|
|
many of the files in /etc with symbolic links to other places.
|
|
For example, /etc/hosts is a symlink to /conf/net/hosts. Why is this
|
|
done? Because Fred's Linux/PRO distribution of Linux keeps all
|
|
machine-specific configuration files in /conf. And because this is
|
|
the way he does it, we may as well too. In general it makes things
|
|
easier to locate. If you want to keep all of your net files in
|
|
/etc, that's fine, but you'll have to put them there by hand.
|
|
|
|
Make a backup of everything in /etc before you unpack net-base.
|
|
Then unpack it from / (the root directory):
|
|
|
|
# cd /
|
|
# zcat net-base.tar.z | tar xvvofp -
|
|
|
|
Also, unpack net-std.tar.z, which contains the network clients and
|
|
daemons (e.g., telnet and telnetd). Unpack it from / as well:
|
|
|
|
# cd /
|
|
# zcat net-std.tar.z | tar xvvofp -
|
|
|
|
|
|
If you wish to use tin (a newsreader), or DIG (the DARPA Internet
|
|
Groper), unpack the net-ext package from /:
|
|
|
|
# cd /
|
|
# zcat net-ext.tar.z | tar xvvofp -
|
|
|
|
Now unpack the fixed versions of rlogin/telnetd from the files:
|
|
|
|
# cd /tmp
|
|
# gzip -dc ftpd.tar.z | tar xvf -
|
|
# gzip -dc telnet-rlogin.tar.z | tar xvf -
|
|
|
|
you will then need to copy the binaries to where the old
|
|
version currently live.
|
|
|
|
Finally, unpack the net-032 package, which contains the sources
|
|
for the TCP/IP setup programs (ifconfig, arp, route, etc.) and the
|
|
configuration files. This is unpacked into /usr/src/net-032.
|
|
|
|
# mkdir /usr/src/net-032
|
|
# cd /usr/src/net-032
|
|
# zcat net-032.tar.gz | tar xvvofp -
|
|
# make install
|
|
|
|
** Important information for Shadow Password users **
|
|
If you are using the SLS distribution, then replace any blank
|
|
passwords in /etc/passwd with :x: instead of ::.
|
|
Otherwise rshd/rlogind will let anyone become these user ids.
|
|
This is an SLS setup bug and will, by default allow anyone remote
|
|
access to your machine, with root priveledges!
|
|
|
|
2.2 Putting things in the right place.
|
|
|
|
With the standard NET-2 distribution, all of the configuration files
|
|
are in /conf/net, with links in /etc. For example, /etc/hosts
|
|
is a link to /conf/net/hosts. However, if you are using a
|
|
standard pre-packaged distribution of Linux such as SLS, /conf/net
|
|
probably isn't used... that is, /etc/hosts is just /etc/hosts.
|
|
So, when I say "/conf/net/hosts", I mean "/etc/hosts", and vice
|
|
versa.
|
|
|
|
Just keep in mind that the TCP/IP software only looks in /etc and
|
|
/usr/etc for configuration files. Therefore, it makes sense to
|
|
keep all of your files in /etc and /usr/etc as they should be.
|
|
HOWEVER, Fred has decided to put the files in /conf/net with LINKS
|
|
in /etc. Either way, it doesn't matter. When we say "/etc/hosts",
|
|
it doesn't matter if /etc/hosts is an actual file or a link to
|
|
/conf/net/hosts.
|
|
|
|
If you just unpacked NET-2 above (i.e. you don't already have the
|
|
files from installing SLS), then you don't have the configuration
|
|
files in /conf/net (you only have the symlinks in /etc).
|
|
The easiest way to get the configuration files in /conf/net is
|
|
to copy them from the net-032 distribution:
|
|
|
|
# mkdir -p /conf/net
|
|
# chown -R root.root /conf; chmod -R 755 /conf
|
|
# cp /usr/src/net-032/etc/* /conf/net
|
|
|
|
You should make sure that all of the symlinks to /conf/net in /etc
|
|
can be resolved (that is, try to "more" or "cat" each file, make
|
|
sure you don't get any errors). Also note that some files will
|
|
be duplicated: for example, /etc/inetd.conf is a symlink to
|
|
/usr/etc/inetd.conf. However, from the cp command above you also
|
|
have a /conf/net/inetd.conf, which can be deleted (remember that
|
|
all of the programs still look in /etc, not /conf. So whatever is
|
|
in /etc is the file which is actually being used).
|
|
|
|
|
|
2.3 Creating the device interfaces.
|
|
|
|
In previous versions it was necessary to create a number of
|
|
device files for the NET-2 code. This is no longer the case.
|
|
|
|
If you have any of the following files created you should delete
|
|
them:
|
|
|
|
rm /dev/net /dev/unix /dev/inet
|
|
rm /dev/ip /dev/icmp /dev/tcp /dev/udp
|
|
rm /dev/wd0 /dev/wd1 /dev/wd2 /dev/wd3
|
|
rm /dev/ec0 /dev/ec1 /dev/ec2 /dev/ec3
|
|
rm /dev/ne0 /dev/ne1 /dev/ne2 /dev/ne3
|
|
|
|
should clean them all.
|
|
|
|
However, the arp program does need /dev/arp, so:
|
|
|
|
mknod -m 600 /dev/arp c 16 1
|
|
|
|
will create it ok. If you already have it, check that it looks
|
|
the same.
|
|
|
|
3. Building the Kernel.
|
|
|
|
You're now ready to build the new 0.99.pl14 kernel with the NET-2
|
|
code enabled.
|
|
|
|
3.1 Configuring the NET-2 kernel code.
|
|
|
|
A 'make config' will take you through configuring the kernel
|
|
Select the drivers you desire by answering 'yes' when prompted.
|
|
|
|
Note, you will be prompted for "Network Device Support?", but
|
|
the label after it might suggest that this is for Ethernet only,
|
|
this is not the case, and you must answer 'yes' to this, even if
|
|
you only desire the slip or plip drivers to be configured.
|
|
You will be asked later about each of the ethernet drivers,
|
|
slip and plip in turn.
|
|
|
|
The Ethernet HOWTO also contains much useful information for
|
|
configuring Ethernet devices in the kernel.
|
|
|
|
3.2 Building the kernel.
|
|
|
|
You can now build the kernel as you normally would (see the file
|
|
/usr/src/linux/README if you've never done this before). Essentially
|
|
this entails editing /usr/src/linux/Makefile to set root device and
|
|
default display mode. (*Note: keyboard is now handled by loadable
|
|
keymaps as of 0.99.pl10; grab the file keytable.tar.z from your
|
|
nearest Linux ftp site).
|
|
|
|
Finally do 'make dep' and 'make'. You now have a new 0.99.14 kernel
|
|
with NET-2 set up. I wouldn't reboot it quite yet as we still have
|
|
to configure the NET-2 programs before it will work correctly.
|
|
|
|
4. Configuring NET-2 TCP/IP.
|
|
|
|
The final step is to modify the various setup files to get NET-2
|
|
working. After this is ready you can boot your new kernel and
|
|
go happily netting (if all goes well).
|
|
|
|
In this section I'll describe each of the major TCP/IP setup files,
|
|
what they do, and what you need to do to configure them.
|
|
|
|
If you're using SLIP, see section 5.0 on configuring SLIP. The
|
|
discussion below is for Ethernet connections only. SLIP users
|
|
should FIRST read all of section 4.0 and then apply the changes
|
|
discussed in section 5.0.
|
|
|
|
4.1 Before you begin.
|
|
|
|
Before you can configure NET-2 TCP/IP, you need to find out
|
|
the following information about your network setup. Your network
|
|
admins can tell you most of these things.
|
|
|
|
* IP address: this is the unique machine address in dotted-decimal
|
|
format. An example is 128.253.153.54. Your network admins will
|
|
provide you with this number.
|
|
|
|
If you're only configuring loopback mode (i.e. no SLIP, no ethernet
|
|
card, just TCP/IP connections to your own machine---called
|
|
"loopback") then your IP address is 127.0.0.1.
|
|
|
|
* Your network mask ('netmask'). For performance reasons, it is
|
|
desirable to limit the number of hosts on any particular segment
|
|
of a network. If you have a large number of addresses allocated
|
|
to you, you might break those addresses up into large chunks,
|
|
and create subnetworks, and then allow each individual network
|
|
segment be a subnetwork of the whole network. The network mask
|
|
is a pattern of bits, which when overlayed onto an address on your
|
|
network, will tell you which subnet that address lives on. This is
|
|
very important for routing, and if you find, for example, that you
|
|
can happily talk to people outside your network, but not to some
|
|
people within your network, there is a good chance that you have
|
|
an incorrect mask specified.
|
|
|
|
Your network administrators will have chosen the netmask when the
|
|
network was designed, and therefore they should be able to supply
|
|
you with the correct mask to use. Most networks are class C
|
|
subnetworks which use 255.255.255.0 as their netmask. Other Class B
|
|
networks use 255.255.0.0. The NET-2 code will automatically select
|
|
a mask that assumes no subnetting as a default if you do not specify
|
|
a mask.
|
|
|
|
The masks chosen by default are as follows:
|
|
|
|
For addresses with the first byte:
|
|
1-127 255.0.0.0 (Class A)
|
|
128-191 255.255.0.0 (Class B)
|
|
192+ 255.255.255.0 (Class C+)
|
|
|
|
If one of these doesn't work, try the other. If this
|
|
doesn't work, ask your local net guru for help.
|
|
|
|
This applies equally well to the loopback port. Since the
|
|
loopback ports address is always 127.0.0.1, the netmask for
|
|
this port is always 255.0.0.0. You can either specify this
|
|
explicitly or rely on the default mask.
|
|
|
|
* Your network address. This is your IP address masked with the netmask.
|
|
For example, if your netmask is 255.255.255.0, and your IP address
|
|
is 128.253.154.32, your network number (IP addr AND netmask) is
|
|
128.253.154.0. With a netmask of 255.255.0.0,
|
|
this would be 128.253.0.0.
|
|
|
|
If you're only using loopback, you don't have a net address.
|
|
|
|
* Your broadcast address. This is your IP address masked with the
|
|
netmask, and then possibly ORed with the subnetmask inverted.
|
|
Such that for a Class C network, with netmask 255.255.255.0,
|
|
your broadcast address will be your network address (calculated
|
|
above) ORed with 0.0.0.255.
|
|
|
|
For example:
|
|
|
|
Your IP address is: 128.253.154.32
|
|
Your netmask is: 255.255.255.0
|
|
netmask inverted is: 000.000.000.255
|
|
|
|
then:
|
|
|
|
Your broadcast address should be: 128.253.154.255.
|
|
|
|
Note that for historical reasons, some networks are setup to use
|
|
the network address as the broadcast address, if you have any doubt,
|
|
check with your net admin.
|
|
|
|
If you have access to a sniffer, or some other device capable of
|
|
providing a trace of your network, then you might be able to
|
|
determine both the network and broadcast addresses by looking at the
|
|
traffic on your network. Keep an eye open (or filter all traffic
|
|
except) for ethernet frames destined for the ethernet broadcast
|
|
address: ff:ff:ff:ff:ff:ff, if it is an IP datagram, then look at
|
|
the destination ip address. If the IP source address is your router,
|
|
and the protocol ID is not ARP, then what you are seeing might be a
|
|
routing broadcast. The destination IP address in this case will be
|
|
the IP broadcast address of your network. You can then work out the
|
|
IP network address. But again, if in doubt then consult your network
|
|
admin, or check the configuration of a known working machine.
|
|
|
|
If you're only using loopback, you don't have a broadcast address.
|
|
|
|
* Your gateway address. This is the address of the machine which
|
|
is your "gateway" to the outside world (i.e. machines not on your
|
|
subnet). In general the gateway machine has an IP address identical
|
|
to yours but with a ".1" in the last position; e.g. if your IP
|
|
address is 128.253.154.32, your gateway might be 128.253.154.1.
|
|
Your network admins will provide you with the IP address of your
|
|
gateway.
|
|
|
|
If you're only using loopback, you don't have a gateway address.
|
|
If your network is not connected to the Internet, that is, it
|
|
is a standalone network, then you don't have a gateway, and
|
|
therefore don't need a gateway address.
|
|
|
|
* Your nameserver address. Most machines on the net have a name
|
|
server which translates hostnames into IP addresses for them.
|
|
Your network admins will tell you the address of your name server.
|
|
You can in fact run a nameserver on your own machine by running
|
|
named, in which case the nameserver address is 127.0.0.1. However,
|
|
But it is not required that you run named at all; see section
|
|
4.2.2.1.
|
|
|
|
If you're only using loopback, you don't have a nameserver
|
|
address. (After all, you're only connecting to yourself.)
|
|
|
|
SLIP USERS: You may or may not require any of the above information
|
|
except for a nameserver address. Depending on how your slip access
|
|
is achieved, you will either be given an ip address to use, in
|
|
which case you probably already know it, or the slip server will
|
|
dynamically allocate one for you. How to handle this situation is
|
|
described in section 5.
|
|
|
|
NET-2 supports full routing, multiple routes, subnetworking (at
|
|
this stage on byte boundaries only), the whole nine yards. The above
|
|
describes most basic TCP/IP configurations. Yours may be quite
|
|
different: when in doubt, consult your local network gurus and check
|
|
out the man pages for "route" and "ifconfig" included with the net-032
|
|
package. Configuring TCP/IP networks is very much beyond the scope of
|
|
this document; the above should be enough to get most people started.
|
|
|
|
4.2 /etc/rc.d/rc.inet1 and /etc/rc.d/rc.inet2
|
|
|
|
For the non-UNIX wizard: "rc" files are run at bootup time by the
|
|
"init" program and start up all of the basic system programs, such
|
|
as sendmail, cron, etc. as well as the NET-2 daemons (such as inetd).
|
|
They are analogous to the MS-DOS autoexec.bat file, and "rc" might
|
|
stand for "runtime commands". For NET-2 the rc files are found in
|
|
/etc/rc.d. It doesn't really matter where you keep them, as long as
|
|
init can find them. (We'll go into this later).
|
|
|
|
First things first. The file /etc/rc.d/rc.inet1 configures the basic
|
|
TCP/IP interface to your machine, using two programs: /etc/ifconfig
|
|
and /etc/route.
|
|
|
|
/etc/ifconfig is used for configuring interface with the parameters
|
|
that they require to function, such as IP addresses, network masks,
|
|
broadcast addresses and the like.
|
|
|
|
/etc/route is used to create entries in a table (the routing table)
|
|
that the networking code will look in, to determine where to send
|
|
datagrams that it wishes to transmit.
|
|
|
|
Note that in the previous NET-1 code, the name of the interface
|
|
configuration program was "config". However, the "standard" for UNIX
|
|
system TCP/IP configuration is to use ifconfig and route, and this has
|
|
been implemented with NET-2.
|
|
|
|
THEREFORE: Be sure NOT to use /etc/config in your rc files. "config"
|
|
will not work with NET-2, and if you try and use it you will see
|
|
messages mentioning "old-style ioctl", and it wont work. You should
|
|
only run rc.inet1 and rc.inet2 at boot time (or rc.net after you have
|
|
converted it).
|
|
|
|
NOTE: The standard SLS "rc" file file calls "/etc/rc.net" instead
|
|
of "/etc/rc.d/rc.inet1" and "/etc/rc.d/rc.inet2". The SLS rc.net
|
|
file can be treated as just the rc.inet1 and rc.inet2 files in
|
|
one file. So when you see rc.inet1, and rc.inet2 below, just add the
|
|
same commands into /etc/rc.net, and you will achieve the same result.
|
|
It is important that the commands in rc.inet1 be run first, so make
|
|
sure those commands are at the top of the file.
|
|
|
|
Below you're going to edit rc.inet1 to use the correct ifconfig and
|
|
route commands for your machine. But first, you need to know the
|
|
information about your network setup in section 4.1, above.
|
|
|
|
4.2.1 Editing rc.inet1
|
|
|
|
Edit the file /etc/rc.d/rc.inet1. This file uses the "ifconfig" and
|
|
"route" commands to configure your network interface at boot time.
|
|
SLS Users: Remember that SLS uses just rc.net, and these command
|
|
should be called first, so put them at the top of the file.
|
|
|
|
You may need to do some heavy surgery on this file to get it to look
|
|
right; it may be easier to delete it and start from scratch. Given
|
|
the information above, a possible rc.inet1 for a machine that has
|
|
a single ethernet interface should look like:
|
|
|
|
|
|
#!/bin/sh
|
|
# Portion of /etc/rc.d/rc.inet1 to configure the loopback interface
|
|
|
|
HOSTNAME=`hostname`
|
|
|
|
# Attach the loopback device.
|
|
/etc/ifconfig lo 127.0.0.1 # uses default netmask 255.0.0.0
|
|
/etc/route add 127.0.0.1 # a route to point to the loopback device
|
|
# End Loopback Definition
|
|
|
|
# Portion of /etc/rc.d/rc.inet1 to configure an ethernet interface
|
|
|
|
# IF YOU HAVE AN ETHERNET CONNECTION, use these lines below to configure the
|
|
# eth0 interface. If you're only using loopback or SLIP, don't include the
|
|
# rest of the lines in this file.
|
|
|
|
# Edit for your setup.
|
|
IPADDR="128.253.154.32" # REPLACE with YOUR IP address!
|
|
NETMASK="255.255.255.0" # REPLACE with YOUR netmask!
|
|
NETWORK="128.253.154.0" # REPLACE with YOUR network address!
|
|
# Note: NETWORK MUST be in
|
|
# /etc/networks
|
|
BROADCAST="128.253.154.255" # REPLACE with YOUR broadcast address, if you
|
|
# have one. If not, leave blank and edit below.
|
|
GATEWAY="128.253.154.1" # REPLACE with YOUR gateway address!
|
|
|
|
/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
|
|
# If you don't have a broadcast address, change the above line to just:
|
|
# /etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK}
|
|
|
|
/etc/route add ${NETWORK} # MUST HAVE AN ENTRY IN
|
|
# /etc/networks !!!
|
|
|
|
/etc/route add default gw ${GATEWAY} metric 1 # Only necessary if your
|
|
# network has an Internet
|
|
# connection.
|
|
# End of Ethernet Configuration
|
|
|
|
|
|
This is a basic rc.inet1 to run the ifconfig and route commands
|
|
needed to set up a basic TCP/IP connection. Edit this for your setup.
|
|
If you do not have an ethernet interface, and either have a standalone
|
|
workstation (no network connection at all), or you use SLIP, then
|
|
you need only the two lines that refer to the loopback interface "lo"
|
|
as noted.
|
|
|
|
To ensure that this will be run at boot time, make sure that you
|
|
include the command:
|
|
|
|
/bin/sh /etc/rc.d/rc.inet1
|
|
|
|
in your /etc/rc, or in your /etc/inittab (if you're running the
|
|
sysvinit package). In general, make sure that rc.inet1 is run
|
|
BEFORE rc.inet2 at boot time. You may wish to run rc.inet1 and
|
|
rc.inet2 from /etc/rc or /etc/rc.local. Or you can run them from
|
|
/etc/inittab. Either way is fine, but don't run one without the other.
|
|
|
|
|
|
4.2.2 Editing rc.inet2
|
|
|
|
Having run rc.inet1, you now your interfaces configured with addresses,
|
|
and a routing table with enough information to get you started. You'll
|
|
now want to do something with them.
|
|
|
|
The rc.inet2 script is also run at boot time, AFTER rc.inet1.
|
|
It starts up various TCP/IP daemons such as inetd, portmapper,
|
|
and so on. Remember that SLS uses just rc.net, thus, the following
|
|
should appear at the bottom of the file.
|
|
|
|
Now would be a really good time for you to read Olafs Network
|
|
Administrators Guide. It will help you decide what you need to
|
|
put in this file, and what you don't need to put in this file.
|
|
|
|
But Briefly:
|
|
'inetd' is a program that sits in the background and manages
|
|
internet connection requests and the like. It is smart enough
|
|
that you don't need to leave a while bunch of servers running
|
|
even when there is nothing connected to them. When it sees an
|
|
incoming request for a particular service, eg telnet or ftp, it
|
|
will check the /etc/services file, and find what server program
|
|
needs to be run to manage the request, will start it, and hand
|
|
the connection over to it. Imagine it as a master server for you
|
|
internet servers.
|
|
|
|
'syslogd' is a daemon (server that runs in the background) that
|
|
handles all system logging. It accepts messages generated for it,
|
|
will distribute them according to the specifications in
|
|
/etc/syslogd.conf. For example, certain types of messages you will
|
|
want to send to the console and also to log to a file, while others
|
|
will need only be logged, while others yet again, will only need
|
|
to go to the console. syslogd allows you to specify what messages
|
|
you want to send where.
|
|
|
|
For a more complete and detailed description of how all the networking
|
|
bits and pieces fit together, please get Olaf Networking Guide as
|
|
described in section 0.3 (Related Documentation).
|
|
|
|
|
|
You will probably want to comment out most of this file, especially
|
|
if you're not planning on using NFS (Network File System). You
|
|
MUST leave the stanza to run inetd and syslogd uncommented. Note
|
|
that if you DON'T uncomment everything but inetd and syslogd,
|
|
you may run into network problems at first. The best bet is to
|
|
comment all of these things out, get yourself on the network, and
|
|
then worry about configuring the rest of the clients in rc.inet2.
|
|
|
|
If you're not going to be using NFS, you can comment out the lines
|
|
to run: ugidd, mountd, nfsd, pcnfsd, and bwnfsd.
|
|
|
|
You can comment out the stanza to run "umail" unless you have that
|
|
package. In general, most of the things found in rc.inet2 are "sold
|
|
separately". I recommend starting only inetd and syslog at first
|
|
until you get everything going.
|
|
|
|
The following is a copy taken from Fred's net-032 distribution.
|
|
Please check the "NET" declaration, as some distributions might
|
|
keep the network daemons in another directory.
|
|
|
|
Each of the stanzas basically says: "If the filename xxxxxx exists,
|
|
and it is an ordinary file (not a directory, pipe, etc.) then
|
|
execute the following commands".
|
|
|
|
|
|
#! /bin/sh
|
|
#
|
|
# rc.inet2 This shell script boots up the entire INET system.
|
|
# Note, that when this script is used to also fire
|
|
# up any important remote NFS disks (like the /usr
|
|
# distribution), care must be taken to actually
|
|
# have all the needed binaries online _now_ ...
|
|
#
|
|
# Version: @(#)/etc/rc.d/rc.inet2 2.18 05/27/93
|
|
#
|
|
# Author: Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
|
|
#
|
|
|
|
# Constants.
|
|
NET="/usr/etc"
|
|
IN_SERV="lpd"
|
|
LPSPOOL="/var/spool/lpd"
|
|
|
|
# At this point, we are ready to talk to The World...
|
|
echo -e "\nMounting remote file systems ..."
|
|
/bin/mount -t nfs -v # This may be our /usr runtime!!!
|
|
|
|
echo -e "\nStarting Network daemons ..."
|
|
# Start the SYSLOG daemon. This has to be the first server.
|
|
# This is a MUST HAVE, so leave it in.
|
|
echo -n "INET: "
|
|
if [ -f ${NET}/syslogd ]
|
|
then
|
|
echo -n "syslogd "
|
|
${NET}/syslogd
|
|
fi
|
|
|
|
# Start the SUN RPC Portmapper.
|
|
if [ -f ${NET}/rpc.portmap ]
|
|
then
|
|
echo -n "portmap "
|
|
${NET}/rpc.portmap
|
|
fi
|
|
|
|
# Start the INET SuperServer
|
|
# This is a MUST HAVE, so leave it in.
|
|
if [ -f ${NET}/inetd ]
|
|
then
|
|
echo -n "inetd "
|
|
${NET}/inetd
|
|
else
|
|
echo "no INETD found. INET cancelled!"
|
|
exit 1
|
|
fi
|
|
|
|
# Start the NAMED/BIND name server.
|
|
if [ ! -f ${NET}/named ]
|
|
then
|
|
echo -n "named "
|
|
${NET}/named
|
|
fi
|
|
|
|
# Start the ROUTEd server.
|
|
if [ -f ${NET}/routed ]
|
|
then
|
|
echo -n "routed "
|
|
${NET}/routed -q #-g -s
|
|
fi
|
|
|
|
# Start the RWHO server.
|
|
if [ -f ${NET}/rwhod ]
|
|
then
|
|
echo -n "rwhod "
|
|
${NET}/rwhod -t -s
|
|
fi
|
|
|
|
# Start the U-MAIL SMTP server.
|
|
if [ -f XXX/usr/lib/umail/umail ]
|
|
then
|
|
echo -n "umail "
|
|
/usr/lib/umail/umail -d7 -bd </dev/null >/dev/null 2>&1 &
|
|
fi
|
|
|
|
# Start the various INET servers.
|
|
for server in ${IN_SERV}
|
|
do
|
|
if [ -f ${NET}/${server} ]
|
|
then
|
|
echo -n "${server} "
|
|
${NET}/${server}
|
|
fi
|
|
done
|
|
|
|
# Start the various SUN RPC servers.
|
|
if [ -f ${NET}/rpc.portmap ]
|
|
then
|
|
if [ -f ${NET}/rpc.ugidd ]
|
|
then
|
|
echo -n "ugidd "
|
|
${NET}/rpc.ugidd -d
|
|
fi
|
|
if [ -f ${NET}/rpc.mountd ]
|
|
then
|
|
echo -n "mountd "
|
|
${NET}/rpc.mountd
|
|
fi
|
|
if [ -f ${NET}/rpc.nfsd ]
|
|
then
|
|
echo -n "nfsd "
|
|
${NET}/rpc.nfsd
|
|
fi
|
|
|
|
# Fire up the PC-NFS daemon(s).
|
|
if [ -f ${NET}/rpc.pcnfsd ]
|
|
then
|
|
echo -n "pcnfsd "
|
|
${NET}/rpc.pcnfsd ${LPSPOOL}
|
|
fi
|
|
if [ -f ${NET}/rpc.bwnfsd ]
|
|
then
|
|
echo -n "bwnfsd "
|
|
${NET}/rpc.bwnfsd ${LPSPOOL}
|
|
fi
|
|
|
|
fi
|
|
echo network daemons started.
|
|
# Done!
|
|
|
|
4.2.2.1 "To named or not to named... that is the question."
|
|
|
|
"I dub thee ... "
|
|
Named is the nameserver daemon that runs under TCP/IP. It allows
|
|
your machine to serve the name lookup requests of other machines...
|
|
that is, if a machine wants to find the IP address for
|
|
"goober.norelco.com", and you have this machine's IP address in your
|
|
named database, then you can service the request and tell other
|
|
machines what goober's address is.
|
|
|
|
Under older implementations of Linux TCP/IP, to create aliases for
|
|
machine names (even for your own machine), you were required to run
|
|
named on your Linux box to store name->IP address translations. The
|
|
problem with this is that named is generally difficult to setup and
|
|
maintain. To solve this problem, a program called "hostcvt.build"
|
|
was made available on Linux systems to translate your /etc/hosts file
|
|
(see section 4.3) into named database files. However, even with
|
|
this problem out of the way, running named on your system will cause
|
|
some amount of CPU load and network traffic.
|
|
|
|
The bottom line is this: You DO NOT need to run named on your
|
|
Linux system. The SLS instructions will probably tell you to run
|
|
hostcvt.build to set up named. This is simply unnecessary, UNLESS
|
|
you want to make your Linux system a nameserver for some reason.
|
|
Now, instead of putting hostnames into the named database, you can
|
|
simply include them in the file /etc/hosts (section 4.3). When
|
|
looking up names, your Linux system will first look in /etc/hosts
|
|
and then ask the nameserver out on the net (if you have one).
|
|
|
|
The only reason you may want to run named would be if:
|
|
a) You're setting up a network of machines, and need a nameserver
|
|
for one of them (and don't have a nameserver out on the net
|
|
elsewhere);
|
|
b) Your network admins want you to run your Linux system as a
|
|
nameserver for some reason; or,
|
|
c) You have a slow SLIP connection, and want to run a small
|
|
cache-only nameserver on your Linux machine so that you don't
|
|
have to go out on the phone line every time a name lookup
|
|
occurs. (If you are only going to lookup a small number of
|
|
machine names, and you know what they are, you can put their
|
|
addresses in /etc/hosts instead.) Generally name lookup isn't
|
|
that slow, and should work fine over most SLIP connections.
|
|
d) You want to run a nameserver for fun and excitement.
|
|
|
|
In general, you DO NOT need to run named: this means that you
|
|
can comment it out from rc.inet2, and you don't have to run
|
|
hostcvt.build. If you want to alias machines, for example you want
|
|
to refer to "loomer.vpizza.com" just as "loomer", you can add an
|
|
alias in /etc/hosts instead. There is no reason to run named unless
|
|
you truly want a full nameserver on your machine. If you already
|
|
have a nameserver (most machines on the Internet do, and your net
|
|
admins will tell you its address), don't bother running named.
|
|
|
|
If you're only using loopback, you can run named and set your
|
|
nameserver address to 127.0.0.1, but that's pointless. (No pun
|
|
intended.) You don't need a nameserver at all if you use only
|
|
loopback; the only hostname you know is your own, and it's in
|
|
/etc/hosts (see section 4.3, below).
|
|
|
|
Have I mentioned Olafs Network Administration Guide as described
|
|
in section 0.3 (Related Documentation) yet ??
|
|
|
|
4.3 /etc/hosts
|
|
|
|
/etc/hosts contains a list of IP addresses and the hostnames they
|
|
map to. In this way, you can refer to other machines on the network
|
|
by name, as well as by IP address. Using a nameserver (see section 4.1)
|
|
also allows you to do the name->IP address translation automatically.
|
|
(Running named allows you to run your own nameserver on your Linux
|
|
box. See section 4.2.2.1 above.)
|
|
|
|
This file needs to contain at least an entry for 127.0.0.1 with
|
|
the name "localhost". If you're not only using loopback, you need
|
|
to contain an antry for your IP address, with your full hostname
|
|
(such as loomer.vpizza.com). You may also wish to include entries
|
|
for your gateway and network addresses.
|
|
|
|
For example, if "loomer.vpizza.com" has the IP address
|
|
"128.253.154.32", my /etc/hosts file would look like:
|
|
|
|
# /etc/hosts: List of hostnames and IP addresses
|
|
127.0.0.1 localhost
|
|
128.253.154.32 loomer.vpizza.com loomer
|
|
# end of hosts
|
|
|
|
Once again, edit this for your own needs. If you're only using
|
|
loopback, the only line in /etc/hosts should be for 127.0.0.1, with
|
|
both "localhost" and your hostname after it.
|
|
|
|
Note that in the second line, above, there are two names for
|
|
128.253.154.32: "loomer.vpizza.com" and just "loomer". The first name
|
|
is the full hostname of the machine. The second is an alias---it
|
|
allows me to just use "rlogin loomer" without having to type in the
|
|
entire name.
|
|
|
|
4.3.1 Important note regarding /etc/hosts from NET-032.
|
|
|
|
If you using the hosts file that came with NET-032, then:
|
|
The line "%%IP%% %%HOST%% %%ALIAS%%" needs to be deleted from
|
|
this file! This is a "tag" line used by Fred's experimental net
|
|
config scripts. Matt Welsh is now writing a new set of scripts which
|
|
don't use these lines. In any of these files, you see curious lines
|
|
with entries such as "%%NAME%%", these lines MUST be deleted. If you
|
|
don't delete them, you may have lots of strange errors and overflowing
|
|
syslog files.
|
|
|
|
4.4 /etc/networks
|
|
|
|
The /etc/networks file lists the names and addresses of your own,
|
|
and other, networks. It is used by the route command, and allows
|
|
you to specify a network by name, should you so desire.
|
|
|
|
NOTE: Every network you wish to add a route to using the 'route'
|
|
command MUST have an entry in /etc/networks
|
|
|
|
Its format is similar to that of the /etc/hosts file, (Sec 4.3)
|
|
and an example one might look like:
|
|
|
|
#
|
|
# /etc/networks: list all networks that you wish to add route commands
|
|
# for in here
|
|
#
|
|
default 0.0.0.0 # default route - mandatory
|
|
loopnet 127.0.0.0 # loopback network - mandatory
|
|
mynet 128.253.154.0 # Example network CHANGE to YOURS
|
|
#
|
|
# end of networks
|
|
|
|
|
|
4.5 /etc/host.conf
|
|
|
|
The system has some library functions called the resolver library.
|
|
This file specifies how your system will lookup host names. It should
|
|
contain the two lines:
|
|
|
|
order hosts,bind
|
|
multi on
|
|
|
|
These two lines tell the resolve libraries to first check the
|
|
/etc/hosts file for any names to lookup, and then ask the nameserver
|
|
(if one is present). The "multi" entry allows you to have multiple
|
|
IP addresses for a given machine name in /etc/hosts.
|
|
|
|
This file comes from the implementation of the resolv+ bind
|
|
library for Linux. You can find further documentation in the
|
|
resolv+(8) man page (if you have the man page available).
|
|
|
|
If you don't, they are available from:
|
|
Site: src.doc.ic.ac.uk [146.169.2.1]
|
|
Directory: /computing/comms/tcpip/nameserver/resolv+
|
|
File: resolv+2.1.1.tar.Z
|
|
|
|
This file contains resolv+.8, which is the man page for the
|
|
resolver library.
|
|
|
|
4.6 /etc/resolv.conf
|
|
|
|
This file actually configures the system name resolver.
|
|
This file contains two types of entries: The addresses of your
|
|
nameservers (if any), and the name of your domain (if you have one).
|
|
If you're running your own nameserver (i.e., you're running named
|
|
on your Linux machine: see section 4.2.2.1), then the address of
|
|
your nameserver is just 127.0.0.1 (the loopback address).
|
|
|
|
Your domain name is your fully-qualified hostname (if you're a
|
|
registered machine on the Internet, for example), with the hostname
|
|
chopped off. That is, if your full hostname is loomer.vpizza.com,
|
|
your domain name is just "vpizza.com", without the hostname ("loomer").
|
|
|
|
For example, if your machine is goober.norelco.com, and has a
|
|
nameserver at the address 128.253.154.5, your /etc/resolv.conf would
|
|
look like:
|
|
|
|
domain norelco.com
|
|
nameserver 127.253.154.5
|
|
|
|
You can specify more than one nameserver. Each one
|
|
must have a "nameserver" line of its own in resolv.conf.
|
|
|
|
If you're only using loopback, you don't need a nameserver.
|
|
|
|
4.7 /etc/HOSTNAME
|
|
|
|
This is a new file; it contains the full hostname of your machine
|
|
(with the domain name). It is used by the 'hostname' command, to
|
|
saveyou having to supply the hostname as an argument. For example,
|
|
the machine above would have the file /etc/HOSTNAME:
|
|
|
|
goober.norelco.com
|
|
|
|
That's all.
|
|
|
|
4.8 /etc/rc.local
|
|
|
|
Change the line in /etc/rc.local (or /etc/rc, depending on your
|
|
setup) which sets your system's hostname, to
|
|
|
|
/bin/hostname -S
|
|
|
|
(You have a new hostname in /bin.) This sets your hostname from
|
|
the name found in /etc/HOSTNAME. If you don't like this (personally
|
|
I don't), just do:
|
|
/bin/hostname -S <your-hostname>
|
|
|
|
For example,
|
|
/bin/hostname -S loomer.vpizza.com
|
|
|
|
It IS important that you give a full hostname (with domain name)
|
|
in /etc/HOSTNAME. This allows the hostname command to set the
|
|
host AND domainname in one shot.
|
|
|
|
IMPORTANT: The hostname found in /etc/HOSTNAME *must* be a valid
|
|
hostname. This means that it must be found in /etc/hosts (or that
|
|
your nameserver must be able to resolve it, but you should put it
|
|
in /etc/hosts in case your nameserver is down).
|
|
|
|
4.9 Other files.
|
|
|
|
There are of course many other files in /etc which you may need to
|
|
dabble with later on. Instead of going into them here, I'm going to
|
|
provide the bare minimum to get you on the net. More information will
|
|
be provided in later versions of the NET-2 HOWTO.
|
|
|
|
Once you have all of the files set up, and everything in the
|
|
right place, you should be able to reboot your new kernel and
|
|
net away to your heart's content. However, I strongly suggest
|
|
that you keep a bootable copy of your old kernel and even possibly
|
|
a "recovery disk" (say, the SLS a1 disk, or HJLu's single disk
|
|
boot disk) in case you hosed your /etc/rc files, for example,
|
|
and can't login when you boot.
|
|
|
|
|
|
5. Configuring SLIP.
|
|
|
|
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 asynchronous line of some sort. Of course, to use SLIP you'll
|
|
need access to a dial-in SLIP server 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 is must take control of the serial device. Slip devices
|
|
are named 'sl0', 'sl1' etc, how do these correspond to your serial
|
|
devices ? The networking code uses what is called an IOCTL (I/O
|
|
control) call to change the serial devices into slip devices. There
|
|
are two programs supplied that can do this, they are 'dip' and
|
|
'slattach'.
|
|
|
|
'dip' (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 machine, search for
|
|
messages sent to you and extract information from them such as your
|
|
IP address, and perform the IOCTL to change the serial device over
|
|
to a slip device.
|
|
|
|
'slattach' on the other hand does very little other than set the
|
|
serial device speed and perform the IOCTL to convert it to a slip
|
|
device.
|
|
|
|
When do you use which ? You would use dip when your link to the
|
|
machine that is your slip server is a dialup modem, or some other
|
|
temporary link. You would use 'slattach' when you have a leased
|
|
line, perhaps a cable, between two machines, and there is no special
|
|
action needed to get the link working. See section 5.4 for more
|
|
information.
|
|
|
|
Configuring SLIP is much like configuring an Ethernet interface
|
|
(please read section 4.0 above). However, there are a few key
|
|
differences.
|
|
|
|
First of all, slip links are unlike an Ethernet network in that
|
|
there are only ever two hosts on the network, one at each end.
|
|
Unlike an ethernet that is available for use as soon as you are
|
|
cabled, with slip, depending on the type of link you have, you
|
|
may have to command your modem to establish the connection to
|
|
the remote modem. Dialing in and connecting to your SLIP server is
|
|
usually done at boot time, usually by a program called "dip"
|
|
(found in the "dip" subdir of the net-032 package). "Dip" not only
|
|
dials and logs you into the SLIP server, but it also initiates the
|
|
SLIP connection and runs the appropriate ifconfig and route commands
|
|
to initialize the device. Therefore, the only lines needed in
|
|
/etc/rc.d/rc.inet1 are the few commands to initilize the loopback
|
|
connection at the top (see section 4.2.1 above).
|
|
|
|
If you're not using DIP, you may indeed have to edit rc.inet1 for
|
|
your SLIP parameters.
|
|
|
|
Also, there are two types of SLIP servers: Dynamic IP address
|
|
servers and static IP address servers. Dynamic servers allocate
|
|
a new, different IP address to you every time you dialin and
|
|
initiate a connection. Static servers give you the same address
|
|
every time. Almost every SLIP server will also prompt you for
|
|
a username and password when dialing in: DIP can handle logging
|
|
you in automatically.
|
|
|
|
Essentially, configuring a SLIP connection is just like configuring
|
|
for loopback or ethernet. The main differences are discussed below.
|
|
Read section 4.0 above for information on configuring your TCP/IP
|
|
files, and apply the changes below.
|
|
|
|
5.1 Static SLIP server connections using a dialup line.
|
|
|
|
If you have a static-allocation server (same IP address every time),
|
|
then you may want to put entries for your hostname and IP address
|
|
(since you know what your IP address is!) in /etc/hosts. You should
|
|
also configure the other files listed in section 4.0: rc.inet2,
|
|
host.conf, resolv.conf, /etc/HOSTNAME, and rc.local). Remember that
|
|
when configuring rc.inet1, you don't need to run the ifconfig and
|
|
route commands other than the two for the loopback interface (if
|
|
you're using DIP to dial your connection).
|
|
|
|
In general, your gateway is the IP address of your SLIP server.
|
|
Because DIP handles the configuration of the route, you probably
|
|
don't need to know this, but in some cases you might have to run the
|
|
appropriate ifconfig or route commands in /etc/rc.d/rc.inet1 to
|
|
get it to work correctly. Instead of using "eth0" as your interface
|
|
name, SLIP connections use "sl0". Keep in mind that you can't
|
|
ifconfig sl0 until you have dialed the connection and connected to
|
|
the SLIP server.
|
|
|
|
Also, you may need to use the "pointopoint" argument to ifconfig if
|
|
DIP does not do it correctly. For example, if your SLIP server's
|
|
address is 44.136.8.5, and your IP address is 128.253.154.32, you may
|
|
need to run the command
|
|
|
|
# /etc/ifconfig sl0 128.253.154.32 pointopoint 44.136.8.5
|
|
|
|
See the man pages for ifconfig in the net-032 package.
|
|
|
|
5.2 Static SLIP server connections using a leased line or cable.
|
|
|
|
If you have a leased line, or cable to your slip server, then you
|
|
do not need to worry with the hassle of causing your modem to
|
|
dial and establish the connection. In this situation the 'slattach'
|
|
program is the best solution for configuring your SLIP link.
|
|
|
|
I can think of no better way of describing the process than by
|
|
illustration. In your rc.inet1 file you would have something similar
|
|
to the following:
|
|
|
|
# Portion of /etc/rc.d/rc.inet1 for leased line static slip connection
|
|
#!/bin/sh
|
|
IPADDR="128.253.154.32" # REPLACE with YOUR IP address!
|
|
REMADDR="128.253.154.33" # REPLACE with YOUR OTHER SLIP servers address!
|
|
|
|
slattach -p cslip -s 19200 /dev/ttyS0
|
|
/etc/ifconfig sl0 $IPADDR pointopoint $REMADDR up
|
|
/etc/route add default gw $REMADDR
|
|
|
|
# End
|
|
|
|
slattach allocates the first unallocated slip device to the serial
|
|
device specified. slattach starts with 'sl0'. Therefore the first
|
|
slattach command attaches slip device 'sl0' to the serial device
|
|
specified, 'sl1' the next time etc.
|
|
|
|
Note also that the first parameter that slattach accepts is one to
|
|
specify the protocol. At present the only working values are
|
|
'slip', and 'cslip'. 'cslip' is compressed slip, it is the same
|
|
slip, except that the datagrams headers have been compressed to
|
|
reduce overhead on the link. On good clean links this is recommended.
|
|
In future protocols such as PPP, and KISS (for Amateur Radio use)
|
|
will be offered.
|
|
|
|
After you have 'slattached' the interface, you can now configure
|
|
it with ifconfig as you would an ethernet interface, but since
|
|
there is only one other machine that you can talk to directly via
|
|
the link you do not need to worry about netmasks and the like.
|
|
Normally you would point your default route to the slip interface,
|
|
as it is your connection to every other machine. The pointopoint
|
|
parameter should automatically add a route to the machine at the
|
|
other end of the link. Its primary function is to tell your machine
|
|
that there are no other hosts on that network interface.
|
|
|
|
If you have more than one slip interface then you will have routing
|
|
considerations to make. You will have to decide what routes to
|
|
add, and those decisions can only be made on the basis of the
|
|
actual layout of your network connections.
|
|
|
|
5.3 Dynamic SLIP server connections using a dialup line.
|
|
|
|
If your SLIP server allocates a new IP address to you every time
|
|
you dialin, you don't know your IP address at all, so you can't
|
|
include an entry in /etc/hosts for your machine. (If you want, you
|
|
can place your hostname in /etc/hosts with the address 127.0.0.1).
|
|
|
|
Most dynamic SLIP servers tell you your IP address when you initiate
|
|
the connection. For example, it may print a string such as, "Your IP
|
|
address is 128.253.154.10. Server address is 128.253.154.1." DIP will
|
|
need to know these numbers when it configures the connection. See
|
|
section 5.3 below on using DIP.
|
|
|
|
If you use DIP, it does all of the work of configuring the
|
|
connection when you dialin, so rc.inet1 only needs the two lines
|
|
to configure the loopback address (see section 4.2.1 above).
|
|
Also, see section 5.1 above. You need to configure all of
|
|
the files listed in section 4.0. Your gateway address (should you
|
|
need to know it) will be the address of the SLIP server. Also,
|
|
you may need to run ifconfig on sl0 using the SLIP server's address
|
|
as the "pointopoint" argument (see section 5.1 above). However, if
|
|
you use DIP, it should be able to do all of the ifconfig and route
|
|
commands for you.
|
|
|
|
One good way to figure out how to configure SLIP on your machine is
|
|
to find someone else who uses the SLIP server (it can be on a PC,
|
|
Mac, UNIX box, whatever) and find out what numbers they use.
|
|
|
|
|
|
5.4 Using DIP.
|
|
|
|
DIP can simplify the process of dialing into the SLIP server, logging
|
|
in, starting the connection, and configuring the sl0 device with
|
|
the appropriate ifconfig and route commands.
|
|
|
|
Essentially, to use DIP you'll write a "chat script" which is
|
|
basically a list of commands to send to DIP along with commands for
|
|
logging in, starting the connection, and so on. See "sample.dip"
|
|
in the net-032 package for an explanation. DIP is quite a powerful
|
|
program, with many options. Instead of going into all of them here
|
|
you should look at the READMEs and the sample files from tsx-11 and
|
|
the net-032 distribution.
|
|
|
|
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 version of dip include a command
|
|
you can use to automatically read and configure your interface
|
|
with the address printed by your server. The following sample was
|
|
contributed by Paul Mossip, and is probably a good starting point
|
|
for you:
|
|
|
|
|
|
#
|
|
# Connection script for SLIP to knoware.nl.mugnet.org
|
|
#
|
|
|
|
# Fetch the IP address of our target host.
|
|
main:
|
|
|
|
# Set the desired serial port and speed.
|
|
port /dev/cua0
|
|
speed 38400
|
|
|
|
# Reset the modem and terminal line.
|
|
reset
|
|
|
|
# Prepare for dialing.
|
|
send ATZ1\r
|
|
wait OK 4
|
|
if $errlvl != 0 goto error
|
|
dial 666-0999 ## Change to your servers number!
|
|
if $errlvl != 0 goto error
|
|
wait CONNECT 60
|
|
if $errlvl != 0 goto error
|
|
|
|
# We are connected. Login to the system.
|
|
login:
|
|
sleep 3
|
|
send \r\n\r\n
|
|
wait gracelands> 20 ## Change to your servers prompt
|
|
if $errlvl != 0 goto error
|
|
send login\n
|
|
wait name: 10 ## Wait username: prompt
|
|
if $errlvl != 0 goto erro
|
|
send elvisp\n ## Change to your own!
|
|
wait ord: 10 ## Wait password prompt
|
|
if $errlvl != 0 goto error
|
|
send alive\n ## Change to your own!
|
|
wait gracelands> 10
|
|
if $errlvl != 0 goto error
|
|
send slip\n ## Change to suit your server
|
|
wait SLIP 30 ### Wait for SLIP prompt
|
|
if $errlvl != 0 goto error
|
|
get $local remote 10 ## Assumes the server sends your IP..
|
|
if $errlvl != 0 goto error ## address as soon as you enter slip.
|
|
get $remote gracelands ## slip server address from /etc/hosts
|
|
done:
|
|
print CONNECTED to $remote with address $rmtip we are $local
|
|
default
|
|
mode SLIP
|
|
goto exit
|
|
error:
|
|
print SLIP to $host failed.
|
|
exit:
|
|
#
|
|
# End dip script
|
|
|
|
|
|
The example above will automatically point your 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 'default'
|
|
command.
|
|
|
|
The above example is fairly robust. Please refer to the 'dip' man
|
|
page for more information.
|
|
|
|
It should be simple to modify the code for DIP in the file attach.c
|
|
to run the route and ifconfig commands that work for you automatically.
|
|
|
|
5.5 Configuring your Linux Machine as a SLIP Server.
|
|
|
|
Note: Some of the information below came from the dip man pages,
|
|
where in fact how to run Linux as a slip server is briefly documented.
|
|
|
|
To configure Linux as a slip server, you need to create Special
|
|
slip accounts for users, where dip (in slave mode) is used as the
|
|
login shell. Fred suggests that he has a convention of having all
|
|
of his Slip accounts begin with a capital 'S', eg "Sfredm".
|
|
|
|
Because the login program won't accept arguments to the login shell,
|
|
you will need to create a small program that looks like the following:
|
|
|
|
/* dip-i.c - from a mail message of Karl kkeyte@esoc.bitnet */
|
|
int main()
|
|
{
|
|
execlp("dip", "dip", "-i", (char *) 0);
|
|
}
|
|
|
|
Compile it with: 'gcc -O dip-i.c -o dip-i'
|
|
|
|
Give it permissions 555. I recommend calling it /usr/bin/dip-i as
|
|
shown below.
|
|
|
|
A sample /etc/passwd entry for a Slip user looks like:
|
|
|
|
Sfredm:ij/SMxiTlGVCo:1004:10:UUNET:/tmp:/usr/bin/dip-i
|
|
^^ ^^ ^^ ^^ ^^ ^^ ^^
|
|
| | | | | | \__ shell program running
|
|
| | | | | | dip -i 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 login(1) program, if it finds and
|
|
verifies the user ok, will execute the shell program 'dip-i' which
|
|
will execute dip command in input mode (-i). Dip now scans the
|
|
/etc/net/diphosts file for an entry for the given user name.
|
|
Therefore, each slip user must also have an entry in
|
|
/etc/net/diphosts.
|
|
|
|
|
|
5.6 /etc/net/diphosts
|
|
|
|
/etc/net/diphosts is used by dip 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/net/diphosts is as follows:
|
|
|
|
Suwalt::145.71.34.1:SLIP uwalt:CSLIP,1006
|
|
^ ^ ^ ^ ^ ^
|
|
| | | | | \___ MTU
|
|
| | | | \_________ protocol (SLIP, CSLIP,
|
|
| | | | KISS, PPP)
|
|
| | | \___________________ comment field ("gecos" :-)
|
|
| | \________________________________ IP address of the other
|
|
| | side, or host.domain.name
|
|
| \___________________________________ unused (compat. with passwd)
|
|
\________________________________________ login name (as returned by
|
|
getpwuid(getuid()) )
|
|
|
|
|
|
An example /etc/net/diphosts entry for a remote slip user might be:
|
|
|
|
Sfredm::145.71.34.1:SLIP uwalt:SLIP,296
|
|
which specifies a SLIP link with MTU==296, or
|
|
|
|
Sfredm::145.71.34.1:SLIP uwalt:CSLIP,1006
|
|
which specifies a CSLIP-capable link with MTU of 1006.
|
|
|
|
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 they check out ok, then the user will
|
|
see no special messages, they should just change into slip mode
|
|
at their end, and then they should be able to connect ok, and be
|
|
configured with the paramters from the diphosts file.
|
|
|
|
5.7 Configuring PLIP interfaces.
|
|
|
|
PLIP is like SLIP, in that it is used for providing point to point
|
|
IP links between machines, except that it is designed to use the
|
|
Parallel ports on your machine instead of the serial ports. Because
|
|
it is possible to transfer more than one bit at a time with the
|
|
Parallel port, it is possible to attain higher speeds with the
|
|
plip interface than with the serial interface. In addition, even
|
|
the simplest of parallel ports, printer ports, can be used, in
|
|
lieu of you having to purchase conmparatively expensive 16550AFN
|
|
UARTs for your serial ports.
|
|
|
|
When compiling the kernel, there is only one file that might need
|
|
to be looked at. That file is net/drv/plip/global.h, and it contains
|
|
timers in mS. The defaults are probably going to be fine, unless you
|
|
have an especially slow computer, in which case you might have to
|
|
increase them on the machine at the other end of the link.
|
|
|
|
A sample configuration for a plip interface might be:
|
|
|
|
#!/bin/sh
|
|
# Portion of /etc/rc.d/rc.inet1 for PLIP connection to local machine
|
|
|
|
IPADDR='192.148.64.1' # Replace with YOUR IP Address
|
|
REMADDR='212.194.167.1' # Replace with the address of YOUR OTHER HOST
|
|
|
|
ifconfig pl0 $IPADDR pointopoint $REMADDR up # Configure PLIP interface
|
|
route add default gw $REMADDR # Route to other machine.
|
|
|
|
# End
|
|
|
|
The pointopoint parameter has the same meaning as for SLIP, in
|
|
that it specifies the address of the machine at the other end of
|
|
the link.
|
|
|
|
In almost all respects, you can treat a plip interface as though
|
|
it were a slip interface, except that neither 'dip' nor 'slattach'
|
|
can be, or are used.
|
|
|
|
5.7.1 PLIP Cabling Diagram.
|
|
|
|
PLIP has been designed to use cables with the same pinout as those
|
|
commonly used by the better known of the dos based pc-pc file transfer
|
|
programs. The pinout diagram (taken from net/drv/plip/README) looks as
|
|
follows:
|
|
|
|
Pin Name Connect pin - pin:
|
|
-------------- ----------------------
|
|
GROUND 25 - 25
|
|
D0->ERROR 2 - 15 15 - 2
|
|
D1->SLCT 3 - 13 13 - 3
|
|
D2->PAPOUT 4 - 12 12 - 4
|
|
D3->ACK 5 - 10 10 - 5
|
|
D4->BUSY 6 - 11 11 - 6
|
|
D5 7*
|
|
D6 8*
|
|
D7 9*
|
|
STROBE output 1*
|
|
AUTOFD output 14*
|
|
INIT output 16*
|
|
SLCTIN output 17*
|
|
|
|
Do not connect the pins marked with an asterisk (`*'). They are
|
|
D5 (pin 7), D6 (pin 8) and D7 (pin 9). STROBE is pin 1, FEED is
|
|
pin 14.
|
|
|
|
Extra grounds are on pins 18, 19, 20, 21, 22, 23 and 24.
|
|
|
|
If the cable you are using has a metallic shield it should be
|
|
connected to the metallic DB-25 shell at one end only.
|
|
|
|
6. PPP (Under construction).
|
|
|
|
There is now some ALPHA PPP software available. For the latest
|
|
information relating to it, join the PPP channel on the niksula.hut.fi
|
|
list server, and keep your eye on comp.os.linux.development.
|
|
Already there have been some encouringly good reports for it.
|
|
|
|
The PPP software comes in two parts. Some kernel modifications, and
|
|
the ppp daemon. They are available at the following locations:
|
|
|
|
ftp://ftp.gang.umass.edu/user/michael/linux-ppp-0.1.5.tgz
|
|
ftp://ftp.gang.umass.edu/user/michael/pppd-0.1.4.tgz
|
|
|
|
Please check that there isn't a later version there, and be
|
|
sure to read any README files or the like that are there as
|
|
well, as they will tell you how to install, where to report
|
|
bugs and the like.
|
|
|
|
7. AX.25 (Under construction).
|
|
|
|
Alan Cox has some experimental AX.25 code available for testing.
|
|
|
|
8. Are You Stuck ?
|
|
|
|
Really ? Then you should read the man pages for ifconfig and route,
|
|
included in the net-032 package, and understand their functions. These
|
|
commands have a lot of flexibility, and because everyone's network
|
|
setup is different, you may find a way to use ifconfig and route to
|
|
get your connection working. If you do, feel free to send me some mail
|
|
so I can include it in the next update of the NET-2 HOWTO. Because of
|
|
my limited amount of experimental data, most of the discussion above
|
|
is about my own setup, and I'd like to generalize it as much as
|
|
possible.
|
|
|
|
Matt is currently writing a set of scripts to simplify NET-2
|
|
configuration. You can pick up the pre-alpha release from
|
|
tc.cornell.edu, in the file /pub/mdw/netconf-0.3.tar.z. These scripts
|
|
maintain a small database of network configuration info, and allow you
|
|
to easily modify and configure your network interface. The scripts are
|
|
far from complete: Matt has been waiting until the NET-2 interface
|
|
itself stabilizes a bit more before upgrading it further.
|
|
|
|
Another good place to look for help on setting up NET-2 is the
|
|
O'Reilly and Associated book 'TCP/IP Network Administration',
|
|
the one with the crab on the cover. Keep in mind that NET-2 is now
|
|
a "standard" implementation of TCP/IP, this means that ifconfig
|
|
and route work the same under Linux as they do on other UNIX systems.
|
|
Keep also in mind that some of the arguments and options may differ
|
|
slightly from those in the book.
|
|
|
|
You might also search out the following documents which are an
|
|
excellent source of tutorial information on tcp/ip:
|
|
|
|
athos.rutgers.edu:/runet
|
|
-rw-r--r-- 1 0 0 176218 Oct 20 1989 tcp-ip-admin.doc
|
|
-rw-r--r-- 1 0 0 214199 Oct 20 1989 tcp-ip-admin.ps
|
|
-rw-r--r-- 1 0 0 92106 Oct 20 1989 tcp-ip-intro.doc
|
|
-rw-r--r-- 1 0 0 111478 Oct 20 1989 tcp-ip-intro.ps
|
|
|
|
Also keep in mind that NET-2 _is_ developing very rapidly, it's
|
|
one of the newest additions to the Linux kernel. Thus, all of the
|
|
bugs haven't been worked out yet, so there may be some problems.
|
|
However, a good rule of thumb is that if you were able to get TCP/IP
|
|
working under kernels before 0.99.pl10, you should be able to get it
|
|
working under NET-2 as well. There are still some issues dealing with
|
|
performance to be fixed, but overall the system works. And, as with
|
|
everything in Linux development, time will cure what ails NET-2.
|
|
If it's absolutely unusable to you, go back to an earlier kernel
|
|
version, and wait until things develop further. The code is still
|
|
fairly new.
|
|
|
|
9. Common Problems and Solutions.
|
|
|
|
Now that the NET-2 HOWTO has been out for a while, I've been
|
|
able to gather some common problems (and answers!). Here are
|
|
some things which I have learned from hearing from readers.
|
|
If you run into a problem which should be included here,
|
|
please send it along (even if you have the solution!).
|
|
|
|
QUESTION: How do I know what version of NET software I am running?
|
|
|
|
ANSWER: In the kernel messages when you boot your machine, you should
|
|
see a line that describes your networking code. For example, mine
|
|
looks like:
|
|
|
|
Linux version 0.99.14l+NET-2EB4 (root@albert.vk2ktj.ampr.org.)
|
|
|
|
This line, not terribly obviously, tells you that I am running
|
|
NET-2E, Beta 4.
|
|
|
|
QUESTION: When I try to use the network, or use SLIP, I get the
|
|
error message "Network not reachable". What should I do?
|
|
|
|
|
|
ANSWER: This message means that a machine somewhere in the path did
|
|
not have a route to the destination network. Until you can demonstrate
|
|
otherwise, it is the courteous thing to do, assume it is your
|
|
machine. This is usually an indication that either your ifconfig or
|
|
route commands are in some way wrong. You can look at the status of
|
|
your ifconfig by using the command "ifconfig" by itself. This should
|
|
tell you what NET-2 thinks your IP address, netmask, etc. are.
|
|
You can use the command "route" by itself to get routing information.
|
|
This will tell you what routes you have set up and what gateways
|
|
(if any).
|
|
|
|
The best way to test a SLIP or network connection is to use "ping"
|
|
with IP addresses only. If you use hostnames, as in "ping loomer",
|
|
if some part of name lookup isn't working you'll have trouble.
|
|
To test just the network, NOT name lookup, use only IP addresses,
|
|
as in "ping 128.253.154.32".
|
|
|
|
For SLIP connections the best thing to do is to ping your
|
|
SLIP server. If nothing comes back, then something is wrong with your
|
|
slip port configuration, double check all of the steps detailed above.
|
|
Try using "dip -v" which will print debugging information while DIP
|
|
is dialing the server.
|
|
|
|
If you get a response from your slip server, but not from anywhere else,
|
|
then you are probably missing your default route, you may need to use
|
|
the commands:
|
|
|
|
# route del <your slip server address>
|
|
# route add default gw <your slip server address>
|
|
|
|
to get SLIP talking to the server. Once you can talk to the
|
|
server, everything SHOULD work (if your server is set up correctly!).
|
|
|
|
For Ethernet connections, try pinging your gateway. If you can talk
|
|
to your gateway, you should be able to talk to the outside world.
|
|
You may need more than one route (that is, more than one gateway).
|
|
For example, some universities use one gateway for on-campus
|
|
networks and another for off-campus networks.
|
|
|
|
Either way, try pinging addresses on your local network, and remote
|
|
addresses. If you can ping all addresses ok remote to your network,
|
|
and some on your local network, but not others on your local network,
|
|
then check your netmask setting.
|
|
|
|
If the "network not reachable" message means that you can't
|
|
talk to your gateway. This can be due to several things:
|
|
|
|
a) Wrong route or ifconfig commands
|
|
b) Ethernet card problems (see below)
|
|
c) You didn't compile the kernel correctly (see below).
|
|
d) There is in fact some sort of network failure elsewhere.
|
|
|
|
|
|
QUESTION: I keep getting the error "eth0: transmit timed out".
|
|
What does this mean?
|
|
|
|
ANSWER: This usually means that your Ethernet cable is unplugged,
|
|
or that the setup parameters for your card (I/O address, IRQ, etc.)
|
|
are not set correctly. Check the messages at boot time and make
|
|
sure that your card is recognized with the correct Ethernet address.
|
|
If it is, check that there is no conflict with any other hardware
|
|
in your machine, eg you might have a soundblaster sharing the same
|
|
IRQ or i/o control port.
|
|
|
|
QUESTION: I get errors "check Ethernet cable" when using the network.
|
|
|
|
ANSWER: You probably have your Ethernet card configured incorrectly.
|
|
For Etherlink cards, in the file /usr/src/linux/driver/net/CONFIG,
|
|
change the line
|
|
EL_OPTS = -UEL2_AUI
|
|
to
|
|
EL_OPTS = -DEL2_AUI
|
|
|
|
This tells the card to use the AUI cable interface.
|
|
Just make sure that all of the options for your card are set
|
|
correctly in the CONFIG file, and rebuild your kernel.
|
|
|
|
|
|
QUESTION: When I use NET-2, I get a "General protection" error
|
|
or a panic from the kernel. How can I fix this?
|
|
|
|
ANSWER: Remember that the NET-2 code is still on the buggy side,
|
|
just because it's in mid-development. If you get a kernel panic
|
|
while using NET-2, write down the EIP address (and the other
|
|
information given in the panic message). The EIP is the address
|
|
where the kernel paniced, usually of the form 0008:xxxxxxxx
|
|
where "0008" is the segment descriptor for the kernel text, and
|
|
"xxxxxxxx" is the offset into that segment (80386 programmers will
|
|
know what this means).
|
|
|
|
Use the command
|
|
nm /usr/src/linux/tools/system | sort -n
|
|
or
|
|
nm /usr/src/linux/tools/zSystem | sort -n
|
|
|
|
depending on whether or not you use a compressed kernel (zImage).
|
|
This will print a listing of all symbols in the kernel text,
|
|
simply scan down the list and look for the function that contains
|
|
the EIP address in the kernel dump. There's the culprit.
|
|
|
|
However, in some cases the EIP can be misleading; the kernel
|
|
may panic at a place which is complete irrelevant to where the
|
|
actual problem occurred. However, it is a good starting place;
|
|
first, locate the function which contains the EIP address, and
|
|
then check out the kernel code to see what might be wrong.
|
|
|
|
Keep in mind that this will only work if you compile your own
|
|
kernel and have the "system" file associated with it.
|
|
|
|
|
|
QUESTION: How can I hang up the phone line when I'm done using
|
|
SLIP?
|
|
|
|
ANSWER: If you use dip to dial out on the SLIP line, just
|
|
"kill -9" the dip process itself (dip won't die unless you kill
|
|
it with SIGKILL or some other signal). When dip dies, the line
|
|
should hang up. DIPs behaviour is being modified so that it will
|
|
be more sociable and die when it is supposed to. If you are using
|
|
the new dip, then 'dip -k' will kill any copy of dip that you
|
|
have running, and hang up the line as well.
|
|
|
|
If you don't use dip to dial out, either instruct your dialing
|
|
program to hang up the line, or kill the dialing process.
|
|
|
|
|
|
QUESTION: dip doesn't work. How do I make it work ?
|
|
|
|
ANSWER: Check that the file permissions of dip are 6750, that is
|
|
'chmod 6750 dip'. Check also that dip is owned by root:
|
|
'chown root:dip dip'
|
|
|
|
|
|
QUESTION: With SLIP, I get a connection open, but no data flows.
|
|
|
|
ANSWER: This could be a number of things. First, check your routes
|
|
and be sure that the gateway is set correctly. Attempt to ping
|
|
your gateway; if you can't, then something is wrong with the routes.
|
|
|
|
Another problem could be that your system and the SLIP server
|
|
disagree about header compression. With 0.99.pl11 and above,
|
|
SLIP automatically compresses packet headers. To turn off header
|
|
compression, check the SL_COMPRESS option in the CONFIG file.
|
|
In pl14 there will be supplied a 'setencap' command to allow you
|
|
to configure compression.
|
|
|
|
|
|
QUESTION: With SLIP, I get a connection, but after sending a small
|
|
amount of data, the connection hangs.
|
|
|
|
ANSWER: Probably an MTU problem. The MTU is the maximum packet
|
|
size available for the network. For SLIP, your MTU is set in
|
|
your dip dialing script with the "MTU" command. The default value
|
|
is 1500, which means that the system can send packets of up to
|
|
1500 bytes in size. However, some SLIP servers (Berkeley SLIP,
|
|
for example), use a smaller MTU (around 1006).
|
|
|
|
Another thing to check if you are having erratic SLIP problems is
|
|
flow control. You need to use hardware (RTS/CTS) flow control
|
|
on your modem, and your modem and your computer must agree. XON/XOFF
|
|
flow control is not practical for SLIP.
|
|
|
|
9.1 Not so common problems and solutions (Mostly NFS).
|
|
|
|
QUESTION: How do I use my existing Novell fileserver with my
|
|
Linux machine ?
|
|
|
|
ANSWER: If you have the Novell NFS Daemon code then it is easy, just
|
|
NFS mount the Novell volume that you wish to use. If you don't, and
|
|
you are really desperate to be able to do this, and you have a spare
|
|
pc machine laying about, you are in luck. Here is what you do:
|
|
|
|
You configure the spare machine as a normal Novell workstation,
|
|
mapping the appropriate Fileserver directories to virtual drives
|
|
as you so desire. You then grab a copy of SOSS (Son Of Stans own
|
|
Server) from your nearest ftp site, and run it on the same workstation.
|
|
SOSS is an NFS server that will happily run on just about any pc.
|
|
This will allow you to NFS export the Novell network drives. It has
|
|
caveats in that it will not perform as well as directly mounting
|
|
the Novell fileserver, that it requires another machine, and that it
|
|
will generate roughly twice as much network traffic, but it will work.
|
|
|
|
Stan's Own Server (NFS server).
|
|
|
|
spdcc.com:pub/sos/soss.zoo
|
|
spdcc.com:pub/sos/sossexe.zoo
|
|
|
|
A version "couple of bugs fixed: IP numbers and subdirectories
|
|
with extensions)" is available from:
|
|
hilbert.wharton.upenn.edu:/pub/tcpip/soss.zip
|
|
|
|
QUESTION: Files get corrupted when using NFS over wider area networks
|
|
or SLIP, why ? How do I stop it ?
|
|
|
|
ANSWER: Certain vendors (Sun primarily) shipped many machines running
|
|
NFS without UDP checksums. Great on ethernet, suicide otherwise. UDP
|
|
checksums can be enabled on most file servers. Linux has it enabled by
|
|
default from pl13 onwards - but both ends need to have it enabled...
|
|
|
|
QUESTION: Why are my NFS files all read only ?
|
|
|
|
ANSWER: The Linux NFS server defaults to read only. RTFM the 'exports'
|
|
and nfsd manual pages. With non Linux servers you may also need to
|
|
alter /etc/exports
|
|
|
|
QUESTION: I mount from a linux nfs server and while ls works I can't
|
|
read or write files. How do I fix this ?
|
|
|
|
ANSWER: You must mount a Linux filestore with rsize=1024,wsize=1024
|
|
(or 2048 if you really want - 1024 is a better choice).
|
|
|
|
QUESTION: I mount from a linux nfs server with a blocksize of between
|
|
3500-4000 and it crashes the Linux box regularly, why ?
|
|
|
|
ANSWER: This is a known problem that is being worked on, refer to
|
|
previous question. Don't you hate answers like that ? :)
|
|
|
|
QUESTION: Can Linux do NFS over TCP ?
|
|
|
|
ANSWER: No. To do this would require someone to spend the time to
|
|
update the rpc code to add rpc stream record marking. It should work
|
|
then.
|
|
|
|
QUESTION: Why do I get loads of strange errors trying to mount a
|
|
machine from a Linux box.
|
|
|
|
ANSWER: This is possibly related to a restriction imposed by older
|
|
NFS servers. Make sure your users are in 8 groups or less.
|
|
|
|
QUESTION: Why are my Linux NFS clients very slow when writing to Sun
|
|
& BSD systems ?
|
|
|
|
ANSWER: NFS writes are normally synchronous, meaning that all file-
|
|
-system changes occur in the order they transmitted, this means that
|
|
if before NFS will allow you to write any more data, any previous
|
|
write must have already completed, (you can disable this if you don't
|
|
mind risking losing data). Worse still, BSD derived kernels, this
|
|
includes Sun systems, tend to be unable to work in small blocks. Thus
|
|
when you write 4K of data from a Linux box in the 1K packets it uses,
|
|
BSD does this:
|
|
|
|
read 4K page
|
|
alter 1K
|
|
write 4K back to physical disk
|
|
read 4K page
|
|
alter 1K
|
|
write 4K page back to physical disk
|
|
etc..
|
|
|
|
Better systems don't have this problem. The Linux client is however
|
|
quite slow anyway.
|
|
|
|
QUESTION: I've heard NFS is not secure is this true ?
|
|
|
|
ANSWER: Yes, totally. Running NFS in an uncontrolled environment is
|
|
rather like leaving your front door open, painting 'On holiday' on
|
|
your house and posting maps to every known criminal...
|
|
In a fairly secure environment or when you can recover data from stupid
|
|
misuse its pretty much OK. The worst someone can easily do is alter all
|
|
the files on an NFS mounted disk, and/or crash the machine. So long as
|
|
you don't mount your system files writable you should be mostly safe.
|
|
|
|
QUESTION: I occasionally mount from lots of different places, do I have
|
|
to mount them all each time I boot ?
|
|
|
|
ANSWER: No you can use the automounter to mount disks as you access
|
|
them.
|
|
|
|
QUESTION: How do I stop things hanging when a server goes down ?
|
|
|
|
ANSWER: There are three main NFS behaviours:
|
|
|
|
soft: Your NFS client will report an error to the process
|
|
concerned if an NFS server doesn't answer after a few
|
|
retries. Most software handles this well - but not all.
|
|
|
|
hard: Your NFS client will try forever unless killed off.
|
|
Operations will be restarted when the NFS server
|
|
recovers or reboots.
|
|
|
|
hard,intr: As hard but ^C will also stop the NFS retrying. In
|
|
a few cases, notably nfs mounted /usr/spool/mail disks,
|
|
this doesn't help as the shell will be ignoring ^C when
|
|
it checks you have mail.
|
|
|
|
If you intend to leave your machine unattended, then choosing the
|
|
'soft' option is probably best, because while it might cause some
|
|
problems to an application running, it won't halt your whole machine
|
|
if a server that it is attached to goes down. If your machine will
|
|
always have a human operator available, then the 'hard,intr' option
|
|
might be best. The hard option would be best suited to you if you can
|
|
afford to wait, and don't want the process writing to the server
|
|
interrupted at all.
|
|
|
|
QUESTION: Can I use two slip interfaces ?
|
|
|
|
ANSWER: Yes. If you have, for example, three machines which you
|
|
would like to interconnect, then you most certainly could use
|
|
two slip interfaces on one machine and connect each of the other
|
|
machines to it. Simply configure the second interface as you did
|
|
the first. NOTE that the second interface will require a different
|
|
IP address to the first. You may need to play with the routing a
|
|
bit to get it to do what you want, but it should work.
|
|
|
|
10. Known bugs.
|
|
|
|
There are several known bugs with the NET-2 software. Note that these
|
|
may or may not be fixed with a newer version of the NET-2 code;
|
|
therefore, I leave them here.
|
|
|
|
The bugs here are for NET-2d, found in kernels 0.99.pl10, pl11,
|
|
and pl12, and pl13, and pl14. NET-2e (currently in Beta), when
|
|
released, may or may not have fixed these bugs.
|
|
|
|
* Bug with route guessing code. If you ifconfig the "lo"
|
|
interface before the "eth0" interface in rc.inet1, whenever you
|
|
add a route, it will be added to "lo" instead of "eth0".
|
|
(Simply use the "route" command by itself; it will display all
|
|
of your routes. If your "default" route, which should be out
|
|
on the ethernet, is for device "lo" instead of "eth0", then you're
|
|
seeing this bug.)
|
|
|
|
This is just a problem with the route guessing code. Several
|
|
things can fix it: 1) ifconfig/route on "eth0" before "lo" in
|
|
rc.inet1; or, 2) Set your netmask to 255.0.0.0 (which is reported
|
|
to work, but I can't guarantee it). This should be fixed in NET-2e.
|
|
|
|
* Missing IP packet fragmentation. Packet fragmentation allows the
|
|
various protocol layers to "chop up" packets into smaller packets
|
|
if the MTU (maximum tranfer unit) of one network differs from
|
|
another. NET-2e should contain packet fragmentation/defragmentation
|
|
code, but NET-2d currently does not.
|
|
This now only applies to kernel earlier than pl14+, as it is now
|
|
supported.
|
|
|
|
* Weak NFS support. There have been a number of success stories with
|
|
NFS under Linux, however, not all of the support is there. For
|
|
one thing, the current NFS buffer size is much smaller, and
|
|
therefore much slower, than other implementations of NFS.
|
|
|
|
11. Copyright Message. (We're not ogres, nor are we silly).
|
|
|
|
The NET-2-HOWTO is copyright by Terry Dawson and Matt Welsh. A verbatim
|
|
copy of this document may be reproduced and distributed in any medium,
|
|
physical or electronic without permission of the authors. Translations
|
|
are similarly permitted without express permission if such translations
|
|
include a notice stating who performed the translation, and that it is
|
|
a translation. Commercial redistribution is allowed and encouraged,
|
|
however, the authors would like to be notified of any such
|
|
distributions.
|
|
|
|
Short quotes may be used without prior consent by the authors.
|
|
Derivative works and partial distributions of the NET-2-HOWTO must
|
|
include either a verbatim copy of this file, or make a verbatim copy
|
|
of this file available. If the latter is the case, a pointer to the
|
|
verbatim copy must be stated at a clearly visible place.
|
|
|
|
In short, we wish to promote dissemination of this information through
|
|
as many channels as possible. However, we wish to retain copyright on
|
|
this HOWTO document, and would like to be notified of any plans to
|
|
redistribute it. Further we desire that ALL information provided in
|
|
this HOWTO be disseminated.
|
|
|
|
If you have any questions relating to the conditions of this copyright,
|
|
please contact Matt Welsh, the Linux HOWTO coordinator, at:
|
|
mdw@sunsite.unc.edu, or +1 607 256 7372.
|
|
|
|
|
|
12. Miscellaneous.
|
|
|
|
I'm sure that I've missed something. This NET-2 HOWTO was thrown
|
|
together with the help of Matt Welsh, and Jeff Uphoff. Other major
|
|
contributors have been Alan Cox, Fred van Kempen, and others just
|
|
like yourself. Hopefully it will help you, and others out there, get
|
|
networking under Linux.
|
|
|
|
Future plans for the NET-2 HOWTO include a section on setting up
|
|
your own Linux LAN (with SLIP and/or Ethernet), adventures in
|
|
routing, and the use of netstat and other network administration
|
|
under Linux. For now, the information here should be more than
|
|
enough. :)
|
|
|
|
If you have questions about setting up NET-2, feel free to mail me, or
|
|
if you have any corrections, additions, or errata for this NET-2 HOWTO,
|
|
send me any and all changes (cdiffs are nice, but I'm flexible).
|
|
|
|
Of course, thanks to Fred, Linus, Ross, Phil, Paul, Don, Alan,
|
|
Matt, and everyone else who helped to develop the NET-2 code and work
|
|
on previous versions of TCP/IP for Linux and the NET-FAQ. Finally,
|
|
Linux has a complete implementation of TCP/IP. It may not be for
|
|
everyone yet. But for those who have an itch they want to scratch,
|
|
happy hacking, here it is.
|
|
|
|
Cheers,
|
|
|
|
Terry Dawson, (terryd@extro.ucc.su.oz.au)
|
|
|
|
13. Change History.
|
|
|
|
Changes from 1.8:
|
|
correction to broadcast address calculation, thanks Andr'as Salamon
|
|
tcp/ip tutorials added thanks to Gilbert Callaghan
|
|
These annotations at the suggestion of Andy Burgess
|
|
Shadow password section updated - thanks Rick Sladkey
|
|
added Slip Server section - thanks Fred
|
|
added /etc/net/diphosts section - thanks Fred
|
|
enhanced the netmask description a little
|
|
Revamped for 0.99.14
|
|
Added Index
|
|
|
|
Changes from 1.9:
|
|
Added change history.
|
|
Corrected Archive header now that I understand what it is there for
|
|
Thanks to _everyone_ who helped me understand :)
|
|
Ammended loopback route details - thanks Jeffrey A. Kintscher.
|
|
First attempt at enlarging the configuration section to cope with
|
|
different networks and different distributions thanks
|
|
Eric Christensen.
|
|
Reinstated /dev/arp as a required device. Oops.
|
|
Finally added resolv+(8) man page reference.
|
|
Tried to clean the slip section a bit.
|
|
Added leased line/cable slip link config using slattach.
|
|
Corrected a minor PLIP stoopidity I inflicted that fortunately noone
|
|
appears to have noticed.
|
|
Ammended Slip Server config to run a script in lieu of 'dip -i'
|
|
Fixed numerous tyops and mizpellinks (When will I not ?)
|
|
|
|
|