Problems with ISC SLIP and their reply: It don't work well.

Brad Isley bgi at stiatl.salestech.com
Sat May 25 00:53:57 AEST 1991


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 at 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.



More information about the Comp.unix.sysv386 mailing list