ISC 2.2 and SLIP have some pretty major problems!

[Jim Deitch]

In article <1990Nov09.064033.8282 at ddsw1.MCS.COM> karl at nis.naitc.COM (Karl Denninger) writes:
>In article <1990Nov09.011135.18395 at ddsw1.MCS.COM> kdenning at nis.naitc.com (Karl Denninger) writes:
>>
>>We are having a hell of a time getting this to work.
>>
>>Here's the deal:
>>	We have one machine which has a bunch of Telebit 2500's.  We would
>>	like anyone to be able to log in under SL/IP that has the
>>	appropriate login id and password.
>
>I have basic functionality (including routing dynamically using gated).
>There are a number of problems with the stock setup, which I'll go into in a
>moment.
>
>Here's the remaining problems:
>
>>	The problem is twofold:
>>		1) The system requires a system name when you set up SL/IP.
>>		   The problem, of course, is that I don't KNOW what which 
>>		   system will call!  ARGH!  
>
>This is still a problem.  There is a TCP/IP address to set here, and how is
>one to know what it will be until the connection is made?  There has to be a
>way to do this intelligently... if not, it's time to hack some code...
>
>I >could< tell people to all use the same address.... but then I am limited
>to one SLIP connection (I may be limited to one at a time anyway by ISC's
>software)
>
>>		2) It also wants a line name (ie: /dev/ttyxx).  Again, what
>>		   if I have a bunch of lines on a rotary?!  Grrrrr...
>
>This turns out to be a non-issue... it doesn't really need to know the line
>you come in on, or at least I can't see where it actually uses the
>information you give it.
>
>However, some problems remain:
>
>1)	/etc/gated doesn't recognize when the interface comes back up after
>	a connection is dropped.   This stinks; I want the system to
>	automatically reestablish the routing tables (I think this is a
>	rational requirement).  As things sit now even a "ifconfig sl0 down"
>	followed by "ifconfig sl0 up" doesn't reprime /etc/gated; you have
>	to kill and restart it before it will realize that the interface is
>	back online.  This is horrible!  It also does NOT happen with the
>	"real" interfaces.  An attempt to tell gated that both the real
>	ethernet board and the SLIP port were "passive" interfaces failed
>	with no diagnostic message (ie: /etc/gated just exits if I do this
>	with no indication of why, even in "-t" mode).
>
>	Note that it >does< correctly recognize when the line goes down and
>	deletes the routes that were established.  And also note that it
>	works as designed with real ethernet boards.
>
>	Having to stop and restart /etc/gated manually everytime I start up
>	a SLIP connection makes dynamic routing nearly impossible to deal
>	with.
>
>2)	The IP number is a REAL problem.  This is especially bad if I want
>	to support more than one SL/IP connection at a time.  Then again, it
>	appears that ISC doesn't handle that anyway, so perhaps it's no big
>	deal.
>
>3)	sldialup is a horrible botch; I need to redo that.  In addition to
>	this, there is no mechanism to check and see whether a connection
>	has been idle for any amount of time; that is also needed.  You see,
>	if you dial out on a non-modem control port, and the other end hangs
>	up on you, sldialup stays "online" forever!  Also, sldialup needs to
>	learn how to do locking with UUCP and the like.  Hack time here!
>
>4)	Don't even >think< about starting SLIP if you have the NFS server 
>	running (on 2.2); the result of doing this is that none of the 
>	programs for NFS register with the portmapper, and you can't export 
>	any filesystems!  You can, however, mount filesystems from another
>	machine (if you don't mind the nasty messages from the system when
>	the registration fails for the server side).  I tried to cheat, and
>	disable the slip interface while NFS was being loaded -- this ended 
>	with a COMPLETELY locked machine when lockd started.  Without 
>	lockd I can get both NFS server functionality and SLIP, however, 
>	that leaves me without file locking.  ARGH!
>
>	(Be especially careful if you play with this; one result here was
>	that I had to boot from floppy and hack the startup files to get the
>	machine to come back up!)
>
>	In line with this, DONT screw up when you configure SL/IP.  If you
>	fail to enter a valid IP address or hostname for the SL/IP
>	connection, and have NFS started, you'll ALSO end up with a
>	permanently locked machine (and much hair-pulling to get it back
>	online)
>
>5)	I'd >love< a way to determine when a connection is opened (or tries
>	to open) so I can write a little daemon that calls up a given site 
>	and starts SL/IP with it.  The uses for this should be obvious.
>
>Does anyone have good (or even bad :-) suggestions?  I really don't want to
>dedicate modem(s) and phone lines to this; if I didn't care then I'd just do 
>it the easy way and get a PC-based router and perform the connection that
>way.  As it is I can't do that.
>
>Is it time to start hacking on the kernel driver(s) for this one?  Does
>anyone have the requisite code (or something close) to make this easier than
>starting from scratch?  I would think that something that is STREAMS based
>would be necessary.
>
>Comments and suggestions welcome...
>
>--
>Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
>Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
>Macro Computer Solutions, Inc.   "Quality Solutions at a Fair Price"

Karl,
  Where the hell have you been?  ISC has a shell, like uucico, called
/usr/ucb/sllogin that will allow a user to login and start a slip
session.  When the modem hangs up it will drop the connection and be
ready with getty for whatever comes it's way.

I agree about sldialup, try sending a break, using control b as they
suggest in the manual, and watch what happens.  You are left standing
there with a non connected slip because you exited right back to the
shell.

Maybe you should RTFM all the way through.  I had slip up and going
just fine here with 4 machines calling in in about 4 hours, and I am
no rocket scientist.

Jim

-- 

UUCP: nosc!jadpc!jdeitch
ARPA: jadpc!jdeitch at nosc.mil
INET: jdeitch at jadpc.cts.com