Newsgroups: comp.os.linux.announce,,comp.os.linux.admin,
From: (Terry Dawson)
Subject: Linux NET-2 HOWTO (part 1/2)
Message-ID: <>
Followup-To: poster
Summary: HOWTO configure TCP/IP networking, SLIP, PLIP, and PPP under Linux.
Keywords: Linux, Networking, TCP/IP, NET-2, SLIP
Sender: (Matt Welsh)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Mon, 25 Apr 1994 19:48:17 GMT
Approved: (Matt Welsh)
Lines: 1513

Archive-name: linux/howto/networking/part1
Last-modified: 15 Apr 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 <> and 
   Matt Welsh <> 

(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, kke...@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	"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 <>. It is based 
	on the NET-1 code by Ross Biro <>, ethernet 
	drivers by Donald Becker <>, SLIP drivers by 
	Laurence Culhane <>, and the D-Link driver by
	Bj0rn Ekwall <>. The NET-2debugged code is maintained
	by Alan Cox <>. 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,
	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

	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

	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
        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:

	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
	/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
	or directly from me ( It will also be
	posted to the newsgroups comp.os.linux.announce,,
	and news.answers periodically. 

	You can find news.answers FAQ postings, including this one, archived

0.5	Feedback.

	Please send any comments, updates, or suggestions to me, 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 
	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 (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

	This package includes network configuration programs such as
	ifconfig, route, netstat etc.

	The TCP/IP application binaries and setup files are found in:
	      "          "    "      "      "    "      "    /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:

	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/ /lib/
		# ln -sf /lib/ /lib/

	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

	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

	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

	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 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

	* 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 as their netmask. Other Class B
	  networks use 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		(Class A)
	  128-191		(Class B)
	  192+		(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, the netmask for
	  this port is always 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, and your IP address
	  is, your network number (IP addr AND netmask) is With a netmask of, 
	  this would be 

	  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,
	  your broadcast address will be your network address (calculated
	  above) ORed with

	  For example:

	  Your IP address is:
	  Your netmask is:
	  netmask inverted is:


	  Your broadcast address should be:

	  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, your gateway might be
	  Your network admins will provide you with the IP address of your

	  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 However,
	  But it is not required that you run named at all; see section

	  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 after you have
	converted it).

	NOTE: The standard SLS "rc" file file calls "/etc/" instead
	of "/etc/rc.d/rc.inet1" and "/etc/rc.d/rc.inet2". The SLS
	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/, 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, 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:

# Portion of /etc/rc.d/rc.inet1 to configure the loopback interface


# Attach the loopback device. 
/etc/ifconfig lo	# uses default netmask
/etc/route add	# 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=""		# REPLACE with YOUR IP address!
NETMASK=""		# REPLACE with YOUR netmask!
NETWORK=""		# REPLACE with YOUR network address!
				# Note: NETWORK MUST be in
				#       /etc/networks
BROADCAST=""	# REPLACE with YOUR broadcast address, if you
				# have one. If not, leave blank and edit below.
GATEWAY=""		# 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, 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, <>

# Constants.

# 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 ]
	echo -n "syslogd "

# Start the SUN RPC Portmapper.
if [ -f ${NET}/rpc.portmap ]
	echo -n "portmap "

# Start the INET SuperServer
# This is a MUST HAVE, so leave it in.
if [ -f ${NET}/inetd ]
	echo -n "inetd "
	echo "no INETD found.  INET cancelled!"
	exit 1

# Start the NAMED/BIND name server.
if [ ! -f ${NET}/named ]
	echo -n "named "

# Start the ROUTEd server.
if [ -f ${NET}/routed ]
  	echo -n "routed "
  	${NET}/routed -q #-g -s

# Start the RWHO server.
if [ -f ${NET}/rwhod ]
	echo -n "rwhod "
	${NET}/rwhod -t -s

# Start the U-MAIL SMTP server.
if [ -f XXX/usr/lib/umail/umail ]
	echo -n "umail "
	/usr/lib/umail/umail -d7 -bd </dev/null >/dev/null 2>&1 &

# Start the various INET servers.
for server in ${IN_SERV}
	if [ -f ${NET}/${server} ]
		echo -n "${server} "

# Start the various SUN RPC servers.
if [ -f ${NET}/rpc.portmap ]
	if [ -f ${NET}/rpc.ugidd ]
		echo -n "ugidd "
		${NET}/rpc.ugidd -d
	if [ -f ${NET}/rpc.mountd ]
		echo -n "mountd "
	if [ -f ${NET}/rpc.nfsd ]
		echo -n "nfsd "

	# Fire up the PC-NFS daemon(s).
	if [ -f ${NET}/rpc.pcnfsd ]
		echo -n "pcnfsd "
		${NET}/rpc.pcnfsd ${LPSPOOL}
	if [ -f ${NET}/rpc.bwnfsd ]
		echo -n "bwnfsd "
		${NET}/rpc.bwnfsd ${LPSPOOL}

echo network daemons started.
# Done!	"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 
	"", 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 ""
	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 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
	  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 If you want to alias machines, for example you want
	to refer to "" 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, 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 above.)

	This file needs to contain at least an entry for 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  You may also wish to include entries 
	for your gateway and network addresses. 

	For example, if "" has the IP address 
	"", my /etc/hosts file would look like:

	# /etc/hosts: List of hostnames and IP addresses 		localhost 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, with
	both "localhost" and your hostname after it.
	Note that in the second line, above, there are two names for "" 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		# default route    - mandatory
loopnet	# loopback network - mandatory
mynet	# 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:  []
        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, then the address of
	your nameserver is just (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,
	your domain name is just "", without the hostname ("loomer").

	For example, if your machine is, and has a
	nameserver at the address, your /etc/resolv.conf would 
	look like:


	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:

	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

	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

	'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

	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
	Configuring SLIP is much like configuring an Ethernet interface
	(please read section 4.0 above). However, there are a few key

	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, and your IP address is, you may 
	need to run the command 

		# /etc/ifconfig sl0 pointopoint

	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
IPADDR=""         # REPLACE with YOUR IP address!
REMADDR=""	# 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 

	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 Server address is" 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

  # Fetch the IP address of our target host.

  # Set the desired serial port and speed.
  port /dev/cua0
  speed 38400

  # Reset the modem and terminal line.

  # 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.
  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
  print CONNECTED to $remote with address $rmtip we are $local
  mode SLIP
  goto exit
  print SLIP to $host failed.
# 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'

	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 kke...@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:

	 ^^         ^^        ^^  ^^   ^^    ^^   ^^
	  |          |         |   |    |     |    \__ 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

---End of part 1/2---

Newsgroups: comp.os.linux.announce,,comp.os.linux.admin,
From: (Terry Dawson)
Subject: Linux NET-2 HOWTO (part 2/2)
Message-ID: <>
Followup-To: poster
Summary: HOWTO configure TCP/IP networking, SLIP, PLIP, and PPP under Linux.
Keywords: Linux, Networking, TCP/IP, NET-2, SLIP
Sender: (Matt Welsh)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: <>
Date: Mon, 25 Apr 1994 19:52:41 GMT
Approved: (Matt Welsh)
Lines: 644

Archive-name: linux/howto/networking/part2
Last-modified: 15 Apr 94

---This is part 2/2---

	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

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:: uwalt:CSLIP,1006
	  ^    ^  ^            ^         ^     ^
	  |    |  |            |         |     \___ MTU
	  |    |  |            |         \_________ protocol (SLIP, CSLIP,
	  |    |  |            |                    KISS, PPP)
	  |    |  |            \___________________ comment field ("gecos" :-)
	  |    |  \________________________________ IP address of the other
	  |    |                                    side, or
	  |    \___________________________________ 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:: uwalt:SLIP,296
		which specifies a SLIP link with MTU==296, or

		Sfredm:: 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:

# Portion of /etc/rc.d/rc.inet1 for PLIP connection to local machine

IPADDR=''		# Replace with YOUR IP Address
REMADDR=''		# 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

	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
	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:

	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 

	Matt is currently writing a set of scripts to simplify NET-2
	configuration. You can pick up the pre-alpha release from, 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:
	-rw-r--r--  1 0        0          176218 Oct 20  1989 tcp-ip-admin.doc
	-rw-r--r--  1 0        0          214199 Oct 20  1989
	-rw-r--r--  1 0        0           92106 Oct 20  1989 tcp-ip-intro.doc
	-rw-r--r--  1 0        0          111478 Oct 20  1989

	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 (

	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".

	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

	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
		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

	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).

		A version "couple of bugs fixed: IP numbers and subdirectories
		with extensions)" is available from:

	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

	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
	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

	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 (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

	* 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

	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:, 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.


	Terry Dawson, (

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 ?)

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.