bgi@stiatl.salestech.com (Brad Isley) (05/24/91)
This is a summary of my conversations so far with Multiuser/Interactive regarding our problems with ISC SLIP delivered with TCP/IP 1.2. I hope several things will result from this posting. 1) Someone will be wiser. 2) Someone can help with our problem. 3) Someone will have an easier time getting as far as I did. 4) Interactive will fix their software. Please note the Reply-To: line above. Until I get Interactive's sendmail to work the way it's supposed to you are better off replying there. (It's a 3b1). emory!slammer!brad writes: >Eric Storch at Multiuser Systems wrote: > Brad, > > As per our conversation, here is the copy of the mail that I got back from > Interactive Technical Support: Thanx - replies to uunet!emory!slammer!brad work. I'm having sendmail problems that will be addressed in another note. - so please reply there for now. I have some additional notes and a reply for the folks at Interactive. I'm also posting this to Usenet comp.protocols.tcp-ip and comp.unix.sysv386. Someone out there might benefit or be able to help. emory!slammer!brad writes: >someone at interactive support wrote: >> emory!slammer!brad wrote: > ============================================================================= >> . >> . >> . >> I have an AST 386/33 running Interactive 2.2 >> Ethernet is a WD8003 with TCP/IP 1.2 and NFS 2.1. >> Serial ports are controlled by a Comtrol Ultra-8 with driver version 1.08. >> 12 megs RAM installed. Adaptec 1542B. Wangtek tape controller and drive. >> >> Everything is stable without SLIP. > >What port is SLIP running on? We don't support SLIP running on anything >but our standard asy ports. > *** Why is this not documented? Imagine the load on a system running SLIP on a builtin port running 38400 bps or even 19200 bps. I even called and asked if SLIP was supported on intelligent multiport boards and the answer was, "Yes." I even went as far as asking, "Can I use it as a gateway?" Same answer. Sorry - don't ask who I talked to. I don't remember. >> >> We're running SLIP and uucp to connect to Performance Systems >> International. The uucico will eventualy hang with an error message: >> >> news uupsi (5/13-9:00:52,172,31) IN SEND/SLAVE MODE (INPUT FAILURE) >> ... >Has the customer configured uucp over TCP/IP? How can you possibly run >a uucp process such as uucico over SLIP without first configuring UUCP >to run over TCP/IP? Yes. Thankfully this isn't a problem anymore. It was the result of a timeout caused by one of two things: 1) Remote modem hanging up. The hangup was cause when the remote modem choked on V.42BIS. I don't know what kind of modem it is. I told my TB1600 to connect in a non-error-correcting mode and no more hang-ups. PSI told me that they didn't support V.42BIS in this area yet. I assumed the modems could figure that out. I was wrong. 2) Default route mysteriously disappearing from the table. This one I think was due to SLIP coming up and down. A few minutes after adding the route it will disappear. Add it again and it stays. >> We have another problem that may be causing some of the uucico hangs. The >> TCP/IP we run does not seem to always route packets properly. After >> establishing the SLIP connection we add a default route through it. Lots >> of packets that should go out the SLIP wire do not. >> > >Again, we don't like to route data through a non-supported SLIP device. OK. So I should run SLIP on the builtin port. This brings the performance of the system (386 33mhz) to an unacceptable level. Why can't you support generic serial devices? Are you telling me that it cannot route packets properly? Or are you saying it cannot send packets properly? Please clarify. I'd like to think that routing decisions are made without detailed network interface knowledge. >> # @(#)_netd2.slip 1.1 89/07/13" >> # >> sl_ip = "/dev/sl" lsap 0x888 # stream for IP messages >> link sl_ip under ip_tcp name "sl0" >> #ifconfig "sl0" stislp uupsi netmask 255.255.255.0 up >> #ifconfig "sl0" stislp uupsi up >> ------------------------------------ >> The ifconfig for sl0 is commented out because at boot time the modem may not >> be connected to PSI. Connecting to psi is done with this shell script. > >SLIP isn't going to care that the modem is not connected. If you type >'ifconfig sl0' then it will still report that the device is there. All NFS daemons and some other TCP daemons crash with timeouts if the sldial & slattach aren't running when slip is ifconfig'd. This requires a reboot to make the system stable. Switching to runlevel 2 and back up to 3 after dialing sets the stage for a crash. >> After running the sldial and pressing ESC we then run >> /etc/ifc: >> ------------------------------------ >> set -x >> tty=`cat /etc/slip.tty` >> touch /usr/spool/locks/LCK..$tty >> slattach /dev/ttyu03 `cat /etc/slip.bps` >> addr=`cat /etc/slip.addr` >> ifconfig sl0 $addr $addr netmask 255.255.255.0 up >> #ifconfig sl0 $addr $addr up >> gated -tu /usr/adm/route.log > >Here's a MAJOR PROBLEM. SLIP does *NOT* work with a gateway! It is >logged as a bug. Okay, so what's the solution? TCP/IP 1.2 has been out for how long? How long should we wait for a fix? Re the manual "Interactive TCP/IP System Admin Manual" page 44 under section 6.2 Initiating SLIP Over Modem and Serial Lines, "If you are using one system to act as a gateway ... /etc/gated" According to Interactive documentation your gated performs routing decisions normally performed by routed. We DO NOT want it to act as a gateway in the sense that would function as an internetwork router. What we want is for it to have the smarts to figure out which device outgoing packets should be sent to. Users here want to rlogin to this machine. From there they should be able to access the Internet via SLIP. This seems to be working acceptably now. Ping looses many more packets than any other network application. >Why are there 0's in the hosts file? This will result in irradic network >behavior. Using 0's indicates a netmask not an IP address. >I would suggest him to change this soon. Sorry for this. I didn't set this up - but I WILL change it soon. No other machines have had a problem with it. Convergent CTIX, Sun-OS, DG-UX, HP-UX, PC-NFS, BW-NFS, NCSA Telnet, KA9Q, Wollongong on VMS, Banyan and even AIX 1.1, 1.2 and 3.1.5 are all happy with it. >> 127.1 local localhost >> 20.0.0.1 st640.salestech.COM st640 # Convergent 640 >> 20.0.0.3 huey.SalesTech.Com huey >> 20.0.0.4 louie.SalesTech.Com louie >> 20.0.0.5 dewey.SalesTech.Com dewey >> # Everything with the suffix pc are pc's >> 20.0.0.6 johnpc >> 20.0.0.7 johnpc1 >> . >> . >> . >> 20.0.0.207 vxdsh >> 20.0.0.208 vxdsi >> 20.0.0.209 vxdsj >> 20.0.0.210 vxdsk >> >> 128.145.107.101 uupsi >> 128.145.107.101 stislp.salestech.com stislp >> 136.161.128.3 uu.psi.com >> ------------------------------------ >> >> Our internal network at SalesTech is 20.0.0. We do not advertize our >> presence through PSI to the Internet. The machine this is running on, >> 'stiatl', is not used as a gateway to the Internet; I just run gated because >> the TCP/IP 1.2 documentation says gated does the routing instead of routed. >> Any user here must access the Internet directly from stiatl. >> >> After the 'route add default 128.145.107.101 1' command, most, but not all, >> packets that aren't addressed to the 20.0.0 network go out the modem. We have >> a line analyzer and watch them. Ping is quite useful here. If we ping the >> other end of the link, 128.145.107.101 or if we ping 128.145.107.127 (the >> address of the machine at the other end) the response is fine. Ping response >> is also OK from uunet.uu.net. However, if we ping 192.67.67.20 or 192.33.4.100 >> the first few pings go out the slip port, but subsequent pings do not. >> I assume the wd0 network gets them but I cannot tell. >> > >Are these addresses supposed to be reachable via ethernet or SLIP? Again, >the problem is probable trying to run gated with SLIP. This local network 20.0.0 is reachable only via ethernet. The Internet is only reachable from stiatl - see netstat output. >> Netstat says the default route is there. Technical support at PSI says it >> should work. Any ideas? [uucico hang notes deleted - problem solved] >> netstat -nr: >> ------------------------------------ >> Routing tables >> Destination Gateway Flags Refcnt Use Interface >> 127.0.0.1 127.0.0.1 UH 7 409 lo0 >> 128.145.107.101 128.145.107.101 UH 0 0 sl0 >> default 128.145.107.101 UG 3 63 sl0 >> 20 20.0.0.50 U 0 1166 wd0 >> ------------------------------------ >> >> netstat -r: >> ------------------------------------ >> Routing tables >> Destination Gateway Flags Refcnt Use Interface >> localhost localhost UH 7 409 lo0 >> port1.atlanta.pub-ip port1.atlanta.pub-ip UH 0 0 sl0 >> default port1.atlanta.pub-ip UG 3 69 sl0 >> 20 20.0.0.50 U 0 1290 wd0 >> ------------------------------------ >> >>> ping statistics: >> ------------------------------------ >> PING 128.145.107.101: 56 data bytes >> 64 bytes from 128.145.107.101: icmp_seq=0. time=830. ms >> 64 bytes from 128.145.107.101: icmp_seq=1. time=760. ms >> 64 bytes from 128.145.107.101: icmp_seq=2. time=740. ms >> 64 bytes from 128.145.107.101: icmp_seq=3. time=760. ms >> >> ----128.145.107.101 PING Statistics---- >> 4 packets transmitted, 4 packets received, 0% packet loss >> round-trip (ms) min/avg/max = 740/772/830 >> PING 192.67.67.20: 56 data bytes >> 64 bytes from 192.67.67.20: icmp_seq=2. time=1350. ms >> 64 bytes from 192.67.67.20: icmp_seq=5. time=700. ms >> >> ----192.67.67.20 PING Statistics---- >> 12 packets transmitted, 2 packets received, 83% packet loss >> round-trip (ms) min/avg/max = 700/1025/1350 >> PING 192.67.67.20: 56 data bytes >> 64 bytes from 192.67.67.20: icmp_seq=0. time=690. ms >> >> ----192.67.67.20 PING Statistics---- >> 21 packets transmitted, 1 packets received, 95% packet loss >> round-trip (ms) min/avg/max = 690/690/690 >> PING 192.33.4.100: 56 data bytes >> 64 bytes from 192.33.4.100: icmp_seq=0. time=450. ms >> 64 bytes from 192.33.4.100: icmp_seq=1. time=490. ms >> 64 bytes from 192.33.4.100: icmp_seq=2. time=430. ms >> 64 bytes from 192.33.4.100: icmp_seq=3. time=450. ms >> 64 bytes from 192.33.4.100: icmp_seq=4. time=420. ms >> 64 bytes from 192.33.4.100: icmp_seq=5. time=420. ms >> 64 bytes from 192.33.4.100: icmp_seq=6. time=440. ms >> 64 bytes from 192.33.4.100: icmp_seq=7. time=440. ms >> 64 bytes from 192.33.4.100: icmp_seq=8. time=430. ms >> 64 bytes from 192.33.4.100: icmp_seq=9. time=430. ms >> 64 bytes from 192.33.4.100: icmp_seq=10. time=450. ms >> 64 bytes from 192.33.4.100: icmp_seq=11. time=430. ms >> 64 bytes from 192.33.4.100: icmp_seq=16. time=1350. ms >> >> ----192.33.4.100 PING Statistics---- >> 29 packets transmitted, 13 packets received, 55% packet loss >> round-trip (ms) min/avg/max = 420/510/1350 >> ------------------------------------ >> >> The thing to keep in mind wher reviewing the above ping stats: >> >> Sometimes all the pings would go out SLIP and the host failed to respond. >> Sometimes a few initially would go out SLIP, but then the rest would not. >> It seems that the router gets confused about where they should go. The last >> example (192.33.4.100) all the missing responses were due to the ping not >> going out the SLIP interface. >> >> One more question: We use the Internet nameservers when SLIP is up. I >> also setup a nameserver here on a Sun 4/470 that runs just fine. I was >> hoping this would allow users on stiatl to be able to find hosts both on the >> Internet and our local network with this setup. However, stiatl seems to >> only use the first /etc/resolv.conf nameserver address listed. It seems >> that if the first nameserver lookup request fails then the lookup will fail. >> But if the first host times-out it will proceed to the next one. Does the >> first host have to be all-knowing? Do I have to setup stiatl as a >> nameserver and have it pool the names from the Internet AND our local >> network for this to work? >> >> >> Of the several issues above I would like to enumerate them for reference: >> >> 1) Apparently routing is not always right. >> Packets destined for the SLIP gateway sometimes do not get sent there. >> What is wrong? > >SLIP does *not* work with gated (gateway). OK. When can I get one that works? If gated is not running then no packets at all go out the SLIP device. Ver 1.2 seems to work fine unless I'm checking on ping statistics. Ping looses a much higher percentage of packets than any other application. >> >> 2) Am I bringing SLIP up correctly? >> > >It should be done per the documentation. If I do it per the documentation (on the Comtrol port) the TCP software crashes with timeouts - "Cannot validate service." To solve this problem I commented out the ifconfig "sl0" in netd.cf. If the asy driver is used the remaining performance is abysmal and functionality is the same. I'll settle for the manual ifconfig for now and keep it on the Comtrol. It might not be "supported", but it works much better than the asy. >> 3) Should nameserver clients query all servers? >> 3a) If not, should I set up stiatl as a nameserver pooling both sources? >> > >Yes, but with SLIP? I don't know. SLIP has problems with running a gateway, >I havn't tried it with nameservers, mainly because I can't get it to work >with a gateway. I guess the solution here is to put up a nonauthoratative nameserver on stiatl. I'll try that. >> 4) Why does uucico fail? >> 4a) Why does uucico hang in the job table while running over SLIP? >> 4b) Why do subsequent uucico's get nowhere? >> > >Has UUCP been setup to run over TCP/IP? Problem solved. As long as the connection is alive and the default route out the SLIP connection doesn't disappear from the table it works fine. >The last thing, we *don't* support SLIP running over multiport cards. >It has hooks in it specifically for our asy driver. I strongly suggest that your SLIP be "fixed" so that is works with generic tty drivers for reasons enumerated above. Other 386 unixes I know of have no problems supporting 16 simultansous SLIP connections as gateways. The only difference I noticed between asy and comtrol is the time-outs and subsequent daemon crashes cause by no connection at startup with comtrol. This is fixed with the manual ifconfig. >> ============================================================================ >> >> An update to the previous mail. >> I installed the 2.2.1 update and nothing has changed much. ... [ deleted notes that are covered above ] >After he fixes a couple of those things his network should be ok. Except for the fact that gated does the routing and does not always work. >good luck, >Interactive support > > -- > MULTIUSER Systems > Technical Support > ...!isd001!support I do appreciate your help with this but to be frank the only information that has helped is the fact that SLIP with gated is buggy and SLIP is only supported on asy. Just knowing that helps in that I know I cannot fix it and I'm not doing something completely wrong. I now know gated's limitations and I know what causes TCP timeouts/crashes when the SLIP modem hangs up. To summarise: I know why it doesn't work. Now I need to know when it WILL work. Anxiously awaiting a fully functional TCP/IP package... -- -----------------------------\ / ..and Apple thought GUI was theirs!.. \ bgi@salestech.com 841-4169 \---| Yer local zymurgist & Amiga hacker/user | OR \ Klein bottle for sale- Inquire within / uupsi!stiatl!bgi Brad Isley, Sales Technologies, Inc.
larry@nstar.rn.com (Larry Snyder) (05/25/91)
bgi@stiatl.salestech.com (Brad Isley) writes: >>What port is SLIP running on? We don't support SLIP running on anything >>but our standard asy ports. >> *** >Why is this not documented? Imagine the load on a system running SLIP on >a builtin port running 38400 bps or even 19200 bps. I even called and >asked if SLIP was supported on intelligent multiport boards and the >answer was, "Yes." I even went as far as asking, "Can I use it as a gateway?" >Same answer. Sorry - don't ask who I talked to. I don't remember. We've run SLIP on both a Digiboard 8i and a dumb ASY port with a 16550AFN at speeds of 38400. Throughput on the Digi is higher than the ASY port. Throughput averages around 1780 cps running UUCP over SLIP using v.32bis modems. >modems could figure that out. I was wrong. 2) Default route >mysteriously disappearing from the table. This one I think was >due to SLIP coming up and down. A few minutes after adding the >route it will disappear. Add it again and it stays. yep - we've noticed this when bringing SLIP up and down - thank goodness we don't go up and down all day long! >All NFS daemons and some other TCP daemons crash with timeouts if the sldial >& slattach aren't running when slip is ifconfig'd. This requires a reboot to >make the system stable. Switching to runlevel 2 and back up to 3 after >dialing sets the stage for a crash. yes - for sure We are planning on moving over to Dell SVR4 3.0 when it is released for our primary gateway. Dell is constantly working on the product - and their 2.01 release is quite solid. The ability to support multiple concurrent SLIP connections is quite appealing -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
Larry.Snyder@sunbrk.FidoNet.Org (Larry Snyder) (05/26/91)
bgi@stiatl.salestech.com (Brad Isley) writes: >>What port is SLIP running on? We don't support SLIP running on anything >>but our standard asy ports. >> *** >Why is this not documented? Imagine the load on a system running SLIP on >a builtin port running 38400 bps or even 19200 bps. I even called and >asked if SLIP was supported on intelligent multiport boards and the >answer was, "Yes." I even went as far as asking, "Can I use it as a gateway?" >Same answer. Sorry - don't ask who I talked to. I don't remember. We've run SLIP on both a Digiboard 8i and a dumb ASY port with a 16550AFN at speeds of 38400. Throughput on the Digi is higher than the ASY port. Throughput averages around 1780 cps running UUCP over SLIP using v.32bis modems. >modems could figure that out. I was wrong. 2) Default route >mysteriously disappearing from the table. This one I think was >due to SLIP coming up and down. A few minutes after adding the >route it will disappear. Add it again and it stays. yep - we've noticed this when bringing SLIP up and down - thank goodness we don't go up and down all day long! >All NFS daemons and some other TCP daemons crash with timeouts if the sldial >& slattach aren't running when slip is ifconfig'd. This requires a reboot to >make the system stable. Switching to runlevel 2 and back up to 3 after >dialing sets the stage for a crash. yes - for sure We are planning on moving over to Dell SVR4 3.0 when it is released for our primary gateway. Dell is constantly working on the product - and their 2.01 release is quite solid. The ability to support multiple concurrent SLIP connections is quite appealing -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry} * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)