Developing a portable user-land AppleTalk stack

[sfiera]

Weekend project:



Lower left, a Mini vMac LTOU client. Upper right, a Quadra serving its hard drive with AFP over EtherTalk. Off-screen, an RPi running a bridge between the two.

I started with bbraun’s abridge, converted it to Go, and extended it to support LTOU. It took basically the weekend to sort everything out, but it appears to work. Still some stuff I’m not so confident about. For example, I think EtherTalk always uses extended DDP headers; I think LocalTalk does both kinds but I’ve only seen short headers, and I don’t really know how networks are supposed to work.

Repo: https://github.com/sfiera/multitalk

 

[cheesestraws]

This is brilliant.  Seeing this has cheered up my whole week already and it's only Monday morning.

I think EtherTalk always uses extended DDP headers; I think LocalTalk does both kinds but I’ve only seen short headers

AIUI, LocalTalk generates short headers if the two machines communicating are on the same network, or extended headers if they are on different networks.  The way I think about this, anyway, is that LT kind of conflates layers 2 and 3.  It only puts on a separate layer 3 header ("extended headers") if it has to, to save bits on the wire and to keep backwards compatibility.

You can generally get away with sending extended headers *to* LT nodes, but if you want backwards compatibility all the way back to the first AppleTalk implementations, it'd be better to rewrite things into short headers when you can.

I don’t really know how networks are supposed to work.

You're not alone.  I've read the relevant bits of Inside Appletalk five or six times now and it still confuses me.  I think weird stuff will only happen here if you want it to work when there's also an AppleTalk router on the Ethernet link.

My personal plan for how I was going to bridge them was to send out a ZIP broadcast to find a suitable network number on the Ethernet side (as per Inside Appletalk p. 4-9) then just use that for the LT side.  Then  bridge LLAP query/acknowledge packets to AARP query/acknowledge packets so that one wouldn't end up with duplicate addresses.  One should probably also broadcast RTMP packets to the LocalTalk side to tell the nodes there what their network number is so that they can talk to nodes on the far side of the router.

("RTMP" has a different meaning—the video meaning—in my work life and it's odd using the same acronym for two such different things!)

 

[sfiera]

I tried adding in an extra bridge, hooking up a Plus to the Quadra, which runs LocalTalk Bridge. It was able to see machines on the far end, but not connect to them.

I also tried going the opposite way, with the Quadra as a client and Mini vMac as the server. This doesn’t seem to be working right either. I think it is something about the networks. To start with, I assumed that I could naively translate short headers to network 0xFF00, but now I’m not sure that’s the case. I was seeing things like:

2020/03/02 13:38:18 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0]
2020/03/02 13:38:20 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0]
2020/03/02 13:38:22 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0]
2020/03/02 13:38:23 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 0.95:246 <- 65280.22:251 03: [64 0 4 61 5 1 0 0]

I didn’t actually try to figure out what’s going on there yet, but it’s weird that packets would simultaneously be addressed from 65280.22 to 0.95 and from 0.22 to 65280.95.

Maybe I should go back and actually read Inside AppleTalk instead of just skimming for the packet definitions, hah.

 

[sfiera]

Oh, but no more experiments for a couple weeks. I’m heading on vacation (assuming international air travel is still a thing come Thursday) and I need to put away my toys. Might still put in a little work on the repo.

Is there simpler client software to exercise the networking stack than AppleShare? I see there’s an echo protocol, but the only client I know is netatalk’s aecho, nothing to run on a Classic machine.

 

[olePigeon]

I can give this a whirl.  I have both an Ethernet card and a Shiva Fastpath.  I can try both and see if it works.

 

[cheesestraws]

I'm not going to be able to materially contribute for a little while still, but I might put in a couple of trivial PRs if I can work up the concentration :-/

 

[mactjaap]

I can give this a whirl.  I have both an Ethernet card and a Shiva Fastpath.  I can try both and see if it works.

