TashRouter: An AppleTalk Router

[finkmac]

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.


The Raspbian Buster install didn't have the bridge software installed to define "br0" so I added that with "sudo apt install bridge-utils".

this is my bad, technically bridge-utils is deprecated. There's newer incantations to do the same with the "ip" command.

 

[tashtari]

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

Hokay, so...

// 2.252 is ImageWriter
// 1.39 is Mini vMac

// Mini vMac puts out the BrRq for ImageWriters:
frame in                LToUDP  254  39  type 01          b"\x00+\x02\xfe\x02\x11\x12\x00\x01'\xfe\x00\x01=\x0bImageWriter\x10TashTalk Network"
// TashRouter receives it:
in to 1.254             LToUDP   0 0.254 0.39    2 254 2  b"\x11\x12\x00\x01'\xfe\x00\x01=\x0bImageWriter\x10TashTalk Network"
// And zone-wide broadcasts a LkUp:
out to TashTalk Network ttyAMA0  0 0.255 2.254   2   2 2  b"!\x12\x00\x01'\xfe\x00\x01=\x0bImageWriter\x10TashTalk Network"
// ImageWriter receives it:
frame out               ttyAMA0 255 254  type 01          b"\x00+\x02\x02\x02!\x12\x00\x01'\xfe\x00\x01=\x0bImageWriter\x10TashTalk Network"
// And responds with a LkUp-Reply:
frame in                ttyAMA0 254 252  type 01          b'\x00+\x02\x02\x021\x12\x00\x02\xfc\x8a\x01\x10Itchy & Scratchy\x0bImageWriter\x01*'
// TashRouter receives it:
in to 2.254             ttyAMA0  0 0.254 0.252   2   2 2  b'1\x12\x00\x02\xfc\x8a\x01\x10Itchy & Scratchy\x0bImageWriter\x01*'
// ...and does nothing.

Unless the NBP process in the router has a responsibility that I'm not aware of, I think the ImageWriter's behavior is at fault here. The LkUp that TashRouter broadcasts is saying basically "Are you an ImageWriter? If so, tell 1.39 (Mini vMac) that you exist." The LkUp-Reply that the ImageWriter is sending says "Hey, 2.254 (TashRouter on TashTalk Network), I exist!" And TashRouter is like "Uh, okay. I didn't ask, but sure, whatever." and discards the LkUp-Reply. The ImageWriter should have sent a LkUp-Reply addressed to 1.39, then TashRouter would have forwarded it and the ImageWriter would have appeared in the Chooser.

Are AppleTalk ImageWriters able to work on AppleTalk networks with routers, or are they stuck in a past where AppleTalk and LocalTalk were one and the same?

 

[NJRoadfan]

The ImageWriter LocalTalk card should support routers. I also suspect something like this is causing the Apple II Workstation Card to freak out (that might have to do with long vs. short DDP packets, and packets addressed to network '0'). Sadly I have neither a Workstation Card nor an ImageWriter to test these things out and packet trace them.

One option that has a bit of a setup curve is to take TashRouter out of the equation and run modtashtalk plus netatalk's atalkd to do the routing between Ethernet and LocalTalk. Heck, I'd take a peek at atalkd's source and see what its doing with NBP Lookups across the router.

On the subject of a netatalk appliance, I have been testing integrating TashRouter into A2SERVER, mainly for its LToUDP routing. My preferred solution is to avoid the network bridges and macvtap method since they seem to all have their quirks depending on the system. I instead created a tap interface called 'tap0', setup the appropriate lines in atalkd.conf and the TashRouter startup program, and let them route that way. So far there are no issues other than an extra "virtual" network hop over the tap interface. One could even setup a tap enabled emulator like MAME on the machine and ...aham..... tap into the network. I will post this configuration later tonight if anyone is interested.

 

[shirsch]

The ImageWriter LocalTalk card should support routers. I also suspect something like this is causing the Apple II Workstation Card to freak out (that might have to do with long vs. short DDP packets, and packets addressed to network '0'). Sadly I have neither a Workstation Card nor an ImageWriter to test these things out and packet trace them.

