Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!rpi!julius.cs.uiuc.edu!psuvax1!rutgers!aramis.rutgers.edu!athos.rutgers.edu!hedrick
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Newsgroups: comp.protocols.appletalk
Subject: Re: Need help building Rutgers CAP on SunOS 4.1
Message-ID: <Oct.4.17.22.32.1990.21121@athos.rutgers.edu>
Date: 4 Oct 90 21:22:34 GMT
References: <1644@cnca.cnca-cam.fr>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 52

First, I apologize for not having the encaps symlink installed
automatically.  You did right: it should be linked to ethertalk 
if you're using the ethertalk configuration.

I believe you built things correctly.

Your test results, except for atistest, are all consistent with a
correctly operating CAP that simply has nothing on the network to talk
to.  If everything else on the network is using phase II, that is
indeed the case.  The CAP version at Rutgers currently supports only
phase I, because it is based on the UAB Ethertalk code, and that only
supports phase I.  I do hope to do phase II, but it's like to be a few
months.  Among other things, I currectly have no documentation on the
differences between phase I and II.

Note that the configuration you're talking about, which is native
Ethertalk (i.e. not UAB) gets the network number dynamically from the
network, by looking at RTMP packets.  I believe this is the official
Apple way of finding your network number.  If you aren't hearing any
routers, then you won't ever get a network number.  That's the reason
for all the 0's.  Rocky Patel (who is really our Appletalk maintainer
-- I did the Ethertalk work, but don't normally work with CAP) is
probably going to put in an option to let you specify a network
number, for situations where there is no router on the network.

A later posting gives patches that one site found necessary because
atis wasn't getting the right information from their routers.  Atis
handles all the dynanimc stuff.  It acquires both the network number
and the address of the default router, based on the most recent RTMP
packet.  I believe the code is correct as distributed, and seems to
work here with a variety of routers.  But if you're having problems,
there's nothing wrong with hardwiring both the network number and
default router.  Probably the best way to do that would be to run atis
with listening to RTMP disabled, and make aarpd set up the network
number and default router.  To do the latter, in
lib/cap/aarpd/aarpd.c, right after

  this_node = etalk_mynode(&id);

add

 {
  AddrBlock addr;

  addr.node = <default router node number>;
  addr.net = <net number>;
  SetMyAddr(&addr);
 }

You can pass the router node number and net number as arguments to
aarpd or read them from /etc/atalk.local.  The latter is cleaner, but
would require more work.