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