cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (12/30/87)
Does anyone have the specification for EtherTalk? In particular, I am looking for the specification for EtherTalk ARP (protocol type 0x80f3). As far as I can determine, it is pretty close to standard IP ARP (0x806) with some extensions. So far, I have: 1 bit16 hardware_address_format (ETHER:1) 2 bit16 protocol (EtherTalk:0x809b) 3 bit8 hardware_address_length (6 for ethernet) 4 bit8 protocol_address_length (*) 5 bit16 opcode (appletalk_request-not sure about this:3)(**) 6 bit8[6] source_hardware_address 7 bit8[4] source_protocol_address (*) 8 bit8[6] destination_hardware_addr 9 bit8[4] destination_protocol_addr(*) 10 bit8[22] ???? (zeros then 0xc7, 0xdf, 0xfd, 0x28) * - looks like it uses 4 bytes for the <network,node> with a leading zero byte. However, one of the bytes could be a socket? ** - standard was 1: arp request, 2: arp reply. 3 seems to be a appletalk request/probe. In particular, I am interested in the definitions for 5 and 10 above. EtherTalk packets are straight forward enough: they are simply encapsulations: lap dest, lap source, lap type, data. Charlie C. Kim User Services Columbia University
tappan@MIKEY.BBN.COM (12/30/87)
5 is the same as IP ARP if Request or Response. They've added a 'Probe' opcode, which is 3. The machine sends out Probes to do the dynamic address establishment. You respond to a Probe on your own address with a Response. I don't know why they couldn't just use Request. I think 10 is just padding.
cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (12/30/87)
I'm not sure if my response made it out, so I'll repeat it with some new information. I think I've got AARP (Appletalk Address Resolution Protocol) pretty much figured out. I forgot that Ethernet packets are supposed to be at least 60 bytes (actually 64 - 60 bytes + crc: however, the crc bytes are not included in the packet length though some drivers use a minimum of 64 bytes in error). Those last 22 bytes are result from the padding. The rest of the stuff is really simple after that. You have three opcodes: 1 - ARP Request 2 - ARP Reply 3 - ARP PROBE I have had these confirmed by several people (thanks for the responses). Request and PROBE are answered with a Reply and are essentially the same. I would guess that the different opcodes are used to allow one to tell if the person really thinks the Appletalk address he encodes in the source protocol address is his or not: on a request he really does and if it is yours too, then you have a "duplicate <appletalk address>" error while on a probe you know he is just asking if it is in use. Request and PROBE use all zeros for unknown ethernet addresses (not all ones - I'm pretty sure a lot of IP arps use all ones) and am not sure if all ones is legal for unknown ethernet addresses. PROBE is used on EtherTalk startup to establish its AppleTalk address. Several people have commented on the fact that Apple don't use IP ARP packet type 0x0806 (using 0x80f3 instead). Add me to the list. The only reason I can think of is that some ip arp implementations don't pay attention to the protocol type in the arp packet and accept the them as IP ARPs with the resulting "bad" effects (or apple thought this might happen and did it because of that). The four bytes of protocol address do end in the node address. I've received some information about the first three bytes, but I am not sure if I can release this information. The reason all this came up is that we finally got Ultrix DECNET 2.0 and it contains support for receiving and sending Ethernet packets (DLI facility) on a per protocol type basis. (Unfortunately (and not suprisingly), the design allows only a single process to receive packets for a particular protocol (and it must run setuid 0): to allow one to build in EtherTalk support, one would have to either write an AppleTalk bridge/gateway that supports EtherTalk and KIP and/or write a network daemon (for each machine) that would demux the incoming EtherTalk packets and send to the clients via some "defined" mechanism). In any event, the point was to do some baseline testing to see if anything were possible. It seems to be possible, but going on from here is a lot of work. Charlie C. Kim User Services Columbia University
mithomas@bsu-cs.UUCP (Michael Thomas Niehaus) (03/16/88)
I am looking for any information that anyone has on the EtherTalk network for
Macintoshes. Also, does anyone know if the AppleShare PC software would support
a EtherTalk (Ethernet) board. What board would I need? How about Kinetics
FastPath? Since we would need one to use printers and Apple IIGS's on the
network anyway...
I appreciate hearing from anyone who has experience in handling any type of
a system that uses the AppleTalk protocols on a network that is faster than
LocalTalk.
Thanks,
Michael Niehaus
Ball State University
UUCP: ...!{uunet,pur-ee,iuvax}!bsu-cs!mithomas