I will offer - again - to run packet traces on the setup. I just need a modicum of information on how to setup for this. I assume Wireshark must be run on the Pi Zero, correct?

 

[tashtari]

might have to do with long vs. short DDP packets, and packets addressed to network '0'

Where are you thinking this goes into the equation? All the traffic to and from the ImageWriter is in short-header DDP datagrams, including the reply, which should be a long-header DDP datagram but isn't...

 

[NJRoadfan]

@shirsch You can run TashRouter in debug mode to get output similar to above. Another option is to run a Mac on the same LocalTalk segment and use a LocalTalk packet sniffer. On the Ethernet side, you can run Wireshark, set the filter to "atalk", which should give you all the DDP packets coming across the network.

@tashtari, its just a hunch. The ImageWriter LocalTalk card is a bit limited hardware-wise compared to most clients. There is definately something up with its firmware. @RolandJuno Since you have an AppleTalk Internet Router install setup, is it possible to use that machine to route between LocalTalk and Ethernet? See if an Ethernet connected Mac can see the ImageWriter? Maybe run a packet sniffers on both LocalTalk and Ethernet to see what the ImageWriter replies with and how AIR forwards the NBP replies? That would point to any "special handling." I don't see anything obvious in the netatalk source for this.

Also "Inside AppleTalk" page 7-10 is pretty vague on how cross-router network replies should be handled, just "The NBP replies are returned to the original requester." Technically from the ImageWriter's point of view, the original requester is the router! There is reference to a NBP ID in the packet header, so the router at least has a way to keep track of these packet broadcasts if needed.

 

[shirsch]

I hate to bring this up, but is it possible that the router needs to hold some state to properly route the reply packets back to the original sender?

 

[NJRoadfan]

AHA! This is a known problem with the ImageWriter LocalTalk card, see: https://groups.google.com/g/comp.sys.mac/c/Uh7YcyzB7mg/m/uSf2jikYEfwJ

The solution to this (implemented in the current version of Megan) is
to breach the layering, and have Megan send the LkUp with the DDP header
containing the address of the requesting client, much as if it was
simply forwarding a packet (which is really not a nice thing to do,
as Megan is actually sending a new packet here).

Earlier versions of Megan actually implemented this, but as a special case,
only where the nbp type of the lookup was "ImageWriter", other lookups
were handled properly. However the LQ ImageWriter (which uses "LQ"
as the type) and Apple's spooler (which changes the type of the printer so
only the spooler will be able to actually find the real printer) broke
that scheme, so now Megan does the wrong thing all of the time. Its sad.

@tashtari Looks like at least one router rewrites ALL NBPLkup packets with the sender's address because of bad behavior and crappy firmware. Likely because it was less resource intensive then to parse all NBPLkup packets for the type and selectively apply the special headling.

@shirsch The router only needs to maintain a routing table and a zone lookup table (which zones belong to which networks). The router broadcasts RTMP tuple packets every few seconds that tell the clients how to access other networks.

 

[shirsch]

@shirsch You can run TashRouter in debug mode to get output similar to above. Another option is to run a Mac on the same LocalTalk segment and use a LocalTalk packet sniffer. On the Ethernet side, you can run Wireshark, set the filter to "atalk", which should give you all the DDP packets coming across the network.

Wireshark is not a problem, but a few minutes poking around the web fails to turn up any localtalk packet sniffer able to run on a 68k mac. Do you have a package name I can look for?

 

[shirsch]

AHA! This is a known problem with the ImageWriter LocalTalk card, see: https://groups.google.com/g/comp.sys.mac/c/Uh7YcyzB7mg/m/uSf2jikYEfwJ



@shirsch The router only needs to maintain a routing table and a zone lookup table (which zones belong to which networks). The router broadcasts RTMP tuple packets every few seconds that tell the clients how to access other networks.

This is interesting:

I've seen a problem with ATIWs and gateways, if the NBP lookups to the zone
which the ATIW is in is sent to a gateway and that gateway resends it
using a type 1 (short) DDP packet, the name listener in the ATIW seems to reply
to the gateway, rather than the requester address included in the NBP
packet.

