Building an AppleTalk (LocalTalk?) over UDP driver

[cheesestraws]

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:

1. 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.
    
   
2. 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.
    
   
3. 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.
    
   
4. 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.
    
   
5. 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?

 

[sutekh]

I'm definitely onboard  Great outline. I certainly agree with not rolling a custom IP stack. It'd be great if the eventual outcome was 100% physical-layer agnostic and leveraged whatever device is selected in MacTCP / OT. That's where all of the previous implementations seem to be lacking.

As for collaboration, how do you plan to compile? Modern development environment with Retro68? On-platform (I just grabbed a copy of Code Warrior 4 and began fiddling with it FWIW)? Pull requests and commits will involve some manual effort in the case of the latter, but that doesn't preclude using SourceForge / GitHub does it?

Another feature request I'd throw out specific to my "modem thingies", which as I think about it may wreck the whole program for my use case (since there's broadcast involved), is NAT accommodation. The ESP_SLIP_Router package I'm using doesn't bridge. The ESP8266 DHCPs its own IP on the Wifi/LAN side, and has another network on the serial side. The PowerBook references the ESP8266's serial-side IP as its gateway. The ESP_SLIP_Router CLI has a provision for inbound / outbound UDP and TCP portmappings, but that's it. Hmm...

 

[cheesestraws]

The ESP_SLIP_Router CLI has a provision for inbound / outbound UDP and TCP portmappings, but that's it. Hmm...

I don't suppose you can get it to forward broadcast traffic can you?  Otherwise we're ... in significantly harder territory here, I think

 

[sutekh]

I don't suppose you can get it to forward broadcast traffic can you?  Otherwise we're ... in significantly harder territory here, I think

It's either that, modify ESP_SLIP_Router to bridge, or abandon it altogether in favor of what appears to be one or two available (but seemingly much less baked) bridging SLIP implementations. More research and fiddling required. Regardless of the path chosen, however, I'm still going to want LToUDP to achieve my ultimate goal.

Counter argument: With port speed limited to 57,600bps, it's a lot quieter behind the ESP8266 without broadcast noise. Sending that through might clog an already restricted pipe. I wonder if I might just better off spinning up a Netatalk server on my own LAN and brokering AppleTalk connections through that... Anyway, that's unrelated to what you're trying to accomplish here, so please forgive the minor hijack.

 

[cheesestraws]

Anyway, that's unrelated to what you're trying to accomplish here, so please forgive the minor hijack.

I don't think it's unrelated at all: this is a pretty major use case for whatever software we come up with...

 

[olePigeon]

@cheesestraws This would theoretically let you play Bolo over the internet, correct?   At least, I'm hoping.

 

[cheesestraws]

Not in the way I'm currently thinking about it, but I think a lot of the use cases for this might actually be for that kind of use, so I might need to rethink that.

That said, if you can get bbraun to send you the netatalk stuff he uses on his server, you could always use that; I believe he explicitly says that Bolo works fine over AVPN + his server code.

 

[Scott Squires]

bbraun's AVPN (AppleTalk over IP) driver

[...]

The source for this is available and under a BSD license, and I've previously got it building

Did you contact bbraun for that? I checked his svn server and couldn't find it.

 

[cheesestraws]

Did you contact bbraun for that? I checked his svn server and couldn't find it.

The source is just bundled with the binary, in the archive on this page: http://www.synack.net/~bbraun/macapps.html

There's no explicit license mentioned in the source dump, so I asked him (on mac68k.info) and he said to consider it BSD licensed IIRC (I can't remember which BSD license; would obviously have to go back over that forum thread before I released anything).  If you are worried about license, probably best to ask , or go and find the message where he said that.

 

[Scott Squires]

Ohhh, I hadn't even downloaded it, was just looking for the source on his website. LOL!

 

[cheesestraws]

I always forget it's bundled in with the binary and find myself looking for a separate source download, too, when I forget where it is...

 

[FunnymanSE30]

Have you taken a look at Basilisk ii's sheepnet driver? I was able to compile it on my raspberry pi running Raspbian Jessie and connect to a virtual appletalk file server with both my pbg3 running 10.4 and Takky running 7.5.5 and AS 3.7.4/ OT 1.3, I have netatalk running on the same pi, which the takky also connects to, doesn't seem to be able to connect from basilisk to the netatalk server hosted on the same machine though

 

[cheesestraws]

Have you taken a look at Basilisk ii's sheepnet driver?

Sheepnet was, as I understand it, a mechanism to allow BII to share an Ethernet port with the host OS.  Firstly, there are better ways of doing that these days anyway; secondly, it is tied to Ethernet; and it isn't really relevant to this discussion, which is really about how to build a driver for the classic Mac such that it can in some way talk AppleTalk over an IP backbone, preferably with broadcast still working.  Basilisk II's Ethernet over UDP isn't much use here either, unfortunately, as the assumptions it makes about the relationship between MAC addresses and IPs kind of preclude it being trivially bridged to real Ethernet.

I'd ideally like to use this to stun several emus with one boulder; some time ago I came up with a way of using LLAP over UDP to talk "LocalTalk" between emulators.  This is in Mini vMac now, and I was thinking one sensible way to do this might be to implement that standard and just hand off short-form DDP packets to the OS, which is what bbraun's driver does anyway.  Part of the problem here, though, is that like a fool I tried to do that properly and the default implementation uses IP multicast, which of course MacTCP won't even look at.  So, harumph.