this is my bad, technically bridge-utils is deprecated. There's newer incantations to do the same with the "ip" command.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
TashRouter: An AppleTalk Router
- Thread starter Tashtari
- Start date
Hokay, so...
Code:
// 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?
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.
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.
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?
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...
@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.
@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.
AHA! This is a known problem with the ImageWriter LocalTalk card, see: https://groups.google.com/g/comp.sys.mac/c/Uh7YcyzB7mg/m/uSf2jikYEfwJ
@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.
@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.
Last edited:
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?
This is interesting:
Code:
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.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
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).
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).
I currently see a setting of:
Code:
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s')
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:
Code:
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.Great find!
Should be possible, let me do some coding and see if I can make this happen reasonably cleanly...
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?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.
Commenting out lines 152 to 154 should force all packets from TashRouter to "long" form.
