TashRouter: An AppleTalk Router

[finkmac]

It works! Bravo Tashtari!

Left is qemu-m68k running sys7.5.3, Right is Mini vMac in a Snow Leopard VM (because I couldn't get it to work in windows).

Network setup is tashrouter running on a pi4, netatalk running on a pi2.

Note, I wasn't able to get this setup to work with both netatalk and tashrouter on the same machine... I had to put them on different pis.


Raspbian Buster has the macvtap driver... on pi4 Raspbian and newer. It's possible to get it on the pi2, but you need to recompile the firmware... Not for the faint of heart! This is a good starting point. I recommend doing the cross compilation on ubuntu or something, as compiling on the pi will take ages.

 

[NJRoadfan]

No surprises that netatalk and a macvtap setup don't work on the same machine. That is because netatalk can't "see" packets coming in/out of the macvtap interface (pcap has the same problem). You need a router that can "hairpin" (reflective relay) those packets back to the machine's interface.

 

[NJRoadfan]

OK, I see what the problem is. TashRouter isn't picking up RTMP routing data from atalkd over the tap interface. Either atalkd isn't sending it, or its being dropped by the tap interface.

It works with the FastPath 5 though. TashRouter instantly sees it and adds its networks to the routing table. Also, here is a debug log of a LToUDP client trying to administer a FastPath on LocalTalk thru the TashTalk with Shiva NetManager. You can grep 0.220 to see the entries. Note the FastPath outputs two NBP entries. SNMP Agent and the Fastpath itself using it's Ethernet MAC as the name of the unit.

 

[tashtari]

Hm. What I'm seeing here I don't quite understand.

2023-12-14 23:23:00,920 DEBUG: frame in     LToUDP  254  69  type 01         b'\x00\x18\x02\xfe\x02\x11\x03\x00\x05E\xfe\x00\x01=\x01=\x07Locally'
2023-12-14 23:23:00,921 DEBUG: in to 5.254  LToUDP   0 0.254 0.69    2 254 2 b'\x11\x03\x00\x05E\xfe\x00\x01=\x01=\x07Locally'
2023-12-14 23:23:00,922 DEBUG: out to Locally ttyAMA0  0 0.255 1.254   2   2 2 b'!\x03\x00\x05E\xfe\x00\x01=\x01=\x07Locally'
2023-12-14 23:23:00,922 DEBUG: frame out      ttyAMA0 255 254  type 01         b'\x00\x18\x02\x02\x02!\x03\x00\x05E\xfe\x00\x01=\x01=\x07Locally'
2023-12-14 23:23:00,931 DEBUG: frame in       ttyAMA0 254 220  type 84         b''
2023-12-14 23:23:00,936 DEBUG: frame in       ttyAMA0 254 220  type 01         b'\x00k\xfe\x02\x023\x03\x00\x01\xdcS\x01\x1100-80-D3-FF-00-FF\x04SNMP\x01*\x00\x01\xdc\x08\x01\x1100-80-D3-FF-00-FF\nSNMP Agent\x01*\x00\x01\xdcK\x01\x1100-80-D3-FF-00-FF\x08FastPath\x01*'
2023-12-14 23:23:00,936 DEBUG: in to 1.254    ttyAMA0  0 0.254 0.220 254   2 2 b'3\x03\x00\x01\xdcS\x01\x1100-80-D3-FF-00-FF\x04SNMP\x01*\x00\x01\xdc\x08\x01\x1100-80-D3-FF-00-FF\nSNMP Agent\x01*\x00\x01\xdcK\x01\x1100-80-D3-FF-00-FF\x08FastPath\x01*'

(5.69 is the Mini vMac on LToUDP, 1.220 is the FastPath on TashTalk, 5.254 and 1.254 are TashRouter on LToUDP and TashTalk, respectively.)

• Mini vMac at 5.69 sends a short-header DDP datagram to TashRouter at 5.254, a BrRq for =:=@Locally.
• TashRouter at 1.254 converts the BrRq into a LkUp and broadcasts it, saying that anyone with services matching =:=@Locally should respond to Mini vMac at 5.69.
• The FastPath at 1.220 responds to the LkUp with a LkUp-Reply to TashRouter at 1.254, but it's a short-header DDP datagram, so it has no mention of 5.69 or any address beyond TashRouter at 1.254.
• TashRouter at 1.254, having received a datagram that it didn't request with its address as the apparent final destination, shrugs and discards it.
• Mini vMac, having received no reply to its BrRq, tries twice more with the same result.

I don't know what TashRouter is supposed to do differently here. NBP LkUp-Reply datagrams are supposed to be addressed directly to the original requestor, the router isn't meant to keep track of who requested what. The FastPath should be sending a LkUp-Reply to 5.69 using a long-header DDP datagram by way of TashRouter at 1.254. Are you supposed to be able to admin the FastPath through another router, or only through a machine directly connected to it?

 

[NJRoadfan]

Once setup, you can directly admin a FastPath from anywhere on the network. It does work from the Ethernet side of the FastPath. I suppose its a quirk of its firmware when dealing with LocalTalk to LocalTalk routers. I think one can get around this though. By default the FastPath advertises on the LocalTalk side. You can change it to advertise on the EtherTalk side once setup.

EDIT: That worked, just move it to advertise on the EtherTalk side.

I can see the limitation to short form DDP when the unit is reset and in VROM download mode (minimal stack to just download and kickstart firmware), but not when it is fully setup.

 

[tashtari]

Hmm. I guess it's understandably not a path they envisioned a lot of people taking, connecting two links over a LocalTalk network.

So where does this leave us in terms of as-yet unsolved mysteries? The LaserJet isn't playing nice with TashTalk at all, I'm hoping the 1.0.1 firmware will improve that situation. Netatalk isn't routing properly to tap interfaces, I'm not really sure what to do about that as it's not a problem with TashRouter's logic... I suppose I could take another crack at an EtherTalk driver based on pcap, with the idea that that'd have access to every frame going in and out of the system.

Anything else?

 

[NJRoadfan]

That should be it. I had the FastPath out mostly to debug router table functionality along with forwarding. With atalkd, there is a change to the code that was made involving split horizon a while back that I want to revert to see if it fixes the problem.

 

[NJRoadfan]

I FOUND THE ISSUE WITH atalkd. As I suspected, it was that pesky split horizon patch. I reverted it and now TashRouter is getting RTMP data and updating its routing table. Data passing from my Ethernet network thru atalkd to TashRouter now works.

What isn't working still is netbooting the IIgs. I did another log trace and it looks like the IIgs only sends out short form DDP packets to find a netboot server. The attached log shows it trying to find a device with a NBP type of 'Apple //gs' and not getting anywhere before timing out. This worked with modtashtalkd because in that case, netatalk's netboot server was directly on the LocalTalk segment of the network and didn't need a network number to respond. I'm double checking with the Fastpath as a bridge, but I'm pretty sure I got netbooting working thru that no problem.

 

[NJRoadfan]

OK, fixed the IIgs netboot problem. The IIgs needs to be in the same zone as the netboot server! Otherwise it doesn't work at all, even with other routers. So basically all the outstanding issues I have with TashRouter have been resolved.

 

[tashtari]

I FOUND THE ISSUE WITH atalkd. As I suspected, it was that pesky split horizon patch. I reverted it and now TashRouter is getting RTMP data and updating its routing table. Data passing from my Ethernet network thru atalkd to TashRouter now works.

Nice! Can you contribute it upstream?

OK, fixed the IIgs netboot problem. The IIgs needs to be in the same zone as the netboot server! Otherwise it doesn't work at all, even with other routers. So basically all the outstanding issues I have with TashRouter have been resolved.

Even nicer!

 

[NJRoadfan]

I'm submitting an issue now. Hopefully @slipperygrey can revert the patch. This is the offending commit: https://github.com/Netatalk/netatalk/commit/27111c653b471eab31ac2a776e0e483f9194f805

Its likely that the AsanteTalk and Dayna bridges don't correctly handle RTMP packets. No surprises given the grief these bridges have caused other folks on this board.

 

[slipperygrey]

Good catch

I'm submitting an issue now. Hopefully @slipperygrey can revert the patch. This is the offending commit: https://github.com/Netatalk/netatalk/commit/27111c653b471eab31ac2a776e0e483f9194f805

Its likely that the AsanteTalk and Dayna bridges don't correctly handle RTMP packets. No surprises given the grief these bridges have caused other folks on this board.

This patch was a "quirks mode" fix in the first place, and if since you've proven that it has unexpected side effects, reverting it seems like the right thing to do. If you file a PR I can approve and merge.

 

[tashtari]

Update: The offending patch has been reverted, there's a PoC reintroducing the old behavior under a "quirks mode" switch of some kind. Also, there's some interesting discussion on the issue.

One of the points of discussion that interests me is the valid point about comparative availability/popularity of TashTalk/TashRouter, which is something I'd very much like to improve.

Paging @mactjaap - what would it take to integrate TashRouter into your RPi distro? A one-stop "just burn this to an SD card" solution that gives you full-fledged AppleTalk routing, file and printer sharing, and MacIP is definitely something worth having.

@twelvetone12 is working on USB2LT, which would be a big step as far as availability of TashTalk, and of course I still sell TashTalk 2 RPi hat kits whenever I have the parts to put them together, but both are still some distance from being a finished product you can just buy off the shelf. Any interest, @rabbitholecomputing?

In addition, while it's convenient to wrap everything up in an RPi, as @demik pointed out, one doesn't actually need an RPi to run TashRouter - an AirTalk (which can be had for €49 thanks to the efforts of @daanvdl) to bridge LocalTalk to LToUDP, plus a VM to run TashRouter and connect LToUDP to EtherTalk, will do the job just as well.

Not sure how best to make these solutions accessible, but a PyPI package would probably not be the worst place to start... I've just been holding off because I feel like the code is still pretty green. Could maybe do native packages for popular distros and/or a Docker container, too...

Anyway, I'm just throwing dreams at the wall, to mix a metaphor. It's a tall order, I realize, but I really want this to overtake the popularity of AsantéTalk, so everyone who wants one can have a fully standards-compliant LocalTalk/EtherTalk router and not have to shell out $100+ to get a used AsantéTalk (with all its weirdness and incompatibility) off eBay.

 

[akator70]

^ I like all of those ideas.

 

[slipperygrey]

Thanks to @NJRoadfan 's prompt testing and code review, the "branch-netatalk-2-3" branch has been patched now. The atalkd daemon can be started in "quirks mode" with this command:

atalkd -q

For most people it means modifying the systemd unit config file - atalkd.service.

I'm planning to put out a stable netatalk v2.3.0 before the end of the year. Just a few more cleanup tickets that I want to get to first.

For the record, netatalk 2.2.7 through 2.2.10 are all permanently running in "quirks mode". The patch was applied prior to the 2.2.7 release, as part of a batch of ports from NetBSD.

 

[mactjaap]

@tashtari
Sorry for not answering earlier. Buzzy week before Christmas!

For as long I'm working on my MacIP projects (over 10 years now..) I'm dreaming of a replacement for the hardware LocalTalk Bridge. I would really like to see one which combines the ability to use it for filesharing.... but also for MacIP. So a hardware LocalTalk bridge with the abilities of my MacIP project would be the best on earth.
I'm afraid that this ambition is high. Until now there is no new LocalTalk hardware bridge what can do the same as the old ones. But some initiatives are very hopeful!

And again ... I would love to buy one ( or more) if someone could build them.

For the TashRouter in MacIPRpi project. Sure! Would love to give it a try.
I now use atalkd form netatalk 2.x and macipgw for the MacIP part

 

[cheesestraws]

I'm afraid that this ambition is high. Until now there is no new LocalTalk hardware bridge what can do the same as the old ones. But some initiatives are very hopeful!

The thought here is that tashrouter + a tashtalk hat on an R-Pi will mostly do this.

 

[mactjaap]

The thought here is that tashrouter + a tashtalk hat on an R-Pi will mostly do this.

Yes! That is fantastic. I have a hat, but until now i didn’t manage to get it working for “real” Macintosh and my AppleTalk network. Only for vMac. The router I didn’t try yet but I love to try.

 

[Andrew]

Hello all and happy new year! @tashtari thank you very much for your useful contributions to the community. I successfully connected Ethertalk (SE30)<->LtoUDP(vmac) running on a vm (macbook m2). However, I am having weird issues when running using the tashtalk hat on a raspi zero w Tashtalk (SE30)<->LtoUDP(vmac). The behaviour I have is the following:
a) Both SE30 and vmac can see each other's shares
b) vmac can connect on the se30's network share fine but it is really slow, I would say unusable.
c) se30 can see the network share on vmac but cannot connect (times out before asking for password)
I've tried both localtalk ports on the se30. Raspi wifi strength is excellent. Do you think that the raspi zero w resources are limited?
EDIT: I am attaching the output in case it is useful. A few seconds before the end of the log file is when the timeout occurs (SE30 trying to connect to mini vmac)

 

[tashtari]

Hmmm. So what I see in that log looks pretty normal right up until 11:37:15, when the SE/30 sends an echo request to Mini vMac. TashRouter routes it from ttyAMA0 to LToUDP, as it should, but Mini vMac never answers it for some reason. After this, the SE/30 five times sends an ASP GetStatus call to Mini vMac, which Mini vMac does answer, but rather slowly, taking about 0.5-0.75 seconds to reply when it should do basically instantly...

I really don't know how to explain this, there's no reason I can see that Mini vMac shouldn't respond to the echo. The fact that it doesn't is probably why the connection times out, as the SE/30 probably gives up waiting for it, though the fact that there are apparently-working GetStatus calls in the intervening time is very curious.

The only thing I can think of is to try removing wifi as a potential source of trouble - can you hook the RPi up via ethernet instead?