Path: utzoo!dciem!nrcaer!scs!spl1!quintro!kts From: kts@quintro.UUCP (Kenneth T. Smelcer) Newsgroups: comp.sys.apollo Subject: Re: TCP/IP 3.1 hangs on rsh Message-ID: <614@quintro.UUCP> Date: 28 Jul 88 16:08:33 GMT Article-I.D.: quintro.614 References: <5400029@iuvax> Reply-To: kts@quintro.UUCP (Kenneth T. Smelcer) Organization: none Lines: 38 In article <5400029@iuvax> jec@iuvax.cs.indiana.edu writes: > > I have a script that I run that tries to do a rsh on each apollo >from the VAX (Ultrix 2.2) in order to determine if TCP/IP services are >functioning. The problem is that sometimes (not always), the rsh will >hang forever. I do a: > > % rsh io.cs.indiana.edu /bin/echo UP > > and it will sit there for tens of hours. I've noticed that it only >seems to occur on diskless nodes. I'm running SR9.7, Domain/IX 9.5, TCP 3.1, >and the nodes boot from DSP90s with 3MBs, (one of the DSP90's is the gateway, >but the other is a typical node in the network). We have had the same problem talking to nodes within our Apollo network. On our system, (6 DN3000's and a DSP90 server) both rsh and rlogin have the same problem. rlogin will try for a while and then return an "error 0" message and rsh just hangs forever. If you kill the request (^C) and try again, the request always goes through. I talked to Apollo service when we first saw this problem (when we installed SR9.7 with TCP3.0), and they said it was a problem with the routing tables. After some length of time, the routing table would seem to be out of date, and therefore the request would fail. However, that request would update the table, so the next rsh or rlogin would work just fine. I was told the problem was a known bug with SR9.7 and TCP 3.0 and was supposed to be fixed in 3.1. Well, it doesn't happen as often as it used to, but it is still a problem. I would also be interested in any ideas on a work-around or fix for this problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corporation - Quincy, Il. UUCP: {elroy,lll-winken,laidbak}!spl1!quintro!kts or uunet!wucs1!wuibc!quintro!kts