Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!stc!stl!dr
From: dr@stl.stc.co.uk (David Rutter)
Newsgroups: comp.sys.apollo
Subject: Re: TCP/IP host installation
Message-ID: <2836@stl.stc.co.uk>
Date: 5 Mar 90 18:15:55 GMT
References: <90Feb28.173809est.57401@ugw.utcs.utoronto.ca>
Sender: news@stl.stc.co.uk
Reply-To: "David Rutter" <dr@stl.stc.co.uk>
Organization: STC Technology Limited, London Road, Harlow, Essex, UK
Lines: 41


>The problem is that I can't get the other (non-gateway) nodes in the network
>to telnet to computers outside the primary domain ring.  It can successfully
>telnet to the gateway node, though.

We have the same problem. We are running sr 10.1. The Apollo helpline 
suggested installing patch 28 (ethernet-microcode) but this didnt help. 

By looking at the USE field obtained from the command /usr/ucb/netstat -r, we
found that when non gateway Apollo nodes attempt to connect to a Unix machine
on the ethernet, the tcp/ip packets are forwarded by the gateway and received
by the Unix machine. However, the reply from the Unix machine does not get 
forwarded through the gateway. 

(We also found that the USE field obtained from /usr/ucb/netstat -r does not 
always work - the USE count sometimes remains at zero even when we know 
packets are being forwarded through the gateway)

By running the routing demon in the foreground on a Unix machine, we found
that the routing demon on the Apollo gateway successfully forwards details
of our Apollo token ring to other Unix machines on the ethernet. However
it does this only once. It does not rebroadcast this information every few
seconds and so the routing information soon gets deleted from the Unix
machines routing tables.

We tried to manually add a route to the Unix machines routing tables using
/etc/route. When this was tried on a sun running routed, it worked for a few
days and then stopped. /etc/route was successfully used on a Unix HP machine
which wasnt running routed.

Even if /etc/route did work, because of the size of our network, this is not
an acceptable solution. Apollo has as yet not come up with an answer.

A few weeks ago someone posted to the net that they had installed a patch
that solved a similar problem. I dont think they mentioned the patch number.
I would be grateful if they could reply to this message. Was it the patch 28 
that we installed or another one that our Apollo branch doesnt know about?


David Rutter 
dr@stl.stc.co.uk