TashRouter: An AppleTalk Router

shirsch said:

Do any of the active developers have access to a //e + Apple Workstation card? If not, my offer to gather data stands.

Click to expand...

I'm the only developer on TashTalk and TashRouter that I'm aware of. Unfortunately, you're way into stuff that I don't have and/or don't know about (Gatorboxes, Apple II netbooting, &c.) so I'm afraid I won't be much use in debugging where you are right now... if you can isolate the issue a bit closer to TashTalk or TashRouter, though, I'm more than happy to do what I can to resolve it.

Understood, but if you or anyone else on this forum can give me some guidance I will gladly capture the over-the-wire data for both working and non-working clients. That may provide enough information to help zero in on the underlying problem. The problem is almost certainly in the tashtalk or tashrouter code since the //e + workstation board has worked just fine for the past 10-12 years when bridged to ethernet over the Gatorbox. In fact, it was the //gs, not workstation board, that traditionally had connection issues when run with anything other than a Fastpath 4. Geoff Body spent a great deal of time tracking down a flaw in Apple's network software and released a small init that finally solved the problem.

As I suspected, my Quadra 650 (running A/UX) works just fine over the TashTalk router. The //e Workstation board seems to be the problem child.

It could be the TashTalk, or something with the AppleTalk stack itself. Is Geoff Body's Farallon router patches installed on the IIe?

Something easy to test. Does the IIe behave when connected to a Macintosh running file sharing on the Ethernet network? Or even Minivmac sharing files via LToUDP?

You would have to do some packet sniffing on the LocalTalk segment, maybe even some logic level logging if its some weird TashTalk incompatibility. Which firmware is the hat running? Sadly, I don't have an IIe or Workstation Card to test any of this myself.

AFAIK, Geoff's "patch" was actually a GS/OS init file and wouldn't be relevant to the Workstation board supporting a ProDOS 8 envrionment. Historically, it was the //gs that had session issues which is why this situation is so odd. I setup my A/UX box as an Appleshare server, but since it doesn't support shortnames the IIe cannot resolve any of the volumes. However, it is obvious that session continuity is not happening. I can make one or two attempts at logging on before the IIe says "... server? What server?".

I'd love to do some packet sniffing or logic level snooping, but really, really need some specifics. I've used Wireshark, but not for many years so some handwaving input would be required. If it comes to that, I have a logic analyzer and can grab low-level traces. But, again, need some idea of what to look for.

I would try a machine running System 7-9's personal file sharing (assuming it supports short names). The "gold standard" would be AppleShare 3.

One way to eliminate TashRouter and just have the TashTalk in the chain is to setup minivmac with AppleShare 3 and use the standalone tashtalkd bridge. If the IIe can connect to another Mac on the LocalTalk side across the TashTalk (even if it is LToUDP), that would point to some weird packet translation problem in TashRouter. I suspect the TashTalk hat itself is not the problem, otherwise you would have issues getting ANY packets across. I am also assuming you are running the latest TashTalk 2.1.3 PIC build as that fixed a pretty nasty bug with some devices that sent out sync pulses.

I don't know the technical details of the Workstation Card's firmware, only the IIgs. It could be choking on extended network DDP packets for some reason. It could also be a bug in the firmware. I would simplify things and make sure both the TashTalk and Ethernet networks have the same single zone name.

AppleShare 3 does support Apple 2 clients and even provides the images for net-boot. To be sure I'm following, minivmac can be run on any machine with ethernet capability and connect to TashTalk? Or, does it need to be run on the RPi? I'll read through the appropriate message threads to get caught up on LToUDP (this is from Airtalk, correct?).

I have whatever PIC code @tashtari programmed in before sending me a kit. I received it at the beginning of February if that's any help. I have a Pickit 3 and can breadboard up a programmer if it comes to that.

Thanks so much for the suggestion about a common zone name! I didn't realize that was possible, but it certainly makes things simpler.

shirsch said:

I received it at the beginning of February if that's any help.

Click to expand...

You have 2.1.3, then - I started shipping it as soon as I released it.

