TashRouter: An AppleTalk Router

[tashtari]

Is this still happening with the latest code?

I ask because I'm wondering if something interesting is happening on your network with regard to network number 999. If that's your seed network number for the LToUDP port, there should be an entry in the routing table with a distance of 0, which means it doesn't age out, so the fact that it is aging out makes me wonder if there's an unintended code path that's allowing it to get replaced. Can you upload the full log of a session where the LToUDP network gets aged out?

 

[NJRoadfan]

@mmjs Are other LocalTalk connected devices working without issue connected to the TashTalk? Is the Mac 512k the only LocalTalk device on the network? Are you using PhoneNet to connect the machines and if so, are the ends properly terminated with a resistor plug?

Note: The destination network field in RTMP broadcasts on LocalTalk is irrelevant as short DDP packets don't include that information. IT is not the source of the problem.

What System Software version is the 512k running? Is it something like the AppleShare Workstation 1.1 disk? Looking to replicate at least the software side here to test.

With regards to the LToUDP network aging, are you connected to GlobalTalk via AIR? Its likely there is a network number conflict. If TashRouter is seeding that network, it shouldn't be aging it out. See if it works ok isolated from AIR. There could also be weird bugs being exposed in TashRouter due to the high number of networks it has to keep track of (routing table overflow?).

 

[NJRoadfan]

I loaded up the 400k AppleShare Workstation 1.1 for Mac 512k image in minivmac. Other than having to close and reopen Chooser to list zones on a cold boot, I am having no issues connecting to my netatalk box and running applications directly off of the server. Connection is behaving, no timeouts or locking up. Granted, it is emulating a Mac Plus with Plus ROMs, not a 512k, but it shouldn't matter too much for AppleTalk. I'm pointing towards the issues with the Mac 512k being cabling.

Checking packets with "Watcher", I can confirm that RTMP broadcasts are short DDP packets now. NBPLkup packets are also short DDP packets, which may pose an issue for ImageWriters.

 

[mmjs]

This is correct - to the best of my knowledge, the TashTalk 2 Hat that I sell requires the use of a LocalTalk or PhoneNet dongle. It connects the Rx and Tx lines together, which isn't a problem when they go into the same transformer, but this is not what the Mac expects when speaking LocalTalk over its ports.


Is this still happening with the latest code?

Happy to report that once I changed destination_network to port.network in the latest code the 512K is happy!

Additionally, I found a pin issue on my PhoneNet adapter, which fixed the discrepancy with zones not showing up. Ultimately it looks like it was the combo of the timeout, which did get fixed with the rtmp fix, and the physical connection problem. Thanks for working through it with me!

I loaded up the 400k AppleShare Workstation 1.1 for Mac 512k image in minivmac. Other than having to close and reopen Chooser to list zones on a cold boot, I am having no issues connecting to my netatalk box and running applications directly off of the server. Connection is behaving, no timeouts or locking up. Granted, it is emulating a Mac Plus with Plus ROMs, not a 512k, but it shouldn't matter too much for AppleTalk. I'm pointing towards the issues with the Mac 512k being cabling.

Checking packets with "Watcher", I can confirm that RTMP broadcasts are short DDP packets now. NBPLkup packets are also short DDP packets, which may pose an issue for ImageWriters.

Thanks for this @NJRoadfan ! You pointed me in the right direction and this is how I found the pin issue on my PhoneNet dongle!

 

[tashtari]

Happy to report that once I changed destination_network to port.network in the latest code the 512K is happy!

Does it not work with the current code as shipped in the repo? As @NJRoadfan said, the network shouldn't make a difference since broadcast datagrams use the short LocalTalk header which doesn't include the network at all...

 

[mmjs]

Does it not work with the current code as shipped in the repo? As @NJRoadfan said, the network shouldn't make a difference since broadcast datagrams use the short LocalTalk header which doesn't include the network at all...

You are completely right, no intervention is necessary. Working great with the code as shipped. Thank you!

 

