The ch11 device in KLH10 for ITS, which was originally just a dummy inteface to keep ITS running, is now a functional Unibus Chaosnet device, which tunnels Chaosnet packets over UDP. It does not support SPY (promiscuous) mode, LUP (loopback), or broadcast, but ITS doesn't seem to use/need these.

Why Chaos when we have the IMP?

• Some ITS services use Chaos but not IP, e.g. the DIR device.
• The IMP needs to run as root on most Unix flavors, but the UDP tunnel can go over unprivileged ports. (This can also make it avoid firewalls.)
• It's historically interesting, and makes KLH10 more complete.
• It's FUN!

Like other KLH10 network devices, ch11 works together with a Device Process which communicates with the device and reads/writes network data over UDP. A 4-byte protocol header is added, with only one defined function code yet (sending a Chaos packet). The “original” Chaos trailer (destination, source, and checksum) is also added.

The protocol, CHUDP, by default uses UDP port 42042, but this can be configured in case, e.g., that port doesn't pass through your firewall.

The code is a (very) stripped-down version of dvlhdh.c and dpimp.c, and includes minimal patches to the makefile and to kn10dev.c. It is now included in the standard klh10, but an early version can be downloaded here (updated 2017!). I would appreciate if you send me an email if you do, e.g. so I have an idea about who to notify about updates.

To configure the CH11 device, as a minimum, use

  devdef chaos ub3  ch11 addr=764140 br=6 vec=270 myaddr=3132

where the new parameter is “myaddr”, which is the octal Chaosnet address of the system. ITS seems to think the “br” param should be 6, not 5 as used in the old dummy device definition (see CHXCHN in ITS). It uses the generic Unibus parameters “addr”, “br”, “vec” etc, plus additional parameters:

• chudpport=50043 changes the UDP port used
• chip=3131/10.0.1.42:50011 defines a Chaos/IP mapping for Chaos host 3131, which should be contacted at IP 10.0.1.42 at UDP port 50011. You can use hostnames in place of IP addresses, which will use the first address returned by gethostbyname(), if it is an IPv4 address. The port suffix is optional and defaults to 42042. You can define up to 10 such Chaos/IP mappings (without changing the constants in the code). !!

(Rather than configuring lots of chip entries, consider using the separate chaosnet bridge program at https://github.com/bictorv/chaosnet-bridge. You could also connect to my Chaosnet which has a central bridge at UP, see https://chaosnet.net for more info).

If a CHUDP packet is received from an unknown host, a Chaos/IP mapping is dynamically added to the table, so return traffic can find its way. This is useful e.g. if you accept connections from other ITSes without static IP addresses. (There is currently no way to avoid potentially filling your table this way.)

To make use of the interface, you need to recompile ITS after defining CHAOSP, MYCHAD, NINDX, and CH11P in SYSTEM;CONFIG (and following the instructions in distrib.its, of course). See also BEWARE note below. Don't forget to compile SYSENG;@CHAOS and install as DEVICE;ATSIGN CHAOS. Don't forget to keep names of your friends' ITSes in SYSEN2;MLDEV, SYSENG;@DEV, etc. Patch SYSBIN;FTPS BIN to get your Chaos-mail Received header right. More notes may appear later.

Make sure your firewall lets the UDP traffic through.

I would appreciate very much to get feedback and testing, especially from people who actually *know* how the original interface was supposed to act. I've discovered many things by reading SYSTEM;CHAOS and by testing locally, but I can't say I know exactly how it *should* work…

If you have both CHAOSP and IMPP, you run into a bug which results in all non-local IP packets being routed via Chaosnet… (unfortunately noone is listenting at Chaos address 3040). The bug is caused by the IPMASK macro defined and used in SYSTEM;CONFIG, which results in the netmask NM%CHA being zero, which matches anything. The easy fix is to change the line

  IFN CHAOSP,DEFOPT NM%CHA==<IPMASK IMPUS4>	; Set default netmask for it

to

  IFN CHAOSP,DEFOPT NM%CHA==<IPADDR 255,255,0,0>	; Set default netmask for it

but the real fix would be to the IPMASK macro.

• 2005-04-23: Fixed a long-standing bug in dynamic CHUDP handling. Chapter 7 in AIM 628 doesn't give much (and doesn't always match the code in SYSTEM;CHAOS).
• 2005-03-08: Found my old copy of MIT A.I. Memo 628: Chaosnet by David Moon. At some point I'll go through the code and clean things up, add missing functionality, etc.
• 2005-02-09: Fixed silly typo in lost count handling.
• 2005-01-31: Finally got the interrupt handling and synchronization right. Along the way,
  • implemented “lost count” in CSR
  • added basic routing support (if DPCHUDP_DO_ROUTING is non-zero): if a packet is sent to DEFAULT_CHAOS_ROUTER (default 03040) or to another subnet, look up header destination in CHIP table, and if found, send it there (after updating forwarding count, trailer destination, and checksum). If the destination is not found, but a host on the same subnet is found, send it there and hope for the best (currently it will be dropped). Anyway, it now works to have ITSes on different subnets, as long as the CH11 knows about it.
• 2005-01-29: Avoid race condition, handle CSR bits better. dpchudp is still receiving short packets from dvch11 which dvch11 doesn't detect sending - reason unknown, the packets are ignored, and the device “works”, but I'd like to fix it anyway.
• 2005-01-25: Enable interrupts correctly (handle %CAREN/%CATEN in the right order).
• 2005-01-24: Avoid auto-retransmissions (check ch_outactf before sending anything).
• 2005-01-23:
  • Minor portability fixes (after porting to Solaris/Sparc).
  • Checksum now checked in dpimp.
  • Dynamic entries in CHIP table are refreshed if it's more than 5 minutes since last reception from that address.
  • Front-end command: dev chaos chiptable to show current contents of CHIP table.
• 2005-01-19: First release.

• Setting to only accept dynamic ip/port for specific chaos addresses. (Allow for future authentication extension?)
• Dynamic setting for chip table ttl.
• Better routing support (fixed by the Chaosnet bridge program)
• Implement loopback (not LUP, but Chaos pkts to self). Currently they are in practice dropped. I'm not sure ITS handles this very well anyway.
• Use DNS to find Chaos addresses - see more info here.
• More CHUDP protocol functions?
• Security: while ITS with PANDA/PWORD may keep malicious people out, there are gaping holes once you have Chaosnet access. If dynamic CHIP entries are allowed, anyone can come up with a random Chaos address and read/write your system over MLDEV. Possible improvements:
  • Use the TLS link type in the Chaosnet bridge program
  • Let MLSLV check that the chaos address translates to an ITS name in the ITSNMS table (or implement a cbridge-based firewall)
  • Verify CHIP enties by checking that DNS entries for CH and IN classes match. This doesn't work for Chaos nodes with dynamic IP addresses (which is what it's supposed to support).

See the Chaosnet bridge program if you want to use Chaosnet in Linux/Unix