shirsch said:

To be sure I'm following, minivmac can be run on any machine with ethernet capability and connect to TashTalk?

Click to expand...

You need to run a build of the Mini vMac 37 beta with LToUDP enabled, which you can get here. Once you've done that, you can run tashtalkd on the RPi and it'll bridge between LToUDP and the LocalTalk network connected to the TashTalk hat.

A minivmac build with LToUDP can be run on any machine on the network. The tashtalkd program is a simple bridge allowing LocalTalk devices on a TashTalk to speak directly with LToUDP clients like they are on the same network. TashRouter further extends this by setting up LToUDP clients on their own separate virtual LocalTalk network and routing between them.

I found a nice, pre-built hard disk image for OS 7.5 and booted that in minivmac (I also have a code for the builder tool). After setting up sharing, I was able to log into the guest system, list the root directory (shared folder was not seem by the A2 client) and copy files back and forth. The session has been up almost a half hour without any glitches or disconnects.

What I could really use would be a version of tashtalkd that simply bridged between localtalk and ethertalk on the same network. Routing is valuable, but not in my favored setup.

Sounds like we can rule out the TashTalk then. It appears to be doing its job. Bridging LocalTalk-to-Ethernet sans routing isn't very straight forward and has its issues given how quirky the Asanté and Dayna bridges can be.

Yes, it seems like there's an issue with the TashRouter code. @tashtari - Would it help if I grabbed debugging output from the router for working and non-working LT clients?

@tashtari how do you specify the IP address in LtoudpPort to connect to ?

amedeo_68k said:

@tashtari how do you specify the IP address in LtoudpPort to connect to ?

Click to expand...

I believe LtoUDP uses multicast. In my limited use of it the minivmac client was able to find the TashTalk device on its own.

I've been working on using the instructions from @finkmac but applying it to the existing MacIPRpi pre-made image for the Raspberry Pi which I already use. I've stumbled quite a bit figuring where things are located, where things are started from, etc. but feel like I'm making some progress.

My first goal is to test certain portions and bring them up as I go. First I tried to use the TashTalk Hat with tashtalkd to bridge LocalTalk to LToUDP. This seemed to work immediately. My Mini VMac emulated Mac using LToUDP was able to see the ImageWriter II over LocalTalk (using PhoneNET).

Next, I tried using tashrouter. The Raspbian Buster install didn't have the bridge software installed to define "br0" so I added that with "sudo apt install bridge-utils". I also uncommented the line in the "tap-router.py" script to get more logging output which was nice. So far, it seems like things are working half-way. The Mini VMac LToUDP seems to be picked up by tashrouter as it shows in the debug. It also seems to be sending it to the tashtalk/LocalTalk port as I can see a response coming back (in this case, my ImageWriter II). But at this point, no devices show up in the Chooser in Mini VMac. Edit: I should add that all three zones show up in Mini VMac when tashrouter is run so that works!

Note: One thing I had to do was make a couple of changes to tashrouter. There's a few instances of use of a new operator introduced in Python 3.8 called the "wallrus operator," denoted by := that doesn't work on earlier versions of Python (MacIPRpi has Python 3.7.3) and updating Python apparently isn't straight forward so I didn't try it. I instead attempted to rewrite those sections of the code to remove the walrus operator. There's a chance I got it wrong?

In anycase, I'll keep trying things and see where I get. My goal is to have a single Raspberry Pi that can act as a file and time server, but also as an AppleTalk bridge and router, all in one tiny machine!

Extended goal would be to add support for Apple Update Based Routing (AURP), the protocol used by Apple Internet Router with the IP extension added. It's basically IP tunneling of AppleTalk using UDP between other routers. There's a large group of folks using this very thing right now that a few of us started for MARCHintosh that has been colelctively called #GlobalTalk where we're printing to each other's printers, dropping files in shares, chatting with HyperCard, etc. Instllation was tricky as it seems to be limited to System 7.1 but I wrote some instructions on my blog for it. In any case, I'd love to help add support for AURP in tashrouter (there's an RFC for it that details the packets that might help.)

