Jump to content
cheesestraws

Developing a portable user-land AppleTalk stack

Recommended Posts

A quick update on this: I've been working on EtherTalk.  So far I've got a "listener" (an implementation of layer2) based on libpcap.  Another one will follow at some point based on tap interfaces, and I'd like to do one for BasiliskII's UDP Appletalk network too (which is basically EtherTalk with some weird hacks around it).  I've also got about half of AARP implemented.  Next stop is getting address acquisition for EtherTalk working.

Share this post


Link to post
Share on other sites

Another quick update on this: I've submitted the LToUDP patches to Paul C Pratt for inclusion in "stock" Mini vMac.  How much he'll want me to change, we shall see.  I haven't had much time or serenity to work on non-work code, because my house has been full of visitors and is now full of people replacing my bathroom and this is wearing my nerves rather.

 

The next bit I think needs me to finish my rackmount LC II, which is going to be my AppleTalk router, but will also allow me to do interop testing with EtherTalk with things other than BasiliskII.  That's my first post-bathroom-chaos project...

Share this post


Link to post
Share on other sites

Brilliant! And nice to see someone working on something significant for retro Macs also over here in the UK. Keep up the good work! :D

 

Share this post


Link to post
Share on other sites

Another quick update on this: the builders have now left but my mental health is extremely poor, which is making working on software outside of work rather tricky.  I haven't abandoned this, though.

 

The good news is that the Mini vMac LToUDP support is in the current alpha of Mini vMac, and looks like it is going to work on Linux too.

 

More will come when I am actually able to concentrate again.  Watch this space...

Share this post


Link to post
Share on other sites

Hmmmmmmmm

Tried to run the latest Alpha (2 times) on Windows computer..but the two doesn't seem to "see" each other. Tried it some time ago on Macos and it worked. Is there no LocalTalk on Windows?

Share this post


Link to post
Share on other sites

I don't think it's working on Windows.  My code certainly doesn't do Windows.

 

There's no particular reason why it can't (it's just standard socket code), I just don't have a Windows machine set up for development at present.

 

Anyone who does Windows development and wants a pretty easy win, this would be a good target :-).

Share this post


Link to post
Share on other sites

It is absolutely dead standard socket code, so yeah.  When I get my house in order (both literally and metaphorically) I will try to have a go with it with my old Windows dev machine, if nobody else has picked it up by then.

Share this post


Link to post
Share on other sites

This how it looks on our MacBook.

 

One Mini vMac on system 7.5.5 has file sharing and one on System 6.0.8 with Appletalk. Disk Mac is mounted on the desktop of the system 6 Mini vMac.

 

IMG_0855.thumb.JPG.e22099bc17201aee48bcf407443823c9.JPG

Share this post


Link to post
Share on other sites
On 2/18/2020 at 11:37 PM, mactjaap said:

Hope a windows developer takes up the challenge.....

The new alpha as of a couple of days ago apparently has it working under Windows—I assume Paul C. Pratt did the requisite work, it definitely wasn't me.

 

33 minutes ago, olePigeon said:

This is so cool.

The first time I got it working I actually got a fit of the giggles because it was so cool to see.  I can't wait to start getting these networked to *real* Macs, which is the next goal...

Share this post


Link to post
Share on other sites

I tested Alfa 37 on Windows. Same disks as on the Mac. But I didn’t get it going. I’m I doing something wrong? Anybody else tested?

Share this post


Link to post
Share on other sites

Weekend project:

 

ltou-to-you-too.thumb.jpg.261f5a6ce6a11085ae57f8481c0a3e49.jpg

 

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

Share this post


Link to post
Share on other sites

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

 

9 hours ago, sfiera said:

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.

 

9 hours ago, sfiera said:

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!)

Edited by cheesestraws

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :-/

Edited by cheesestraws

Share this post


Link to post
Share on other sites
On 3/2/2020 at 6:42 PM, olePigeon said:

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×