brad@cayman.COM (Brad Parker) (08/23/88)
From article <Added.oX28P8y00UkT09DU8G@andrew.cmu.edu>, by >morgan@JESSICA.STANFORD.EDU: > Ah, the heart of the matter. To allow a Ethernet-attached MacII (or > MacSE) to communicate directly to a CAP-speaking Unix host, there are > two ways to go. If the MacII has an AppleTalk driver that puts out > AppleTalk-in-UDP packets, then it can talk directly to an unaltered > CAP. As far as I know this doesn't yet exist. Anybody working on > one? > The CAP code will not directly support the multiple, "ad hoc" gateways this solution creates. It could be changed to work with mac's speaking UDP encapsulated AppleTalk, but won't out of the box. The KIP0688 code does allow Ethertalk machines to access CAP servers, using the "washing machine" effect. The packets go in as Ethertalk and pop back out (the same interface) as UDP encapsulated AppleTalk. This also works with the GatorBox. -brad -- "What will you do when you wake up one morning to find that God's made you blind in a beautiful person's world and all those great recepies have let you down, and you're twenty and a half and you're not getting age where you go look for the boys 'says I love you lets get married and have kids." -Billy Bragg.
cck@cunixc.columbia.edu (Charlie C. Kim) (08/23/88)
In article <1367@cayman.COM> brad@cayman.COM (Brad Parker) writes: >From article <Added.oX28P8y00UkT09DU8G@andrew.cmu.edu>, by >>morgan@JESSICA.STANFORD.EDU: > >> Ah, the heart of the matter. To allow a Ethernet-attached MacII (or >> MacSE) to communicate directly to a CAP-speaking Unix host, there are >> two ways to go. If the MacII has an AppleTalk driver that puts out >> AppleTalk-in-UDP packets, then it can talk directly to an unaltered >> CAP. As far as I know this doesn't yet exist. Anybody working on >> one? >> > >The CAP code will not directly support the multiple, "ad hoc" gateways >this solution creates. It could be changed to work with mac's >speaking UDP encapsulated AppleTalk, but won't out of the box. > Actually, there's no "additional" gateways involved here. The situation is no different, w/r/t cap, than two unix hosts talking directly to each other via UDP encapsulated AppleTalk. However, in either case (UDP encap. macs or unix), one still needs a KIP based system to forward NBP lookups. The way CAP handles things for kip(udp encapsulated appletalk) is quite simple: send packet to bridge node for forwarding. Actually, there's a clause that says send packet to bridge node for forwarding. UNLESS we know the ipaddress of the appletalk node where we figure out the ipaddress of appletalk nodes by cacheing [<ipaddress>,<ddp node/network>] tuples from receives (at present only one tuple is cached). Often, the cached ipaddress is of a bridge (possibly the same as the bridge node), but it can be of an arbritrary host too. However, all this really does is eliminate some double hops. One major problem is that configuration is quite painful. One must specify: for ip: host ip address host broadcast address for kip (udp encap. appletalk) contents of atalk.local: appletalk network number, appletalk node number, appletalk zone bridge (appletalk) network number, bridge ip address for each and every such mac. (Actually, the appletalk number number and appletalk zone can probably be figured out). As we all know, this stuff is really easy to get right and is very robust in the face of a dynamic environment :-). I realize that this is a problem on the unix hosts too. The fairly recent advent of driver based UDP/IP implementations makes the proposal reasonable (in terms of work). The main reference document is "EtherTalk and Alternative ???" (something like that) available from APDA that outlines the design of EtherTalk and alternative LAP implementations. I'm 99% sure the mac side is doable, and if it is, the CAP side should be interoperable. I don't know if anyone is working on this. I'd be interesting in seeing it though. Charlie C. Kim Systems & Networks Group Center for Computing Activities Columbia University
liam@cs.qmc.ac.uk (William Roberts) (09/01/88)
The DYNIX 3.0 operating system for the Sequent machines (a version of BSD)
has some limited support for EtherTalk: according to the
documentation you can say things like
s = socket(AF_APPLETALK, SOCK_DGRAM, 0);
and it has descriptions of all the various LAP headers, DDP
headers etc. The physical addresses of EtherTalk Macs are
acquired by arp and stored in the relevant arp tables (confuses
/etc/arp though).
The bad news is it doesn't really work. In particular it
doesn't understand longDDP headers and so can only work with
short ones, no software is provided for setting the AppleTalk
address of the DYNIX machine etc. It is just a peg for some
third party software from Kinetics - ironic that all our
ETherPort II Mac IIs have Kinetics software that only ever
sends longDDP packets :-)
The task of receiving EtherTalk packets on your UNIX box isn't
too evil: the Sun Network Interface Tap (NIT) code would allow
you to do it without kernel hacking, even. If this message
doesn't help shame Sequent into fixing their implementation (I
have offered...) then watch this space for code: I need to
prevent our FastPath box from being a bottleneck and single point
of failure.
--
William Roberts ARPA: liam@cs.qmc.ac.uk (gw: cs.ucl.edu)
Queen Mary College UUCP: liam@qmc-cs.UUCP
LONDON, UK Tel: 01-975 5250