amedeo_68k said:

@tashtari how do you specify the IP address in LtoudpPort to connect to ?

Click to expand...

Yeah, LToUDP uses multicast, the address is defined in a constant. You can specify the parameter intf_address to LtoudpPort to bind it to a specific local address (default is to bind to all addresses), but I'm not sure that's what you're thinking of.

shirsch said:

@tashtari - Would it help if I grabbed debugging output from the router for working and non-working LT clients?

Click to expand...

A lot's happened on this thread and I've let myself get a bit behind. Has the Gatorbox always been part of the setup or have you tried a setup where it's just the IIe, TashRouter, and netatalk?

RolandJuno said:

But at this point, no devices show up in the Chooser in Mini VMac

Click to expand...

Can you get and post the debug output that comes up when you click AppleTalk ImageWriter in the Chooser? I'm interested to see where the breakdown in NBP appears to be...

RolandJuno said:

Extended goal would be to add support for Apple Update Based Routing (AURP)

Click to expand...

This is interesting, I'll have to look through the document, but I do wonder - is it better than a more modern approach involving tunneling point-to-point links over SSH or something like that?

tashtari said:

is it better than a more modern approach involving tunneling point-to-point links over SSH or something like that?

Click to expand...

No, it isn't. I wouldn't recommend implementing it. Do Internet-style routing with linknets instead over tunneled vanilla DDP. The size of any reasonable AppleTalk routing table is so tiny relative to available bandwidth at this point that the added complexity in doing delta-based routing information updates probably isn't worth it. And the rest of the IP tunneling in AIR is definitely a relict of the '90s internet, and should probably remain there and not be given to end-users any more.

I run an IP mesh with some friends (done with normal VPN protocols and a little BGP), and we definitely run weird protocols on top of that.

The whole AIR abuse is really cute, but not sustainable over the previously mentioned approach from a reliability, security, and performance standpoint. I know the mac68k.info people have their own AppleTalk VPN, which I'd like to look into sometime.

tashtari said:

Can you get and post the debug output that comes up when you click AppleTalk ImageWriter in the Chooser? I'm interested to see where the breakdown in NBP appears to be...

Click to expand...

Sure! Here's the debug output. My ImageWriter II is named Itchy & Scratchy and it doesn't show in the Chooser in Mini VMac (but the zones do!)

tashtari said:

This is interesting, I'll have to look through the document, but I do wonder - is it better than a more modern approach involving tunneling point-to-point links over SSH or something like that?

Click to expand...

At this point in time, it would only gain you compatibility with an Apple Internet Router + IP extension end point. It's clearly designed for the times and there are likely better ways to do things now. But for the moment, it's filling the need.

Cheers

tashtari said:

A lot's happened on this thread and I've let myself get a bit behind. Has the Gatorbox always been part of the setup or have you tried a setup where it's just the IIe, TashRouter, and netatalk?

Click to expand...

I have been working on a stripped down network. Netatalk 2.1.1 running on an ARM based appliance serving my lab ethenet network. TashTalk hat on RPi Zero W (latest TT firmware and latest tashtalk and tashrouter builds). The Pi Zero is connected to the network using a USB-Ethernet dongle. The Apple IIe workstation board is connected to the tashtalk hat using a pair of phone-net dongles + telco table. TashRouter is running on the Pi Zero.

Summary of issue: I can see the server from the Apple IIe 'logon' program (equivalent to chooser), authenticate and connect to a share. For almost a minute, everything works fine. Then it spontaneously drops the session. If I change nothing else and connect a //gs to the tashtalk 9-pin port everything works properly and stays connected.

If I run the tashtalkd program on the Pi, the Apple IIe can connect to a minivmac session and access the shared volume. In this arrangement (no ethertalk, just TashTalk-to-LToUDP, it works fine and stays connected.

Whatever is going wrong appears to be in the routing between ethertalk and tashtalk/localtalk. Let me know what you'd like me to gather in terms of information? Woud love to help get this working.