OS9 networking

by patrick ulland March 9, 2024

The post assumes you want to actually experiment with ethernet and not just encapsulate a serial port. Which means a hard left into the weeds. Our primary tools will be the lean and mean 'f.name' OS9 utilities that provide the raw functionality to get things done from any OS9 CoCo. On top of that, a couple packed basic09 utilities allow a unixlike experience on a CoCo3. Or accept the challenge and create your own 'syntactic sugar'. Authors wanted!

Starting at the start, Ethernet has three main 'levels' of ID. Embedded in the card is a unique 'media access control' or MAC address. The switch remembers what port your hardware in on by it's MAC. Diagnostic types with an OS9 CoCo can find the hardware MAC address of anyone on the network with the command f.arp.

The first step at organization is the assigned IP address, which maps the tangle of random MAC addresses into a numerically organized subnetwork. On any OS9 CoCo, use f.dhcp to autoconfig, or f.config to hand assign an IP address, mask (size of subnet), and gateway (out of this place). For Level2 OS9, we have 'ifup', details to follow.

Finally, the human pronouncable machine name and location. Formally called the FQDN (fully qualified domain name). The simplest is a three layer example - 'www.google.com' breaks down to server 'www' inside google's network, inside the .com TLD (top level domain). That's almost all we need to know because a web of 'nameservers' exchange address number info up and downstream. Nameservers for google(8.8.8.8) and cloudflare(1.1.1.1) deal with 'everybody' so asking them anything about anybody anywhere works pretty often. From any OS9 CoCo, try 'f.dig 1.1.1.1 name.place.tld' to 'grope' for an IP. Domain Information Groper might find one name leads to another (and another). Keep groping until eventually finding an 'A record' or final answer. More in a bit.

Not everybody needs or wants a global nameserver. If you use dhcp, might even find your local router was named 'the' nameserver. And true, it mainly kicks requests upstream. Otherwise, this is how a LAN begins. Mine example is a cheese Dlink router inside my home AT&T network. It hosts a couple CoCos, a laptop web server and sometimes a Pi. The Dlink does port forwarding, meaning the rest of the house has no idea but can ask for services (long story). But inside my private LAN, the local nameserver means we can refer to local machines by short name. New guy 'coco' came on via dhcp? Just ask for 'coco', the address will shake out because local nameserver. It's awesome.

With these layers of flavor, Level 2 needs a few config files. These were lifted straight outta Unix (or old Linux) so the format should be familiar to some. In general, leading whitespace and blank lines are ignored, leading semicolon or '(*' indicates a comment.

/dd/SYS/interfaces is just that, a list of interfaces for ifup to bring up. Each one must have a name in the range eth0-eth9. There can be 2(RSN) CoCoIO using encapsulation 'inet' but other interfaces will be supported where we can. Finally, 'static' or 'dhcp'. If dhcp, the subsequent address data is ignored, just free parking until static is turned back on. At this time macaddr is just a placeholder for the unhandled issue of CCIO with no EEPROM. Finally, phyaddr will enable multiple card/IP/hostname on one CoCo soon.

iface eth0 inet static
address 10.2.2.123
gateway 10.2.2.1
netmask 255.255.255.0
macaddr 5C:26:0A:01:02:03
phyaddr $FF68

iface eth1 inet static
address 192.168.1.7
gateway 192.168.1.1
netmask 255.255.255.0
macaddr 5C:26:0A:C0:C0:03
phyaddr $FF78

Most of the time we are not wanting to type numbers, so basic network information is kept in /dd/SYS/hosts. First we self identify, 127.xxx provides a hostname for each interface in list order. (Note f.dhcp only uses left 4 chars of a hostname). Then a trusted list of IP/hostname pairs. These are used in place of dns calls. Below the comment lies our live dns cache. When a hostname must be looked up, the result is saved here and used until it stops working. Then it's erased, we look up the name again and add to the bottom.

127.0.0.1 coco.conect.lan
127.0.0.2 port2.conect.lan
192.168.23.49 rickHP.conect.lan
104.192.7.102 play-classics.net
206.163.230.108 www.lcurtisboyle.com
; dns cache below
76.13.32.141 www.aol.com
142.250.1.106 www.google.com

/dd/SYS/resolv.conf normally lists up to 3 nameservers. If the first one fails to find a name the next ones have a go in turn. 'search' is a string added to any short hostname, so 'coco' becomes 'coco.conect.lan' for name searching purposes. We've overloaded this to store an extra dhcp provided nameserver if we are given one. The comment and nameserver pair will be removed or reset next network startup (any style, dhcp or static). A few options are honored, see the CoCoIO manual.

search conect.lan
; temporary, from dhcp
nameserver 192.168.1.254
nameserver 8.8.8.8
nameserver 1.1.1.1

dhcp note: On a CoCo, dhcp takes a hot minute. To save that time every reboot, cheat! Start the network, then run 'ifconfig'. Note the address values dhcp provided, add them to /dd/SYS/interfaces as a 'static' config. No guarantee, but a home router will usually pass out the same address for months. Don't ask. If it does stop working, turn dhcp back on and repeat cheat.

Now what?

At this point, you've got a CoCo2 and a list of IP addresses, or a CoCo3 that can manage those somewhat. What to do? There is no local translator machine or remote gateway provider with a menu, just you vs the internet. On the upside, no boundaries and all that. From Milwaukee my CoCo can ping (round trip test) Henry's droplet in NYC and MarkO's Flintstones subdivision out west equally well. Not because there is an external support system, but because ethernet works like that.

On the downside, there is no menu to pick from. We are the acorn that becomes the mighty oak! heh. Seriously, a CoCo can do things all by itself. A CoCo2 might not have room for pretty config programs, but a list of raw IP addresses along with utilities like f.recv and f.send will drive some fast LAN party games. Add some public IPs from one of those dynamic dns services, the LAN party is nationwide, no adult supervision required.

A CoCo3 has room for an expanded framework. And lots of low hanging fruit. Turning f.get into a 'regular' tftp client, molding f.send and f.recv into rsh. I'm still building a web browser in Basic09.

All of us can just poke at the chip directly. My github has a fully remarked decb program to start the network, contact a web server, and barf the server's response to screen. Mangle that into what you will. There is also the Basic09 version, which is expanding beyond all reason and may become a grown up web browser someday. It is a hybrid, using all the tools above, plus some peeking and poking to get the job done.

Away from the CoCo, we have some shortcomings to paper over *CO*SSH*UGH*. Security by obscurity may be effective at CoCo size, but that doesn't get you into a lot of websites. I remember the old Opera browser had a middle man. We might create a proxy server to pass along simplified and decrypted versions of a requested website - delete the videos, scale the pics.

In the mean time, game servers! A linux box with a public IP could host 100 CoCo players cross country. What other network services do we need? Email? Can't wait to see what comes up.

Links to the code:
https://github.com/rickulland/CoCo-www
https://github.com/strickyak/frobio

and disk images! EOU1 for 6309 or 6809, CCIOFILE files to copy to your OS9 install. See README.txt

README.txt
https://drive.google.com/file/d/1-uRZp127Cwl2fHW2UDsRZ_wmm0zYsXdY/view?usp=sharing

CCIO6309
https://drive.google.com/file/d/10HK2vkXgaZ7UqYBj33dtT4T-PsKVoXnP/view?usp=sharing

CCIO6809
https://drive.google.com/file/d/10GD0kcX8DBXtyt1eF2ikmJjeUQgHI2zm/view?usp=sharing

CCIOFILE
https://drive.google.com/file/d/10FBUi0-oXPahEjCUe3dE-TznafYsOo5u/view?usp=sharing