Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: notes for people installing NeXT SLIP
Message-ID: <1991Jun27.124556.27545@ni.umd.edu>
Date: 27 Jun 91 12:45:56 GMT
References: <1991Jun27.071351.17884@milton.u.washington.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 65

In article <1991Jun27.071351.17884@milton.u.washington.edu> mrc@cac.washington.edu (Mark Crispin) writes:
>     1) Have a thorough understanding of your IP connectivity
>configuration.  This issue is too complex to go into here, but
>briefly, you need to have sketched out what you have since you will
>have to make adjustments based on what you have.

Yes, that's for sure.  Everyone's environment and situation is likely
to be just a little bit different.  Remember, you're designing a
network here, and that deserves careful thought.

>     2) Your modems *must* be hardware flow controlled.  This means no
>Mac modem cables. 

I'm surpised to hear this.  I'm using a non-hardware flow controlled
connection to my modem at 9600 BPS, and it has worked just fine.  On
the other hand, it is NOT a Mac cable because it has DTR and CD
correctly wired.

>     3) To make sure the slip line is seen by anyone else, make sure
>that the gateway machine is running routed with the -s option.  The
>NeXT-supplied /etc/rc does not specify -s so you will need to add it.

This is very much a site specific option, and one of many solutions.
At our site, this won't work because of how the routing is configured
and who believes what.  Again, see (1) above for thinking Real Hard
about how your proposed configuration is supposed to work.

>     4) I found that the the receiving (dudisc) end didn't work the
>way the scripts expected.  The scripts expect the string "Dialup IP
>connected" to appear after sending the password, but dudisc doesn't
>output it (at least it doesn't on my two systems and `strings' didn't
>find it).  To work around this, I put together this little hack, which
>should be built and run as the login shell instead of the hard links
>created by `duinstall':

It looks like dudisc tries to spits out a message like:

	DialUpIP 1.0 910613 connected to "slip0"

but is does so AFTER it has switched the line discipline to the SLIP
line discipline.  I'll try to fix this.

Rather than hack a small program, you might just consider hacking on
the scripts.  The scripts provided are very much just samples and not
intended to be the last word on how things are supposed to be done.
You might just have your script look for the echo of the login or
password that you shove at it.

The "goal" of the scripts is to turn on the SLIP connection.  Once it
does that, it invoked the "go" command to start up the network
connetion on the NeXT.  

For a hardwired line, potentially you might have the single line "go"
as your script if the other end always has the serial connection in
SLIP mode.

One other point to keep in mind is that by default, the Inactivity timer
of the SLIP interface is 300 seconds.  This also applies to interfaces
that are "enabled" by using the dudisc program for dial-in connections.
You might consider increasing the timeout by using the duioctl program
right after you ifconfig the interface's address.

	/usr/dialupip/bin/duioctl slip0 SATIMEO 99999999

louie