1545 lines
65 KiB
Plaintext
1545 lines
65 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 on configuration of TCP/IP networking and SLIP under Linux.
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-name: Linux/HOWTO/NET-2-HOWTO
|
|
Last-modified: 05 Dec 93
|
|
|
|
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.pl13 and above.
|
|
Please mail me if you have questions or comments. --terryd
|
|
|
|
This is the Linux NET-2 HOWTO v1.9, 05 December 1993
|
|
By Terry Dawson <terryd@extro.ucc.su.oz.au> and
|
|
Matt Welsh <mdw@sunsite.unc.edu>
|
|
|
|
CHANGES from previous version:
|
|
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
|
|
|
|
|
|
*** 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
|
|
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
|
|
5.2 Dynamic SLIP server connections
|
|
5.3 Using DIP
|
|
5.4 Configuring your Linux Machine as a SLIP Server
|
|
5.5 /etc/net/diphosts
|
|
5.6 Configuring Plip interfaces
|
|
5.6.1 PLIP Cabling Diagram
|
|
6. Are You Stuck?
|
|
7. Common Problems and Solutions
|
|
8. Known bugs
|
|
9. Miscellaneous
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
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>, device
|
|
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.) I'd like to keep this document as short as
|
|
possible... :)
|
|
|
|
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
|
|
supplied in the standard kernel distribution is version NET-2D
|
|
and is being progressively debugged and made more stable by
|
|
Alan, until NET-2E, which is currently undergoing Beta testing,
|
|
is ready for general release.
|
|
|
|
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?
|
|
|
|
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 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.
|
|
|
|
|
|
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, 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."
|
|
|
|
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 Ethenet devices for Linux.
|
|
|
|
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 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.
|
|
|
|
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 to either Fred, Linus, or the Free Software
|
|
Foundation. They have 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 many 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 (Parallal Line IP) for local
|
|
connection of two machines using your printer ports.
|
|
|
|
1.1 Supported Ethernet cards
|
|
|
|
NET-2 supports the following Ethernet cards:
|
|
|
|
3com 3c503, 3c503/16
|
|
Novell NE1000, NE2000
|
|
Western Digital WD8003, WD8013
|
|
Hewlett Packard HP27245, HP27247, HP27250 (these drivers could
|
|
do with more testing)
|
|
|
|
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
|
|
tsx-11.mit.edu:/pub/linux/packages/net/net-2/sources/net/net-010.tar.z.
|
|
This package includes network configuraiton 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.
|
|
Get the three files in this directory: net-base.tar.z, net-std.tar.z,
|
|
and 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_
|
|
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.x of libc,
|
|
the shadow password handling will no longer need to be in the
|
|
application, and will be handled externally. I have been assured that
|
|
4.5.x is due for release shortly.
|
|
|
|
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-010 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-010.
|
|
# mkdir /usr/src/net-010
|
|
# cd /usr/src/net-010
|
|
# zcat net-010.tar.z | tar xvvofp -
|
|
|
|
** 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-010 distribution:
|
|
# mkdir -p /conf/net
|
|
# chown -R root.root /conf; chmod -R 755 /conf
|
|
# cp /usr/src/net-010/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 version 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/arp /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.
|
|
|
|
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.)
|
|
|
|
|
|
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-010
|
|
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).
|
|
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. These two programs tell the kernel how to route and
|
|
manage TCP/IP connections to your system, by setting things such as
|
|
the IP address, network mask, and so on.
|
|
|
|
Note that in the previous NET-1 code, the "config" program was
|
|
used. However, the "standard" for UNIX system TCP/IP configuration
|
|
is to use ifconfig and route, and this has been implemented with NET-2.
|
|
|
|
THEREFORE: Get rid of your old "rc.net" if you have one. You
|
|
should only run rc.inet1 and rc.inet2 at boot time. If you run your old
|
|
"rc.net" instead, you'll get error messages about "old-style ioctl"
|
|
and things probably won't work at all.
|
|
|
|
NOTE: SLS uses "rc.net" instead of "rc.inet1" and "rc.inet2". Just
|
|
make sure that your "rc.net" uses "ifconfig" and "route" instead
|
|
of the old "config" program. In other words, be sure that your
|
|
rc.net is a new, NET-2 style rc.net. If it is not, get rid of it
|
|
and replace it with rc.inet1 and rc.inet2, as described below.
|
|
If you run SLS, the file "rc.net" contains the code for both rc.inet1
|
|
and rc.inet2.
|
|
|
|
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.
|
|
Remember that SLS uses just rc.net.
|
|
|
|
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 should look like:
|
|
|
|
|
|
#!/bin/sh
|
|
# rc.inet1: configure the network 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.0 # Network address for loopback network
|
|
|
|
# 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 # Add this line only if your
|
|
# network is not standalone
|
|
# End of rc.inet1
|
|
|
|
|
|
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.
|
|
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
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
4.2.2.1 "To named or not to named... that is the question."
|
|
|
|
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).
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
This file specifies how your system will lookup 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).
|
|
|
|
|
|
4.6 /etc/resolv.conf
|
|
|
|
This file contains two types of entires: 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 have a nameserver.
|
|
|
|
4.7 /etc/HOSTNAME
|
|
|
|
This is a new file; it contains the full hostname of your machine
|
|
(with the domain name). 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 the phone line, with a modem (no need for an Ethernet card).
|
|
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.
|
|
|
|
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, 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-010 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
|
|
|
|
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-010 package.
|
|
|
|
5.2 Dynamic SLIP server connections
|
|
|
|
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.3 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-010 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-010 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, you'll probably need to use the command
|
|
"dip -t" and use the DIP "local" and "remote" commands by hand after
|
|
the SLIP server prints your IP address. For example,
|
|
|
|
loomer:~% dip -t
|
|
DIP>port cua0 (My modem is on /dev/cua0.)
|
|
DIP>speed 57600 (Set the baud rate.)
|
|
DIP>reset (Reset modem and terminal line.)
|
|
DIP>send att\r\n (Send modem init string...)
|
|
DIP>dial 2446000 (Dial SLIP server.)
|
|
DIP>term (Enter interactive mode.)
|
|
|
|
Welcome to Annex Server...
|
|
Annex login: mdw1
|
|
Annex password:
|
|
|
|
User mdw1 authenticated.
|
|
Annex> slip (From SLIP server prompt, give "slip" command to start
|
|
SLIP connection.)
|
|
|
|
SLIP inititated.
|
|
Your IP address is 128.254.254.10, server address is 128.254.254.1.
|
|
|
|
^] (Hit DIP break key to get back to DIP prompt.)
|
|
DIP> local 128.254.254.10 (Give local command to specify my IP address.)
|
|
DIP> remote 128.254.254.1 (Specify server's IP address.)
|
|
DIP> mtu 1500 (Set SLIP MTU value.)
|
|
DIP> mode SLIP (Start the SLIP mode from DIP.)
|
|
|
|
loomer:~%
|
|
|
|
Now we're running in SLIP mode, and everything should work. The command
|
|
# /etc/ifconfig sl0
|
|
will tell you the current interface parameters; you may need to set
|
|
some of these by hand if DIP didn't get the correctly. Also, some have
|
|
found that they need to use the route command to change their operating
|
|
parameters. DIP sets a route for the address of your SLIP server, but
|
|
you may need to delete this route and add it as your gateway instead.
|
|
For example, with a SLIP server address of 128.253.154.1, use the
|
|
commands:
|
|
|
|
# /etc/route del 128.253.154.1
|
|
# /etc/route add default gw 128.253.154.1
|
|
|
|
In later versions of dip, and I too profess to be confused as to
|
|
exactly which version it might be, this procedure will not work,
|
|
and you should instead use the dip
|
|
|
|
default
|
|
|
|
command instead. This will automatically point your default route
|
|
via your slip link.
|
|
|
|
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.
|
|
|
|
Of course, typing all of those DIP commands may be time consuming. It
|
|
may be possible to write a DIP chat script to run all of the commands
|
|
up through dialing the connection and logging in, and then "exit" the
|
|
script to let you type the "local" and "remote" commands by hand.
|
|
|
|
Furthermore, there are patches for DIP by Paul Mossip
|
|
(mossip@vizlab.rutgers.edu) which modify the "get" command to grab
|
|
the IP address of your host and the server from the output of
|
|
the SLIP server. This should allow you to do all of the dialing and
|
|
configuration within a chat script just as you would with static
|
|
SLIP servers. This patch was recently posted to comp.os.linux.announce.
|
|
(Check the c.o.l.a archives on sunsite.unc.edu.)
|
|
|
|
Fred is planning to modify DIP for easier use by those with dynamic
|
|
SLIP servers (including the above patch) soon.
|
|
|
|
You'll have to play with various values for your routes and gateways
|
|
to get everything going correctly. If you have any information on how
|
|
you configured your SLIP interface, please drop me a note
|
|
(terryd@extro.ucc.su.oz.au). Include info on your SLIP address, server
|
|
address, gateway, and so on, and what commands you used to set up
|
|
SLIP. There are various possible configurations for SLIP servers and
|
|
I'd like to update this NET-2 HOWTO with as many hints as possible. :)
|
|
|
|
5.4 Configuring your Linux Machine as a SLIP Server
|
|
|
|
So, you wanna go bleeding edge eh ? Ok. I've asked Fred about how to
|
|
do this, and the following is what he has supplied. What I would like
|
|
you to do is take the following information, and make what use of it
|
|
you can. Then, when you have a slip server successfully working,
|
|
I'd like you to send me your configuration scripts, and a description
|
|
of how to use it, and send it to me to replace this section. Ok ?
|
|
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".
|
|
|
|
A sample /etc/passwd entry for a Slip user looks like:
|
|
|
|
Sfredm:ij/SMxiTlGVCo:1004:10:UUNET:/tmp:/usr/bin/dip -i
|
|
^^ ^^ ^^ ^^ ^^ ^^ ^^
|
|
| | | | | | \__ dip 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 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.5 /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.
|
|
|
|
5.6 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 possibel 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 dip interface might be:
|
|
|
|
/etc/rc.d/rc.inet1:
|
|
|
|
ifconfig pl0 192.148.64.1 broadcast 192.148.255.255 \
|
|
netmask 255.255.0.0 pointopoint 212.194.167.1 up
|
|
|
|
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.
|
|
|
|
/etc/rc.d/rc.inet2:
|
|
|
|
route add default pl0 metric 1
|
|
|
|
In almost all respects, you can treat a plip interface as though
|
|
it were a slip interface, except that dip is not, and cannot be
|
|
used.
|
|
|
|
5.6.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:
|
|
|
|
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. Are You Stuck?
|
|
|
|
Really? Then you should read the man pages for ifconfig and route,
|
|
included in the net-010 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.
|
|
|
|
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.
|
|
|
|
7. 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: Whan 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. Try
|
|
using "dip -v" which will print debugging information while DIP
|
|
is dialing the server. Remember that for some SLIP connections you
|
|
may need to use the commands
|
|
|
|
# route del <your slip server address>
|
|
# route add default gw <your slip server address>
|
|
|
|
or the dip:
|
|
|
|
default
|
|
|
|
command (depending on the version of dip you are running),
|
|
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/net/inet/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.
|
|
|
|
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: 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
|
|
amout 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). If your MTU is
|
|
too large, the SLIP server will fragment the packets, and currently
|
|
(NET-2d), IP packet fragmentation isn't supported (see next section).
|
|
The solution is to set a smaller MTU (around 512, or lower) in
|
|
your dip chat script.
|
|
|
|
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.
|
|
|
|
8. 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.
|
|
pl14 has had fragmentation support fitted.
|
|
|
|
|
|
* 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. From
|
|
what I understand, this problem is related to the lack of packet
|
|
fragmentation code, above. With pl14 and upwards this will probably
|
|
be resolved.
|
|
|
|
|
|
9. Miscellaneous
|
|
|
|
I'm sure that I've missed something. This NET-2 HOWTO was thrown
|
|
together with the help of Matt Welsh, Jeff Uphoff, and Alan Cox.
|
|
Hopefully it will help someone out there get going with 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, 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 want to do some hacking---here it is.
|
|
|
|
Cheers,
|
|
|
|
Terry Dawson, (terryd@extro.ucc.su.oz.au)
|
|
|
|
|