[comp.protocols.appletalk] problem with CAP6.0 -- bogus node

jude@nas.nasa.gov (Jude A. George) (06/09/91)

I am having a rather bizarre problem with CAP.  No matter what machine I run
it on, the server programs always think they are on node 57.  I've compiled
the software on two Sun 4's and one SGI Iris, alternately using IPTalk and
"native" Ethertalk (the latter only on the Suns).  I get identical results
each time.  None of the machines have 57 as the last byte of their IP address.

I always get the following message from getzones, atlook, and aufs:

abInit: [ddp:  55.03, 57] starting

Aufs fails to SrvrRegister with atis.  Interestingly enough, the aufs server
shows up when I use InterPoll on a Mac on the other side of the bridge.
Of course, it shows up with the bogus node number 57.  The server also
appears in the Chooser, but the Mac is unable to open a connection to it.

Getzones and atlook show nothing; they print the above message, then
"Looking for =:=@* ...", then quit after a few seconds.

Here is one of my atalk.local files, for a machine with IP addr 129.99.33.185:
(I've also tried putting quotes around the zone name)

# mynet mynode myzone
55.3 185 NAS/N258
# bridgenet bridgenode bridgeIP
55.3 80 129.99.33.80

"55.3" maps to "14083" when viewed by InterPoll.  The bridge is a Kinetics
fastpath running K-STAR IP.  I'm not sure what version it's running...
the FastPath manager doesn't say.  But I don't think the problem is with the
bridge.

Has anyone had similar problems?  Am I missing the obvious?

Jude George
jude@nas.nasa.gov

dhb@maths.qmw.ac.uk (David Burgess) (06/10/91)

Jude George (jude@nas.nasa.gov) writes:

----- Begin Included Message -----
[...]

I am having a rather bizarre problem with CAP.  No matter what machine I run
it on, the server programs always think they are on node 57.  I've compiled
the software on two Sun 4's and one SGI Iris, alternately using IPTalk and
"native" Ethertalk (the latter only on the Suns).  I get identical results
each time.  None of the machines have 57 as the last byte of their IP address.

[...]

----- End Included Message -----

I had a similar problem  where aarpd came back with node number 213 all
the time. Situation: CAP6.0, not many of patches applied, Sparc2, native
ethertalk, no bridges anywhere.

Using the Sun etherfind (on another machine) I came to the conclusion
that the CAP sun wasn't putting out any appletalk packets when aarpd was
run. But I could set up lwsvr, and this was seen by Macs.

Ok, so this isn't a solution, it's another problem. (Sorry World.)
But maybe the problems are related.

David Burgess
Astronomy Unit, Queen Mary and Westfield College, London.