Path: utzoo!utgpu!watserv1!watmath!att!att!bu.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!CAYMAN.COM!josh From: josh@CAYMAN.COM (Josh Littlefield) Newsgroups: comp.protocols.appletalk Subject: Re: One way AppleTalk? Message-ID: <9011031753.AA00981@saba.Cayman.COM> Date: 3 Nov 90 17:53:13 GMT References: <858@casbah.acns.nwu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 >> > I've run across a strange problem with our company's AppleTalk networks. >> > I've got a guy installing a Shiva Fastpath 4 several states away who is >> > having problems seeing devices within certain zones that are local to me. >> > He sees the zone names, but he can't see any devices in them. We've used >> > InterPoll to confirm this (scanning for several minutes). >> > >> > We are running a Phase 1 network. >> >> Very interesting. I'm currently struggling with similar problems, only in >> my case all my FastPath 4 boxes work fine. Instead, I'm having this same >> problem with Shiva NetBridges, a TurboBridge, and IPTalk/atalkad-tunneled >> Gatorboxes! [...lines deleted...] >> There must be something going wrong with the NBP Broadcast Request and >> zone-wide NBP Lookup broadcast mechanisms used to locate devices in zones. Sounds like a you are suffering from a Phase 1/2 incompatibility. Although you are not running Phase 2 EtherTalk, your new NetBridge may be running Phase 2 LocalTalk. For LocalTalk, there are indeed changes associated with Phase 2. Mostly it is in the form of the RTMP packet, which can now describe extended networks on the AppleTalk internet, and which was designed to be backward compatible. However, one additionally change was the addition of a the NBP Forward Request packet. A router receiving an NBP Broadcast Request turns it into an NBP Forward Request (instead of the old-style NBP Lookup directed broadcast) and sends it on. The last router is supposed to turn it into an NBP Lookup broadcast. But if the last router is a Phase 1 Hayes Interbridge, it won't work correctly. The FwdReq packet, whose DDP destination addr is (net N, node 0) will be dropped. The fact that the older Shiva NetBridge has no trouble, but the newer ones do would reinforce this guess. As for the GatorBox, we will generate a Forward request if the outbound interface is Phase 2, and a directed NBP Lookup instead if the interface is Phase 1. Release 1.5.0 always set our LocalTalk interface to Phase 2. Our latest releases (1.5.1 and now 1.6.0) allow LocalTalk to be set to Phase 1. We consider atalkad tunnels to be Phase 1 and GatorBox point-to-point tunnels to be Phase 2. >> I wish I had a LocalTalk protocol analyzer to investigate this problem in >> more detail, but I don't (we have one on order). You may be interested in trying Watch. Watch 1.6.1 is available for anonymous FTP from cayman.cayman.com (192.31.222.1) in ~ftp/pub/Watch/watch.1.6.1.sit.hqx. Watch will capture packets on either LocalTalk or Ethernet (although it only supports a few Ethernet cards). It does a pretty good job of protocol decoding and may help analyze your problems. I use it instead of a LocalTalk sniffer and am pretty happy with it. It is unsupported, but freely available. Constructive criticism is always welcome. Hope this helps. -josh ------------------------------------------------------------------------------ Josh Littlefield Cayman Systems, Inc. Engineering University Park at MIT josh@cayman.com 26 Landsdowne Street (617) 494-1999 Cambridge, MA 02139 ------------------------------------------------------------------------------