Look for the NBP request and it's response, who is it sent to?

Fortunately my gateway code has an option that lets you configure it to only
generate type 2 (long) DDP packets.

Is there a way that TashRouter can forward a "long" DDP packet on behalf of the original sender?

 

[NJRoadfan]

I think TashRouter is already sending "long" DDP packets to LocalTalk clients. A program called "LocalPeek" can be used for the task of sniffing. Apple also released a program, AppleTalk Peek: https://macintoshgarden.org/apps/appletalk-peek-program

 

[RolandJuno]

This is fascinating! A bug in the LocalTalk option card that Apple likely quietly fixed in software elsewhere?

Is there a way to use tashrouter in an eavesdropping mode and monitor tashtalk and LToUDP? I can use it to monitor Apple Internet Router routing the ImageWriter (I have the II and an LQ) with an AirTalk (which does work).

 

[shirsch]

@shirsch You can run TashRouter in debug mode to get output similar to above.

I currently see a setting of:

logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s')

but there's nothing coming out but initialization messages. No traffic. How do I make it more talkative?

 

[NJRoadfan]

We already have the answer (commercial routers rewrite the header), so really no need to do any ImageWriter NBPLkup snooping. I don't know if TashRouter has a promiscuous debug/dump mode for LocalTalk networks.

 

[cheesestraws]

Do you have a package name I can look for?

A program called "LocalPeek" can be used for the task of sniffing. Apple also released a program, AppleTalk Peek

There's a third option called NetMinder LocalTalk.

 

[shirsch]

I was interested in capturing Apple IIe session traffic, not Imagewriter snooping. That's what @tashtari requested a few messages up.

 

[NJRoadfan]

Further info about the ImageWriter and NBP Packets. Looks like the MultiGate just forces all NBP packets to have "long" DDP packets when forwarded to LocalTalk to fix the problem: https://groups.google.com/g/comp.protocols.appletalk/c/2so0gBHgv6g/m/PhT_40v2OnMJ

 

[shirsch]

Further info about the ImageWriter and NBP Packets. Looks like the MultiGate just forces all NBP packets to have "long" DDP packets when forwarded to LocalTalk to fix the problem: https://groups.google.com/g/comp.protocols.appletalk/c/2so0gBHgv6g/m/PhT_40v2OnMJ

That's what I meant when I said "forward long packets on behalf of the sender" in an earlier post above.

And at least one design is stateful:

If I remember correctly the ImageWriter does not answer NBP lookups
properly. Instead of sending the answer to the node mentioned in the
NBP header it will send the reply to the sender of the NBP lookup,
which might be a router. Most routers I know compensate for that by
forwarding the NBP reply to the originator of the broadcast request
that caused the lookup.  The way I have solved the problem in our
routing software costs about 1 kB data to keep information about recent
BrRq's, this might not be feasible in the RAM limited world of a
typical router box.

 

[tashtari]

AHA! This is a known problem with the ImageWriter LocalTalk card, see: https://groups.google.com/g/comp.sys.mac/c/Uh7YcyzB7mg/m/uSf2jikYEfwJ

Great find!

Is there a way that TashRouter can forward a "long" DDP packet on behalf of the original sender?

Should be possible, let me do some coding and see if I can make this happen reasonably cleanly...

How do I make it more talkative?

Is there a way to use tashrouter in an eavesdropping mode and monitor tashtalk and LToUDP?

The line set_log_str_func(logging.debug) in your test_router.py (or whatever you've named it) should make it spit out all datagrams and frames that it sees. Does this produce the output you're looking for?

 

[NJRoadfan]

LocalTalk clients should have no issues with "long" DDP packets. Apple explicitly stated that "short" form packets are used for efficiency reasons and are only to be used talking to nodes within the same network. In https://github.com/lampmerchant/tashrouter/blob/main/tashrouter/port/localtalk/__init__.py

Commenting out lines 152 to 154 should force all packets from TashRouter to "long" form.