Path: utzoo!attcan!uunet!husc6!mailrus!ames!pacbell!varian!kinetics!minshall
From: minshall@kinetics.UUCP (Greg Minshall)
Newsgroups: comp.protocols.appletalk
Subject: Re: Using KIP or KSTAR
Message-ID: <629@kinetics.UUCP>
Date: 16 Sep 88 17:20:30 GMT
References: <3647@Portia.Stanford.EDU>
Distribution: na
Organization: Kintics, Inc., Walnut Creek, CA
Lines: 47

From article <3647@Portia.Stanford.EDU>, by davef@Jessica.stanford.edu (David Finkelstein):
>...
> Be careful, though -- we have been unable to get two KFPS-4's in the
> same zone to work.  When the second box is booted, both boxes refuse
> to give out IP addresss (we are running KIP).  We're expecting new
> PROMs from Kinetics today (and a new version of KStar too) so I hope
> that solves our problem.  If you have problems with two boxes and not
> one (and you've sure you've configured correctly) you might give
> Kinetics a call.

There is one bad "real" bug in K-STAR and one bad "theoretical" bug
in K-STAR (K-STAR being the download module supplied with Kinetics'
FastPath 4).

The bad "real" bug is the one Dave Finkelstein mentions above:  it is impossible
to have more than one K-STAR (or one K-STAR and one KIP) box "in the same
zone" (which is to say: connected to LocalTalk networks which are in
the same zone).

The workaround for this bug is, clearly, to keep the LocalTalk zones unique.
We recognize that this workaround is not possible in all environments, and
*I* (having produced the bug) sincerely apologize for the inconvenience
(and confusion) this bug has caused.

The bad "theoretical" bug is that K-STAR may, in certain environments, reply
to the wrong DDP address when responding to "=:IPADDRESS@*" or
"=:IPGATEWAY@*" NBP Lookups.  What happens is that K-STAR responds to the
source address in the incoming DDP packet; what it should do is respond to
the address in the NBP-tuple in the incoming DDP packet.  The reason this is
a "theoretical" bug is that, in most cases, the two addresses are the same
(for an obscure reason having to do with how AppleTalk bridges have 
traditionally dealt with NBP Broadcast Requests).  However, it has come up
with one customer testing K-STAR with their own, in-house developed,
AppleTalk bridge (which deals with NBP Broadcast Requests in a slightly
different, and likely more conformant, manner than many current AppleTalk
bridges).

Anyone adversely affected by either of the two bugs mentioned above
should contact Kinetics technical support at (415) 947-0998 to get
in the queue for a fix.

Again, apologies for the bugs.

Greg Minshall
Kinetics, a division of Excelan Inc.		(415) 947-0998
2540 Camino Diablo
Walnut Creek, CA  94596