karl@ddsw1.MCS.COM (Karl Denninger) (11/09/90)
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, <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"
jdeitch@jadpc.cts.com (Jim Deitch) (11/10/90)
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, <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@nosc.mil INET: jdeitch@jadpc.cts.com
sl@van-bc.wimsey.bc.ca (Stuart Lynne) (11/10/90)
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. >> >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. If the only reason you don't want a pc-router is that you don't want to have to double up your phone lines; and you have a few spare serial lines on your host; how about simply hooking your pc-router up to them. Have a special "shell" program that once a slip user log's in, simply connect's the two ports (the one he is dialed into and a free port to the pc-router) together. A simple C program to do that shouldn't take long to write. We have been using SCO Xenix TCP/IP and SLIP for about a year and a half. And just recently converted to pc-routers to do SLIP. The subjective analysis is that I will NEVER EVER attempt that again. Our site is MUCH happier now. Tonight we see if the latest ka9q with ppp and compressed headers helps improve connectivey. I wonder how long it will be before I could get that from any of the major 386 Unix vendors :-) I would stronly suggest that you use PC-Routers, either do-it-yourself with ka9q or off the shelf. Even if you have to have some awful hack (such as described above) to hook it up. You will reduce your headaches tremendously. The current crop of SLIP drivers on 386 unix platforms is old, buggy, unreliable, etc. It also tends to exacerbate problems in the TCP/IP implementations (the implementors usually didn't envision connections with 10-15 second response times, often timing out in 1 second or less, etc). -- Stuart Lynne Unifax Communications Inc. ...!van-bc!sl 604-937-7532(voice) sl@wimsey.bc.ca