Subject: Linux NET-2 HOWTO (part 2/2)
From: [email-masked] (Terry Dawson)
Date: Mon, 25 Apr 1994 19:52:41 GMT
Newsgroups: comp.os.linux.announce,comp.os.linux.help,comp.os.linux.admin,news.answers,comp.answers

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
	/etc/net/diphosts.

5.6	/etc/net/diphosts

	/etc/net/diphosts is used by dip to lookup preset configurations for
	remote hosts. These remote hosts might be users dialing-into your
	linux machine, or they might be for machines that you dial into
	with your linux machine.

	The general format for /etc/net/diphosts is as follows:

	Suwalt::145.71.34.1:SLIP uwalt:CSLIP,1006
	  ^    ^  ^            ^         ^     ^
	  |    |  |            |         |     \___ MTU
	  |    |  |            |         \_________ protocol (SLIP, CSLIP,
	  |    |  |            |                    KISS, PPP)
	  |    |  |            \___________________ comment field ("gecos" :-)
	  |    |  \________________________________ IP address of the other
	  |    |                                    side, or host.domain.name
	  |    \___________________________________ unused (compat. with passwd)
	  \________________________________________ login name (as returned by
	                                            getpwuid(getuid()) )

	An example /etc/net/diphosts entry for a remote slip user might be:

		Sfredm::145.71.34.1:SLIP uwalt:SLIP,296
		which specifies a SLIP link with MTU==296, or

		Sfredm::145.71.34.1:SLIP uwalt:CSLIP,1006
		which specifies a CSLIP-capable link with MTU of 1006.

	When a user logs in, they will receive a normal login, and
	password prompt, at which they should enter their slip-login
	userid and password. If they check out ok, then the user will
	see no special messages, they should just change into slip mode
	at their end, and then they should be able to connect ok, and be
	configured with the paramters from the diphosts file.

5.7	Configuring PLIP interfaces.

	PLIP is like SLIP, in that it is used for providing point to point
	IP links between machines, except that it is designed to use the
	Parallel ports on your machine instead of the serial ports. Because
	it is possible to transfer more than one bit at a time with the
	Parallel port, it is possible to attain higher speeds with the
	plip interface than with the serial interface. In addition, even
	the simplest of parallel ports, printer ports, can be used, in
	lieu of you having to purchase conmparatively expensive 16550AFN
	UARTs for your serial ports.

	When compiling the kernel, there is only one file that might need
	to be looked at. That file is net/drv/plip/global.h, and it contains
	timers in mS. The defaults are probably going to be fine, unless you
	have an especially slow computer, in which case you might have to
	increase them on the machine at the other end of the link.

	A sample configuration for a plip interface might be:

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

IPADDR='192.148.64.1'		# Replace with YOUR IP Address
REMADDR='212.194.167.1'		# Replace with the address of YOUR OTHER HOST

ifconfig pl0 $IPADDR pointopoint $REMADDR up	# Configure PLIP interface
route add default gw $REMADDR			# Route to other machine.

# End

	The pointopoint parameter has the same meaning as for SLIP, in 
	that it specifies the address of the machine at the other end of
	the link.

	In almost all respects, you can treat a plip interface as though
	it were a slip interface, except that neither 'dip' nor 'slattach'
	can be, or are used.

