ChaosNET information

CHAOSNet is a local-area network technology that was developed along with the Lisp Machine project at the MIT Artificial Intelligence Laboratory. In fact, the Lisp Machines (as far as I can tell) initially depended on networking for their main file system; the local disk was initially used for microcode and "world" storage, and a virtual memory paging store, but only later was local file system support developed. It seems even after the Lisp Machine File System (LMFS) was developed, that the operating system sources were stored in the AI server running ITS.

Any emulation of the Lisp Machine environment is therefore going to involve an emulation of the CHAOS networking.

Bjorn Victor has documented emulated ITS support for tunneling Chaosnet packets over UDP. He has also discussed support for Chaos addresses in BIND. RFC 1034 mentions Chaos name records for DNS, although I'm not sure that is relevant to up-to-date DNS service.

Chaos FILE protocol documented here (local copy here)

Apparently, SYSDOC;CHAORD was an (early?) draft by David Moon of the Chaos AI Memo. (ITS hosted, local copy)

CHAOS has a few "assigned numbers" associated with it, including ARP hardware type 5, Ethertype (hex) 0804. I suppose that only helps if I want to or want to open a socket on a UNIX machine with a Chaos network driver, or send actual Chaos packets over an Ethernet cable.

ChaosNET over Ethernet

Symbolics Lisp machines can communicate in Chaos protocol over an Ethernet cable. By using tcpdump -xx, one can observe the following packets being emitted. The configuration was as follows:
  • A MacIvory configured as Chaos|62003 (subnet 100 decimal, host 3), running Genera 8.3
  • Ethernet interface (as reported by the FEP command Show Ethernet Address) 08-00-07-5c-2e-e4
  • A Macintosh G4 iBook connected via a four-port Ethernet switch, running sudo -i 1.en0 -xx -vv -s 100
No other machines were defined in the Symbolics environment. TCP/IP software was also not enabled. Note that the MacIvory board is actually controlling a NuBus ethernet card in the host Mac IIfx.

ARP on same subnet


Test one: execute the command Show Hosts chaos|62002 (i.e., host 2 on the same subnet 100 decimal). Presumably the MacIvory wants to send a STATUS packet, but does not know the Ethernet address; because the host is on the same subnet, it expects to be able to broadcast an ARP request on the Ethernet segment and get a response from the host.

23:09:34.090035 arp-#1 for proto #2052 (2) hardware #1 (6)

0x0000:  ffff ffff ffff 0800 075c 2ee4 0806 0001  ...............
0x0010: 0804 0602 0001 0800 075c 2ee4 0364 0000 ............d..
0x0020: 0000 0000 0264 003a f35c 4f12 0110 0001 .....d.:.O.....
0x0030: 0000 0000 0000 2041 4241 0800 5ae2 41f9 .......ABA..Z.A.

I believe this parses as follows
  • The six-byte destination address (all ones) is the broadcast address.
  • The six-byte source address is the Ethernet hardware address of the MacIvory host.
  • Hex 0806 is the two-byte length/type field indicating ARP . (reported as "arp"); this ends the Ethernet header
  • Hex 0001 is the two byte ARP hardware type for Ethernet (reported as "hardware #1")
  • Hex 0804 indicates the request is for the CHAOS protocol (reported in decimal as "proto #2052")
  • Hex 06 indicates the six-byte length of the hardware address (reported as "(6)" after the hardware type)
  • Hex 02 indicates the two-byte length of the protocol address (reported as "(2)" after the protocol)
  • Hex 0001 is the ARP operation code for "request" (reported as "-#1")
  • The next six bytes are the Ethernet address of the sender of the ARP request (the MacIvory in this case)
  • Hex 0364 is the protocol address of the sender of the ARP request (host 03, subnet hex 64)
  • The next six zero bytes indicate the target Ethernet address (unknown)
  • Hex 0264 is the protocol address of the target of the ARP request (host 02, subnet hex 64; i.e. octal 62002)
  • I haven't confirmed the calculation, but I believe the remaining bytes are 22 pad bytes (needed to reach the minimum 46 octets between the length/type and the FCS) The overall length of the packet is specified by 802.3 as "minFrameSize" (see Figure 4.6), listed in 4.4.2 as 512 bits or 64 octets. Figure 4.6 of 802.3 shows this includes the 12 bytes of address, the 4 byte FCS, the 2 byte length/type, leaving a minimum of 46 octets of data.
  • Hex 5ae241f9 would therefore be the 4 byte FCS "Frame Check Sequence" CRC, which is specified by 802.3 to be computed over the addresses, data, and pad. This would be the
STATUS for a different subnet

Test two: Show Hosts chaos|157255 (Octal 157255 is hex DEAD: subnet hex DE, host hex AD.)

