cheesestraws
Well-known member
A conversation with @sutekh earlier reminded me that it would be nice to build an LToUDP (or at least AppleTalk over UDP) driver for "real" macs. This would enable a number of fun things, including networking real macs to Mini vMac (with some tweaks) and perhaps using it over the wireless modem thingies that @sutekh has been building.
Unfortunately, most of the documentation on how to write AppleTalk devices seems to have gone missing over the years, but we do have a starting point—bbraun's AVPN (AppleTalk over IP) driver. This is ... for a rather different use case, but similar enough to be handy; it tunnels AppleTalk over a point-to-point UDP connection, wrapping each DDP packet up in a UDP packet, and sending them over to a central server. The server manages authentication and address allocation.
The source for this is available and under a BSD license, and I've previously got it building, then run out of energy and stopped. But as far as I can see, the use case for a LAN is mostly simpler than the Internet VPN use case. To get from here to where we want to be, I think the following things need to happen, probably in this order:
So—I tried this once before and ran out of steam. But does this seem workable to other people? Is anyone interested in joining in? How on earth does one do collaborative development on classic mac software anyway these days?
Unfortunately, most of the documentation on how to write AppleTalk devices seems to have gone missing over the years, but we do have a starting point—bbraun's AVPN (AppleTalk over IP) driver. This is ... for a rather different use case, but similar enough to be handy; it tunnels AppleTalk over a point-to-point UDP connection, wrapping each DDP packet up in a UDP packet, and sending them over to a central server. The server manages authentication and address allocation.
The source for this is available and under a BSD license, and I've previously got it building, then run out of energy and stopped. But as far as I can see, the use case for a LAN is mostly simpler than the Internet VPN use case. To get from here to where we want to be, I think the following things need to happen, probably in this order:
- Instead of sending to a server on the Internet, get it to send UDP packets to the UDP broadcast on the local network. I'd prefer to do multicast, but MacTCP doesn't remotely support it and I'm not writing a custom IP stack just for this. At this point we can rip out all the DNS code, as well; we will never need to resolve hostnames, and DNS is inordinately long-winded under MacOS. We can also remove the STR 131 resource and the code to find it.
- After this, we will need to remove the authentication flow. Unfortunately, the authentication flow is also responsible for address allocation. So, for the moment, we can hardcode a single address, for debugging purposes. As part of this we can also kill off quite a lot of the rest of the DRVR component, such as the UI and the resource file and preference file shenanigans. Hooray.
- At this point we will get something that should be able to spray out packets onto the network that are at least approximately sane. Taking a break to verify this at this stage would be a good idea.
- We now need to fix the packet write and read routine such that they're actually formatting packets correctly; this should be pretty easy, because LToUDP's packet format is nearly nonexistent. If we've done this stage right we ought to be able to talk between this driver and Mini vMac set to use broadcast LToUDP.
- Now for the awful bit: we probably need to replicate the LocalTalk address discovery logic. Fortunately, the logic for this is in the back of Inside Appletalk, and we may actually not need to do it, depending on how the OS actually calls our address enquiry endpoint (I haven't checked yet).
So—I tried this once before and ran out of steam. But does this seem workable to other people? Is anyone interested in joining in? How on earth does one do collaborative development on classic mac software anyway these days?