[comp.protocols.appletalk] KIP/CAP problem

farrell@EREBUS.STANFORD.EDU (Phil Farrell) (02/25/88)

Can anyone help me with this KIP/CAP problem?

I have three Vax 750s, all running 4.3BSD UNIX, call them A, B, and C.
A and B are connected to the same ethernet cable segment, which is
connected via a gateway to the cable serving C.  One year ago, I
installed a Kinetics FastPath (call it X) on the cable with A & B and
installed KIP code in it, using A as the atalkad server.  Then I added
a second FastPath (call it Y) on the same cable, again using A as the
atalkad server.  I am now running the kip 0987 version (supports zones)
and have installed CAP 4.0 with patches 5, 6, and 7 and bug reports
1-15.  I have atis, lwsrv, and efsd running on both A and B, pointing
them both to FastPath X in /etc/atalk.local.  I also use papif to spool
files from the Vaxes down to LaserWriters on both AppleTalk nets.  This
all works great.

Now the problem.  I installed another FastPath (call it Z) to connect
an AT net to the ethernet cable serving Vax C.  It uses A as its
atalkad server and comes up fine.  I gave all three AT nets the same
zone name, and chooser on any Mac shows the union of all LaserWriters.
Here is a picture of the final setup:

	      Vax A -----+			+----- Vax C
			 |			|
	      Vax B -----+			+----- FastPath Z ---- AT net
			 |--- Ethernet ---------|
AT net --- FastPath X ---+    Gateway		|
			 |
AT net --- FastPath Y ---+

I tried installing and running the CAP atis and lwsrv daemons on this
Vax C, pointing to the new "local" FastPath Z in the /etc/atalk.local,
and they don't quite work.  That is, the daemons run okay, but
/etc/cap/look on C does not see lwsrv, and the Macintosh on the
immediately connected AT net does not see the lwsrv process with
chooser.  If I tell atis on C to dump its tables, it has an entry for
lwsrv that looks okay.  The funny part is that Macintoshes on the more
distant AT nets, as well as /etc/cap/look on Vax A and B, (all on the
other ethernet cable) DO see this lwsrv process!

Next, I tried modifying C's /etc/atalk.local to point back to the
original FastPath X (on the other ethernet cable) and now, all of a
sudden, /etc/cap/look on C can finally see its own lwsrv process!
Anybody have any ideas about why CAP works with the more distant
FastPath but not the local one?  I could just run this way, but the
gateway between the two ethernets can be flaky, so I would rather have
the CAP processes on C using the local FastPath Z.

Thanks for any help.  Phil Farrell   farrell@erebus.stanford.edu