Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!psuvax1!julius.cs.uiuc.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncr-sd!simasd!jadpc!jdeitch From: jdeitch@jadpc.cts.com (Jim Deitch) Newsgroups: comp.unix.sysv386 Subject: Re: ISC 2.2 and SLIP have some pretty major problems! Message-ID: <1990Nov10.035405.741@jadpc.cts.com> Date: 10 Nov 90 03:54:05 GMT References: <1990Nov09.064033.8282@ddsw1.MCS.COM> Followup-To: karl@ddsw1.mcs.com Organization: Network Engineering Technologies Lines: 134 In article <1990Nov09.064033.8282@ddsw1.MCS.COM> karl@nis.naitc.COM (Karl Denninger) writes: >In article <1990Nov09.011135.18395@ddsw1.MCS.COM> kdenning@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@ddsw1.MCS.COM, !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@nosc.mil INET: jdeitch@jadpc.cts.com