[tashtari]

Working great with the code as shipped. Thank you!

Cool! All right, on to the ImageWriter problem...

@RolandJuno I took a look at your trace and... it's strange. It does look like the printer is discoverable at first using long-header DDP datagrams, albeit with the wrongly-calculated checksum, but then seems to go down a bad code path of some kind - those strings of type 0x84 frames are apparently the printer trying to contact something at the invalid LocalTalk address 0. That's not a good sign, but I notice the trace is showing the RTMP broadcasts as being in long-header format which means there's some newer code that you haven't tried yet... I'm wondering if the printer's getting confused because it hasn't received a short-header RTMP broadcast recently.

Can you pull the latest code and apply those same three patches to it?

• datagram.py - comment out lines 45-48
• port/localtalk/__init__.py:165 - change SHORT and short to LONG and long
• service/name_information.py:111 - change 0x0000 to entry.port.network

 

[NJRoadfan]

The latest build still works for netbooting the IIgs off my netatalk box via TashTalk. So far no regressions to report for my devices. I was pretty impressed that AppleShare Workstation 1.1 was able to connect to my Ethernet connected Basilisk II machine running personal file sharing on MacOS 8.1.

 

[tashtari]

The latest build still works for netbooting the IIgs off my netatalk box via TashTalk. So far no regressions to report for my devices. I was pretty impressed that AppleShare Workstation 1.1 was able to connect to my Ethernet connected Basilisk II machine running personal file sharing on MacOS 8.1.

Nice! Love to see it.

 

[shirsch]

Everything is working fine for me. Spent a boring hour bringing various Apple machines up and down, netbooting, browsing, etc. No problems at all.

Here's my first attempt at a dedicated 3d printed case. A lot of hand rework involved to get things fitting correctly. Now to put a gun to my head and learn Fusion 360 so I can make a remix..

 

[NJRoadfan]

Doing some packet sniffing on the Fastpath 4 (onboard circa 1988 ROM) and 5 (latest 1992 release), they both send long DDP packets for NBPLkups. By default they do not generate a checksum. The Fastpath 5 has an option to generate them for LocalTalk if you want.

 

[shirsch]

Doesn't that imply the IIe would have session problems with both? I used it with a FastPath 4 for years before getting my first Gatorbox. Never had a problem. IIRC, it was the FP 5 that never cooperated.

 

[NJRoadfan]

Both output identical NBPLkup packets. Now there is a difference in the header with TashRouter and likely a bug.

TashRouter (LToUDP Network is 5):
Destination 0.255
Source: 5.254

FastPath 4 and 5 (LocalTalk port is network 5, Ethernet side is network 1-1):
Destination 5.255
Source: 1.1

The Fastpath broadcasts NBPLkup packets using the LocalTalk network's actual number, not network '0'. The Fastpath uses the source of the NBPLkup to fill out the source address, not the router's address.

Note I had to edit line 136 to get TashRouter to respond with the actual network number vs. 0x0000. Editing line 111 didn't have any effect.
I don't know how this will effect the Ethernet side of things!

 

[NJRoadfan]

Seems that Inside AppleTalk is a bit vague what the DDP header has to look like on NBPLkup packets generated by a router from a NBP Broadcast request. Technically how TashRouter is doing it should be fine as the NBP tuple has the source/reply address of the request in it. Really depends on how a node is parsing the packet and depending on whats in the DDP header. It also maybe a bug in TashRouter.

 

[NJRoadfan]

OK, re-reading the USENet post about how the Weber Multigate fixed the ImageWriter issues, basically the Fastpath does this out of the box. It mudges all NBPLkup packets it generates with the original sender's address in the DDP header source fields. The way TashRouter does it is technically the "legal way". I have a patch that does this mudging nicely.

Grab the latest TashRouter source. In name_information.py:
Line 112 & 136 change "entry.port.network" to "req_network"
Line 114 & 138 change "entry.port.node" to "req_node"

This should "fix" the ImageWriter.