5.7.1	PLIP Cabling Diagram.

	PLIP has been designed to use cables with the same pinout as those
	commonly used by the better known of the dos based pc-pc file transfer
	programs. The pinout diagram (taken from net/drv/plip/README) looks as
	follows:

	Pin Name	Connect pin - pin:
	--------------	----------------------
        GROUND          25 - 25
        D0->ERROR       2 - 15          15 - 2
        D1->SLCT        3 - 13          13 - 3
        D2->PAPOUT      4 - 12          12 - 4
        D3->ACK         5 - 10          10 - 5
        D4->BUSY        6 - 11          11 - 6
        D5              7*
        D6              8*
        D7              9*
        STROBE output   1*
        AUTOFD output   14*
        INIT output     16*
        SLCTIN output   17*

        Do not connect the pins marked with an asterisk (`*').  They are
        D5 (pin 7), D6 (pin 8) and D7 (pin 9).  STROBE is pin 1, FEED is
        pin 14.

        Extra grounds are on pins 18, 19, 20, 21, 22, 23 and 24.

        If the cable you are using has a metallic shield it should be
        connected to the metallic DB-25 shell at one end only.

6.	PPP (Under construction).

	There is now some ALPHA PPP software available. For the latest
	information relating to it, join the PPP channel on the niksula.hut.fi
	list server, and keep your eye on comp.os.linux.development.
	Already there have been some encouringly good reports for it.

	The PPP software comes in two parts. Some kernel modifications, and
	the ppp daemon. They are available at the following locations:

	ftp://ftp.gang.umass.edu/user/michael/linux-ppp-0.1.5.tgz
	ftp://ftp.gang.umass.edu/user/michael/pppd-0.1.4.tgz

	Please check that there isn't a later version there, and be
	sure to read any README files or the like that are there as
	well, as they will tell you how to install, where to report
	bugs and the like.

7.	AX.25 (Under construction).

	Alan Cox has some experimental AX.25 code available for testing.

8.	Are You Stuck ?

	Really ? Then you should read the man pages for ifconfig and route, 
	included in the net-032 package, and understand their functions. These 
	commands have a lot of flexibility, and because everyone's network 
	setup is different, you may find a way to use ifconfig and route to
	get your connection working. If you do, feel free to send me some mail
	so I can include it in the next update of the NET-2 HOWTO. Because of
	my limited amount of experimental data, most of the discussion above
	is about my own setup, and I'd like to generalize it as much as 
	possible.

	Matt is currently writing a set of scripts to simplify NET-2
	configuration. You can pick up the pre-alpha release from
	tc.cornell.edu, in the file /pub/mdw/netconf-0.3.tar.z. These scripts
	maintain a small database of network configuration info, and allow you
	to easily modify and configure your network interface. The scripts are
	far from complete: Matt has been waiting until the NET-2 interface
	itself stabilizes a bit more before upgrading it further. 

	Another good place to look for help on setting up NET-2 is the 
	O'Reilly and Associated book 'TCP/IP Network Administration',
	the one with the crab on the cover. Keep in mind that NET-2 is now
	a "standard" implementation of TCP/IP, this means that ifconfig
	and route work the same under Linux as they do on other UNIX systems.
	Keep also in mind that some of the arguments and options may differ
	slightly from those in the book.

	You might also search out the following documents which are an
	excellent source of tutorial information on tcp/ip:

	athos.rutgers.edu:/runet
	-rw-r--r--  1 0        0          176218 Oct 20  1989 tcp-ip-admin.doc
	-rw-r--r--  1 0        0          214199 Oct 20  1989 tcp-ip-admin.ps
	-rw-r--r--  1 0        0           92106 Oct 20  1989 tcp-ip-intro.doc
	-rw-r--r--  1 0        0          111478 Oct 20  1989 tcp-ip-intro.ps

	Also keep in mind that NET-2 _is_ developing very rapidly, it's
	one of the newest additions to the Linux kernel. Thus, all of the
	bugs haven't been worked out yet, so there may be some problems.
	However, a good rule of thumb is that if you were able to get TCP/IP
	working under kernels before 0.99.pl10, you should be able to get it
	working under NET-2 as well. There are still some issues dealing with
	performance to be fixed, but overall the system works. And, as with
	everything in Linux development, time will cure what ails NET-2. 
	If it's absolutely unusable to you, go back to an earlier kernel 
	version, and wait until things develop further. The code is still
	fairly new.

9.	Common Problems and Solutions.

	Now that the NET-2 HOWTO has been out for a while, I've been
	able to gather some common problems (and answers!). Here are
	some things which I have learned from hearing from readers.
	If you run into a problem which should be included here,
	please send it along (even if you have the solution!).

	QUESTION: How do I know what version of NET software I am running?

	ANSWER: In the kernel messages when you boot your machine, you should
	see a line that describes your networking code. For example, mine
	looks like:

	Linux version 0.99.14l+NET-2EB4 ([email-masked].)

	This line, not terribly obviously, tells you that I am running
	NET-2E, Beta 4.
	
	QUESTION: When I try to use the network, or use SLIP, I get the
	          error message "Network not reachable". What should I do?

	ANSWER: This message means that a machine somewhere in the path did
	not have a route to the destination network. Until you can demonstrate
	otherwise, it is the courteous thing to do, assume it is your
	machine. This is usually an indication that either your ifconfig or	
	route commands are in some way wrong. You can look at the status of
	your ifconfig by using the command "ifconfig" by itself. This should
	tell you what NET-2 thinks your IP address, netmask, etc. are.
	You can use the command "route" by itself to get routing information.
	This will tell you what routes you have set up and what gateways
	(if any).

	The best way to test a SLIP or network connection is to use "ping"
	with IP addresses only. If you use hostnames, as in "ping loomer",
	if some part of name lookup isn't working you'll have trouble.
	To test just the network, NOT name lookup, use only IP addresses,
	as in "ping 128.253.154.32".

	For SLIP connections the best thing to do is to ping your
	SLIP server. If nothing comes back, then something is wrong with your
	slip port configuration, double check all of the steps detailed above.
	Try using "dip -v" which will print debugging information while DIP
	is dialing the server.

	If you get a response from your slip server, but not from anywhere else,
	then you are probably missing your default route, you may need to use
	the commands:

		# route del <your slip server address>
		# route add default gw <your slip server address>

	to get SLIP talking to the server. Once you can talk to the
	server, everything SHOULD work (if your server is set up correctly!).

	For Ethernet connections, try pinging your gateway. If you can talk
	to your gateway, you should be able to talk to the outside world.
	You may need more than one route (that is, more than one gateway).
	For example, some universities use one gateway for on-campus
	networks and another for off-campus networks. 

	Either way, try pinging addresses on your local network, and remote
	addresses. If you can ping all addresses ok remote to your network,
	and some on your local network, but not others on your local network,
	then check your netmask setting.

	If the "network not reachable" message means that you can't
	talk to your gateway. This can be due to several things:

		a) Wrong route or ifconfig commands
		b) Ethernet card problems (see below)
		c) You didn't compile the kernel correctly (see below).
		d) There is in fact some sort of network failure elsewhere.

	QUESTION: I keep getting the error "eth0: transmit timed out".
	          What does this mean?

	ANSWER: This usually means that your Ethernet cable is unplugged,
	or that the setup parameters for your card (I/O address, IRQ, etc.)
	are not set correctly. Check the messages at boot time and make
	sure that your card is recognized with the correct Ethernet address.
	If it is, check that there is no conflict with any other hardware
	in your machine, eg you might have a soundblaster sharing the same
	IRQ or i/o control port.

	QUESTION: I get errors "check Ethernet cable" when using the network.

	ANSWER: You probably have your Ethernet card configured incorrectly.
	For Etherlink cards, in the file /usr/src/linux/driver/net/CONFIG,
	change the line
		EL_OPTS 	= -UEL2_AUI
	to
		EL_OPTS		= -DEL2_AUI

	This tells the card to use the AUI cable interface. 
	Just make sure that all of the options for your card are set
	correctly in the CONFIG file, and rebuild your kernel.

	QUESTION: When I use NET-2, I get a "General protection" error
	          or a panic from the kernel. How can I fix this?

	ANSWER: Remember that the NET-2 code is still on the buggy side, 
	just because it's in mid-development. If you get a kernel panic
	while using NET-2, write down the EIP address (and the other
	information given in the panic message). The EIP is the address
	where the kernel paniced, usually of the form 0008:xxxxxxxx
	where "0008" is the segment descriptor for the kernel text, and
	"xxxxxxxx" is the offset into that segment (80386 programmers will
	know what this means).

	Use the command 
		nm /usr/src/linux/tools/system | sort -n
	or 
		nm /usr/src/linux/tools/zSystem | sort -n

	depending on whether or not you use a compressed kernel (zImage).
	This will print a listing of all symbols in the kernel text, 
	simply scan down the list and look for the function that contains
	the EIP address in the kernel dump. There's the culprit.

	However, in some cases the EIP can be misleading; the kernel
	may panic at a place which is complete irrelevant to where the
	actual problem occurred. However, it is a good starting place;
	first, locate the function which contains the EIP address, and
	then check out the kernel code to see what might be wrong.

	Keep in mind that this will only work if you compile your own
	kernel and have the "system" file associated with it. 

	QUESTION: How can I hang up the phone line when I'm done using
	          SLIP?

	ANSWER: If you use dip to dial out on the SLIP line, just
	"kill -9" the dip process itself (dip won't die unless you kill
	it with SIGKILL or some other signal). When dip dies, the line
	should hang up. DIPs behaviour is being modified so that it will
	be more sociable and die when it is supposed to. If you are using
	the new dip, then 'dip -k' will kill any copy of dip that you
	have running, and hang up the line as well.

	If you don't use dip to dial out, either instruct your dialing
	program to hang up the line, or kill the dialing process.

	QUESTION: dip doesn't work. How do I make it work ?

	ANSWER: Check that the file permissions of dip are 6750, that is
	'chmod 6750 dip'. Check also that dip is owned by root:
	'chown root:dip dip'

	QUESTION: With SLIP, I get a connection open, but no data flows.

	ANSWER: This could be a number of things. First, check your routes
	and be sure that the gateway is set correctly. Attempt to ping
	your gateway; if you can't, then something is wrong with the routes.
	
	Another problem could be that your system and the SLIP server 
	disagree about header compression. With 0.99.pl11 and above, 
	SLIP automatically compresses packet headers. To turn off header
	compression, check the SL_COMPRESS option in the CONFIG file.
	In pl14 there will be supplied a 'setencap' command to allow you
	to configure compression.

	QUESTION: With SLIP, I get a connection, but after sending a small
	          amount of data, the connection hangs.

	ANSWER: Probably an MTU problem. The MTU is the maximum packet
	size available for the network. For SLIP, your MTU is set in
	your dip dialing script with the "MTU" command. The default value
	is 1500, which means that the system can send packets of up to
	1500 bytes in size. However, some SLIP servers (Berkeley SLIP,
	for example), use a smaller MTU (around 1006).

	Another thing to check if you are having erratic SLIP problems is
	flow control. You need to use hardware (RTS/CTS) flow control
	on your modem, and your modem and your computer must agree. XON/XOFF
	flow control is not practical for SLIP.

9.1	Not so common problems and solutions (Mostly NFS).

	QUESTION: How do I use my existing Novell fileserver with my
	          Linux machine ?

	ANSWER: If you have the Novell NFS Daemon code then it is easy, just
	NFS mount the Novell volume that you wish to use. If you don't, and
	you are really desperate to be able to do this, and you have a spare
	pc machine laying about, you are in luck. Here is what you do:

	You configure the spare machine as a normal Novell workstation,
	mapping the appropriate Fileserver directories to virtual drives
	as you so desire. You then grab a copy of SOSS (Son Of Stans own
	Server) from your nearest ftp site, and run it on the same workstation.
	SOSS is an NFS server that will happily run on just about any pc.
	This will allow you to NFS export the Novell network drives. It has
	caveats in that it will not perform as well as directly mounting
	the Novell fileserver, that it requires another machine, and that it
	will generate roughly twice as much network traffic, but it will work.

		Stan's Own Server (NFS server).

	        spdcc.com:pub/sos/soss.zoo
	        spdcc.com:pub/sos/sossexe.zoo

		A version "couple of bugs fixed: IP numbers and subdirectories
		with extensions)" is available from:
	        hilbert.wharton.upenn.edu:/pub/tcpip/soss.zip

	QUESTION: Files get corrupted when using NFS over wider area networks
	          or SLIP, why ? How do I stop it ?

	ANSWER: Certain vendors (Sun primarily) shipped many machines running
	NFS without UDP checksums. Great on ethernet, suicide otherwise. UDP
	checksums can be enabled on most file servers. Linux has it enabled by
	default from pl13 onwards - but both ends need to have it enabled...

	QUESTION: Why are my NFS files all read only ?

	ANSWER: The Linux NFS server defaults to read only. RTFM the 'exports'
	and nfsd manual pages. With non Linux servers you may also need to
	alter /etc/exports 

	QUESTION: I mount from a linux nfs server and while ls works I can't
	          read or write files. How do I fix this ? 

	ANSWER: You must mount a Linux filestore with rsize=1024,wsize=1024
	(or 2048 if you really want - 1024 is a better choice).

	QUESTION: I mount from a linux nfs server with a blocksize of between
	          3500-4000 and it crashes the Linux box regularly, why ?

	ANSWER: This is a known problem that is being worked on, refer to
	previous question. Don't you hate answers like that ? :)

	QUESTION: Can Linux do NFS over TCP ?

	ANSWER: No. To do this would require someone to spend the time to
	update the rpc code to add rpc stream record marking. It should work
	then.

	QUESTION: Why do I get loads of strange errors trying to mount a
	          machine from a Linux box. 

	ANSWER: This is possibly related to a restriction imposed by older
	NFS servers. Make sure your users are in 8 groups or less.

	QUESTION: Why are my Linux NFS clients very slow when writing to Sun
	          & BSD systems ?

	ANSWER: NFS writes are normally synchronous, meaning that all file-
	-system changes occur in the order they transmitted, this means that
	if before NFS will allow you to write any more data, any previous
	write must have already completed, (you can disable this if you don't
	mind risking losing data). Worse still, BSD derived kernels, this
	includes Sun systems, tend to be unable to work in small blocks. Thus
	when you write 4K of data from a Linux box in the 1K packets it uses,
	BSD does this:

		read 4K page
		alter 1K
		write 4K back to physical disk
		read 4K page
		alter 1K
		write 4K page back to physical disk
		etc..
	
	Better systems don't have this problem. The Linux client is however
	quite slow anyway.

	QUESTION: I've heard NFS is not secure is this true ?

	ANSWER: Yes, totally. Running NFS in an uncontrolled environment is
	rather like leaving your front door open, painting 'On holiday' on
	your house and posting maps to every known criminal...
	In a fairly secure environment or when you can recover data from stupid
	misuse its pretty much OK. The worst someone can easily do is alter all
	the files on an NFS mounted disk, and/or crash the machine. So long as
	you don't mount your system files writable you should be mostly safe.

	QUESTION: I occasionally mount from lots of different places, do I have
	          to mount them all each time I boot ?

	ANSWER: No you can use the automounter to mount disks as you access
	        them.

	QUESTION: How do I stop things hanging when a server goes down ?

	ANSWER: There are three main NFS behaviours:

		soft: Your NFS client will report an error to the process
		      concerned if an NFS server doesn't answer after a few
		      retries. Most software handles this well - but not all.
	
		hard: Your NFS client will try forever unless killed off.
		      Operations will be restarted when the NFS server
		      recovers or reboots.
	
		hard,intr: As hard but ^C will also stop the NFS retrying. In
		      a few cases, notably nfs mounted /usr/spool/mail disks,
		      this doesn't help as the shell will be ignoring ^C when
		      it checks you have mail.

	If you intend to leave your machine unattended, then choosing the
	'soft' option is probably best, because while it might cause some
	problems to an application running, it won't halt your whole machine
	if a server that it is attached to goes down. If your machine will
	always have a human operator available, then the 'hard,intr' option
	might be best. The hard option would be best suited to you if you can
	afford to wait, and don't want the process writing to the server
	interrupted at all.

	QUESTION: Can I use two slip interfaces ?

	ANSWER: Yes. If you have, for example, three machines which you
	would like to interconnect, then you most certainly could use
	two slip interfaces on one machine and connect each of the other
	machines to it. Simply configure the second interface as you did
	the first. NOTE that the second interface will require a different
	IP address to the first. You may need to play with the routing a
	bit to get it to do what you want, but it should work.

10.	Known bugs.

	There are several known bugs with the NET-2 software. Note that these
	may or may not be fixed with a newer version of the NET-2 code;
	therefore, I leave them here. 
	
	The bugs here are for NET-2d, found in kernels 0.99.pl10, pl11, 
	and pl12, and pl13, and pl14. NET-2e (currently in Beta), when
	released, may or may not have fixed these bugs. 

	* Bug with route guessing code. If you ifconfig the "lo"
	  interface before the "eth0" interface in rc.inet1, whenever you
	  add a route, it will be added to "lo" instead of "eth0". 
	  (Simply use the "route" command by itself; it will display all
	  of your routes. If your "default" route, which should be out
	  on the ethernet, is for device "lo" instead of "eth0", then you're
	  seeing this bug.) 
	  
	  This is just a problem with the route guessing code. Several
	  things can fix it: 1) ifconfig/route on "eth0" before "lo" in
	  rc.inet1; or, 2) Set your netmask to 255.0.0.0 (which is reported
	  to work, but I can't guarantee it). This should be fixed in NET-2e.

	* Missing IP packet fragmentation. Packet fragmentation allows the
	  various protocol layers to "chop up" packets into smaller packets
	  if the MTU (maximum tranfer unit) of one network differs from
	  another. NET-2e should contain packet fragmentation/defragmentation
	  code, but NET-2d currently does not.
	  This now only applies to kernel earlier than pl14+, as it is now
	  supported.

	* Weak NFS support. There have been a number of success stories with
	  NFS under Linux, however, not all of the support is there. For
	  one thing, the current NFS buffer size is much smaller, and 
	  therefore much slower, than other implementations of NFS.

11.	Copyright Message. (We're not ogres, nor are we silly).

	The NET-2-HOWTO is copyright by Terry Dawson and Matt Welsh. A verbatim
	copy of this document may be reproduced and distributed in any medium,
	physical or electronic without permission of the authors. Translations
	are similarly permitted without express permission if such translations
	include a notice stating who performed the translation, and that it is
	a translation. Commercial redistribution is allowed and encouraged,
	however, the authors would like to be notified of any such
	distributions. 

	Short quotes may be used without prior consent by the authors.
	Derivative works and partial distributions of the NET-2-HOWTO must
	include either a verbatim copy of this file, or make a verbatim copy
	of this file available. If the latter is the case, a pointer to the
	verbatim copy must be stated at a clearly visible place.

	In short, we wish to promote dissemination of this information through
	as many channels as possible. However, we wish to retain copyright on
	this HOWTO document, and would like to be notified of any plans to
	redistribute it. Further we desire that ALL information provided in
	this HOWTO be disseminated.

	If you have any questions relating to the conditions of this copyright,
	please contact Matt Welsh, the Linux HOWTO coordinator, at:
	[email-masked], or +1 607 256 7372.

12.	Miscellaneous.

	I'm sure that I've missed something. This NET-2 HOWTO was thrown 
	together with the help of Matt Welsh, and Jeff Uphoff. Other major
	contributors have been Alan Cox, Fred van Kempen, and others just
	like yourself. Hopefully it will help you, and others out there, get
	networking under Linux. 

	Future plans for the NET-2 HOWTO include a section on setting up
	your own Linux LAN (with SLIP and/or Ethernet), adventures in
	routing, and the use of netstat and other network administration
	under Linux. For now, the information here should be more than 
	enough. :)
	
	If you have questions about setting up NET-2, feel free to mail me, or 
	if you have any corrections, additions, or errata for this NET-2 HOWTO, 
	send me any and all changes (cdiffs are nice, but I'm flexible). 

	Of course, thanks to Fred, Linus, Ross, Phil, Paul, Don, Alan,
	Matt, and everyone else who helped to develop the NET-2 code and work
	on previous versions of TCP/IP for Linux and the NET-FAQ. Finally,
	Linux has a complete implementation of TCP/IP. It may not be for
	everyone yet. But for those who have an itch they want to scratch,
	happy hacking, here it is.

	Cheers,

	Terry Dawson, ([email-masked])

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