Did you give it a try?

 

[sfiera]

For the record, I noticed an oversight on my part. When I first tested Mini vMac as an AFS client, I used a 6.0.8 image. Since 6.0.8 doesn't have built-in file sharing, when I later tested Mini vMac as a server, I used a 7.x.x image. However, I didn't first verify that Mini vMac on 7.x.x could also serve as a client. It's possible that that wouldn't work either—even likely, I think, due to my ignorance about networks.

I probably either need to assign a network to the LToU side (or both) with RTMP, as cheesestraws said, or else translate verbatim, without converting between short and extended DDP headers (which may break System 6 compatibility).

One thing that would be helpful, if anyone has a chance, would be tcpdump logs of communication between 6 and 7 (EtherTalk atalk-or-aarp or LToU port-1954). But, no hurry, as I won't have the chance to experiment any more myself for at least a week.

 

[olePigeon]

@mactjaap  I will this weekend.  I have to get my AppleTalk bridge out of the garage, which will be apart of my organizing efforts to label all my storage boxes so I don't have to spend an hour looking for stuff every time I want to get them out.

 

[LaPorta]

I haven’t been following this too closely...what is the end goal of this project? I am curious.

 

[olePigeon]

@LaPorta  From what I understand, it's so you can do AppleTalk directly between an Emulator and a vintage Mac. 

 

[cheesestraws]

I haven’t been following this too closely...what is the end goal of this project? I am curious.

It has a number of goals. 

The first immediate goals were to give Mini vMac "plug and play" networking that works reliably and without needing admin privileges on multiple platforms (which I designed the protocol/wrote the code for and which is available for Mac/Linux/Windows in the latest mini vMac alpha) and the ability to bridge Mini vMac to real Macs (which @sfiera has made enormous progress on).  When my brain-health is suitable, I am going to try to design a dongle to bridge LocalTalk Macs as well, based on some ideas that @saybur had).

The more distant goal is to make it easier to write applications on modern computers that speak AppleTalk.  OSes for the moment still have AppleTalk support in-kernel, but it is suffering from serious bit rot in many cases, and it's only a matter of time before it stops being supported.  So an implementation that is nicely modular (so it can be ported to different physical networks easily), comparatively easy to maintain (for everyone's sanity), and doesn't rely on anything much in the kernel is a good thing if we want to be able to continue to provide services to vintage macs over networks in future.

My side of this project is progressing extremely slowly at the moment because 1. my house has been full of builders and 2. my mental health has been extremely poor (there may be a connection here).  At some point I hope to recover enough will to live to make another burst of progress on this...

Does that answer your question?

 

[olePigeon]

@cheesestraws My suggestion is to take your time and put your health first.

If you're looking for a way to turn your brain off for a while, I'd like to suggest Mystery Science Theater 3000.  Start at Season 2 just to get your feat wet.

You don't even have to think of the jokes.  They're either provided by the commentary, or, they just write themselves given how bad the movies are. :lol:

 

[olePigeon]

I can't get the Gryphal service to work, I always get an error that it couldn't be compiled.

 

[sfiera]

I haven’t been following this too closely...what is the end goal of this project? I am curious.

Speaking personally, what I'd like to have in the long term is a AFP server that is designed to do the kinds of things I want to do (like “access Google Drive from my Quadra at home”) and not the ones that netatalk seems to (like “integrate Macs into a multi-user Unix environment”). And, of course, for it to have a clear future, unlike netatalk2-over-DDP.

 

[cheesestraws]

@cheesestraws My suggestion is to take your time and put your health first.

Thanks I am trying to.  I'm doing lots of stuff with my hands at the moment to try to avoid being too frustrated with my brain, like the rackmount LC project and laying floors and making mosaics.  Perhaps we should have some kinds of crafts thread in the lounge?  MST3K is a great idea, it's very relaxing and easy...

Speaking personally, what I'd like to have in the long term is a AFP server that is designed to do the kinds of things I want to do