You can Optionally change Line 111 & 135 from "0x0000" to "entry.port.network" to get the broadcast destination to report the current network vs. "0", but I doubt its really needed for this. Also, I don't know if this will have ill effects on the Ethernet side of things.

 

[tashtari]

Now there is a difference in the header with TashRouter and likely a bug.

When you say "now", have you made a change to the code? I ask because what's in the repo right now sends short-header datagrams for multicasts and broadcasts (over LocalTalk, anyway, which is what I assume you're referring to).

The way TashRouter does it is technically the "legal way".

I'd like for TashRouter to be lawful-good, if I can manage it. I really want to avoid "fixing" things by fudging the headers... to that end, I've done a pretty substantial rewrite of name_information.py to make it keep track of LkUps that it sends and route them to their intended destination when a braindead ImageWriter sends a LkUp-Reply directly to the router. Could anyone with an ImageWriter please give this a try? Just pull the latest from the repo and then overwrite service/name_information.py with the one attached to this post:

 

[NJRoadfan]

I modified TashRouter to send out long DDP headers over LocalTalk for Multicast packets along with the above changes. Boxen like the Fastpath don't have the resources to keep track of NBPLkups, so a hack that isn't resource intensive is always a plus. Sadly Apple's docs have gaps and Apple's engineers played fast and loose with what was documented. I suspect the "norm" for NBPLkups on routed LocalTalk is long DDP headers.

Its interesting to note that despite that Usenet post being from 1989 that Kinetics already had implemented this workaround in the Fastpath 4's PROM firmware by mid-1988. I know the original Stanford University SEAGATE router code that the Fastpath is based on is out there. I should take a peek and see what it does. I chuckle at the lamenting over breaking a "well layered" product in that old post. If only they knew the horrors coming to IPv4 in the form of NAT!

 

[tashtari]

I suspect the "norm" for NBPLkups on routed LocalTalk is long DDP headers.

My understanding must be flawed somewhere.

My interpretation was that the behavior of the ImageWriter is that, on receiving a short-header multicast NBP datagram, it'll respond to the router that sent it (rather than using the return address in the NBP datagram as it should do), and on receiving a long-header multicast NBP datagram, it'll respond to the correct address but with an incorrect checksum.

I must be misunderstanding something, because in the short-header case, there's no way to fudge the return address so it appears to come from the original sender (since there's no source/destination network in the short header), and in the long-header case, if it responds to the right address, all you need to do is ignore the checksum, there's no need to fudge the header.

Am I wrong somewhere?

 

[NJRoadfan]

This is how I'm interpreting the behavior of the ImageWriter LocalTalk card.

The card doesn't seem to read the sender's address in the NBPLkup packet's tuple at all, instead:

-If the card receives a short form DDP NBPLkup, it sends the reply back to the node in the LLAP header.
-If the card receives a long form DDP NBPLkup, it sends the reply back to the source network and node specified in the DDP header.
-The card appears to send back long form DDP NBPLkupReply packets with invalid DDP checksums.

-It is likely all commercial routers send long form DDP packets for NBP traffic that they originate (including the Weber MultiGate). This is expected since if you have a router, it is assumed that you are on an inter-network with network numbers. The routers I have access to put the original sender's address of the NBPLkup in the header as the source, NOT the router's address, likely because of faulty clients like (only?) the ImageWriter. This is technically breaking the "well layered" rules since packets originating from the router (not forwarded from another network) should have the router as the source. The Ethernet side of the Fastpath generates NBPLkup packets with the router's address as the source as it should, clearly this is a LocalTalk only hack!

 

[tashtari]

Okay, I think I misinterpreted that it got the right address out of the NBP header but only if it came with a long-header datagram... that didn't make much sense anyway. I'm hoping that the rewrite of name_information.py that I did will take care of the situation without forcing bad behavior on the router - since we're only communicating in short-header datagrams, the bad checksum calculation doesn't become an issue, and the router just does routing on an extra level. "Just".