23:21:23.866835 08:00:07:5c:2e:e4 > Broadcast, ethertype Unknown (0x0804), length 64:
0x0000:  ffff ffff ffff 0800 075c 2ee4 0804 0001  ...............
0x0010:  0600 adde 0000 0364 cf03 0100 ffff 5354  .......d......ST
0x0020:  4154 5553 0089 003a 6c7e 09e5 0110 0001  ATUS...:l~......
0x0030:  0000 0000 0000 2046 4845 0800 5d0c b9ef  .......FHE..]...

This is not an ARP request. My guess is that that the Symbolics expects some unknown station on the Ethernet to be accepting packets for Chaos address 157255, but because it isn't configured with a Chaos address on the local subnet known to be the bridge to subnet hex DE, it doesn't have a target Chaos address for which to issue an ARP. I'm not sure why it doesn't rely on that bridge to respond with a proxy ARP.

In any case, this gives us an opportunity to examine an ordinary Chaos packet over Ethernet.
  • Six byte broadcast Ethernet address
  • Six byte Ethernet source address
  • Hex 0804 is the Length/Type field assigned to CHAOS.
  • Hex 00 is the Chaos protocol byte
  • Hex 01 is the Chaos opcode "RFC"
  • Hex 0600 (Chaos words are least-significant byte first) is a four-bit forwarding count of zero (the high bits of the second byte) plus a Chaos data byte count of 6.
  • Hex ADDE is the "software" destination address, host hex AD on subnet hex DE
  • Hex 0000 is the (unknown) destination index
  • Hex 0364 is the "software" source address, host hex 03 on subnet hex 64
  • Hex cf03 is the source index of hex 03cf (to which the response to the RFC would be sent; that index should not be reused on the source until ample time has passed, to avoid collision)
  • Hex 0100 is the packet number 1
  • Hex ffff is the acknowledgement number
  • The six bytes of data "STATUS" (for an RFC packet, this is the "contact name", somewhat analogous to the TCP/UDP "well-known port", possibly followed by parameters describing the service being requested.)
  • There might be a Chaos checksum in here, or it might be just garbage padding until the last four bytes which I presume are the Ethernet FCS of hex 5d0cb9ef.

Some of the pad bytes are the same as the previous packet (actually, the initial packet was repeated several times; I suppose I should confirm whether all the repetitions are identical on the ether.) This might be due to re-use of the buffer, or coincidence. Actually, I should examine the packet buffer in the MacIvory memory.

Comments

Post a Comment

Popular posts from this blog

Open Genera VLM on Linux

There are some existing guides to setting up the (unauthorized) Open Genera VLM on x86-64 Linux, but I wanted to tweak them a bit, and came up with a couple of items that diverge from the existing advice. Note that a bunch of URLs on that link should point to https://archives.loomcom.com/  not the static.loomcom.com address. My general goals were to avoid having to run the genera binary as root, and run as a distinct user to have some sense of security (even if the sense is misplaced). I also wanted to change the network addresses, and don't want to use the standard pathnames for the Unix system files and the user directories, and the changes to do so were only in screenshots. My setup Ubuntu 18.04.4 LTS, amd64 My Linux machine is named ubuntu I want all this simulated Genera stuff to happen on  subnet 10.0.10.x  with my Linux host under the name  genera-ubuntu  at 10.0.10.1  and the virtual Lisp machine genera  at 10.0.10.2  (...
Read more

Restoring the Heathkit Jr 35

Image
Heathkit Jr Electronic Workshop "35", Model JK-18 The Heathkit Jr 35 evidently had been stored with batteries in the battery holder, which corroded badly. I replaced it with a plastic RadioShack 4 D-cell battery holder (270-389), wired into the negative power rail and the hot side of the power switch (which is part of the variable resistor). Corroded battery holder Replacement battery holder mounted I mounted the replacement battery holder with a dozen "heavy duty" 1 inch foam double-stick mounting squares (rated to hold 900g), stacked in four groups each three high to overcome the various screws protruding through the main board. The remote speaker station The rubber foot used to protect the relay from being crushed when you turn the kit over was stuck to the remote speaker station. I put it in its rightful place. Relay with the brown rubber foot Earlier, I had built a couple simple circuits, which showed the meter and new battery pack w...
Read more

FPGA selection for beginners

I'm not particularly expert on FPGAs, but I feel like sharing some of the thought process and research I did in getting into tinkering with FPGAs to help other people contemplating such things. Why FPGAs? FPGAs are the go-to solution for "digital things that can't be done with Raspberry Pi, Arduino, or other microcontroller plus software." If you want more than a handful of discrete digital devices in your project, an FPGA (or its smaller cousin, a CPLD) can be whatever collection of gates you need. From a more industrial perspective, they are a stepping-stone to the kind of large-scale digital design that goes into developing ASICs and high-powered DSP solutions. I'll probably discuss later some of the things that are probably not suited for FPGAs and assume for now you at least understand what they are, what they can do, and you just really, really want to use one. You want to buy an FPGA for good reasons and can't decide which: how to choose? Choo...
Read more