Yes, definitely.  I think that would be the sort of flagship application here.  But I don't want one that's just hacked together and will fall to bits under its own weight.  I/we (as the community) have to be able to actually support it, so it needs to be written maintainably.

 

[olePigeon]

@mactjaap  I can't download the latest Alpha to test it.  I always get an error:

--------- GRY SIGNED TEXT ---------

custom variation: 200314_032356_695
options : -br 37 -t mc64 -m II -hres 1024 -vres 768
time : Sat Mar 14 03:23:56 2020
failed to build

------- BEGIN GRY SIGNATURE -------
Gry/nUU60LqH9A2V/ITbRA0gZGBnB2ihen6qtACqZ6XA3qptk76S2mp7zHfYsv/t
qFT40sQni8uuv6iaf93GYslsm8BfsVxhenPkfqlsrPoj9hYWxtvvpGtpwvq1b6su
5fPWtZIPrMQX6Kd+4w/VXLf3pzk3hdmxjCXd2HCgMtS1p0GHojpwC5B4UWpEIlGg
-------- END GRY SIGNATURE --------

 

[mactjaap]

@mactjaap  I can't download the latest Alpha to test it.  I always get an error:

--------- GRY SIGNED TEXT ---------

custom variation: 200314_032356_695
options : -br 37 -t mc64 -m II -hres 1024 -vres 768
time : Sat Mar 14 03:23:56 2020
failed to build

------- BEGIN GRY SIGNATURE -------
Gry/nUU60LqH9A2V/ITbRA0gZGBnB2ihen6qtACqZ6XA3qptk76S2mp7zHfYsv/t
qFT40sQni8uuv6iaf93GYslsm8BfsVxhenPkfqlsrPoj9hYWxtvvpGtpwvq1b6su
5fPWtZIPrMQX6Kd+4w/VXLf3pzk3hdmxjCXd2HCgMtS1p0GHojpwC5B4UWpEIlGg
-------- END GRY SIGNATURE --------

Better to contact the owner of the site.

Maybe you are choosing options which are not possible?

 

[sfiera]

Here are some current Mac builds:

• Mac Plus on macOS
  
• Mac II on macOS
  

They’re built from github.com/sfiera/mini-vmac-builder and all that’s needed to build new versions is to update $LATEST in the Makefile. They are signed but not notarized; woe betide whosoever should upgrade to Catalina. I could build Debian binaries too but don’t have the expertise to do Windows.

Note that the Mac II version starts without any acceleration. I found that it would crash during startup if acceleration was on. It’s fine to turn it back up again after startup finishes.

 

[sfiera]

I think I found a logical error in my code, though I’m not sure what to about it yet, so I’m musing here in text.

It concerns the case I was trying before, where I attempted to bridge EtherTalk/Ethernet to LToU/WiFi (two interfaces), and an AARP “Request” packet comes in (on Ethernet) attempting to map a network/node to a hwaddr. LToU doesn’t have the concept of hardware addresses, so if LToU has seen that network/node (on WiFi), then the bridge should respond with the Ethernet hwaddr.

I wrote the bridge with EtherTalk packets as the underlying data type being passed around (because I started from bbraun’s abridge and abridge only handles EtherTalk). So, right now, the EtherTalk capturer hands the packet to the LToU transmitter, which says “I can’t convert an AARP request to LToU” then checks if it has ever received anything from that network/node. If so, it responds to the AARP request without transmitting anything to the network. But, because that’s the WiFi side of the bridge, it fills out the response the WiFi hwaddr instead of the Ethernet hwaddr.

I’m thinking the implementation should switch to LLAP packets as the underlying data type. Then, the EtherTalk side of the bridge would be the one responsible for filling out responses to AARP requests (and would naturally send the Ethernet hwaddr). The other question is whether to respond, but I don’t think it matters which end of the bridge is responsible for deciding that, right?