TashRouter: An AppleTalk Router

[treellama]

This is great, thanks for getting back to this!

 

[NJRoadfan]

Did anyone try this PR with an ImageWriter? https://github.com/lampmerchant/tashrouter/pull/2

This matches the behavior observed with a Shiva Fastpath 5 (at least from what I remember). Usenet posts state that the fix for the ImageWriter card was to always have a router send it NBP Lookups with DDP long packets which have the sender's source address in the header.

 

[fergycool]

I checked it out and it works fine for me. With the new "route_lkup_replies=True" parameter I am able to print from an EtherTalk connected Macintosh to an LocalTalk connected ImageWriter II just fine (good test out for my newly acquired color ribbons!).

At the risk of public humiliation but for anybody else who tries this and also does not read posts correctly. TapPort needs to be renamed to LinuxTapPort in your starting script! ;-)

 

[fergycool]

I spoke too soon. After that first print the IMII disappeared from the network. There are these errors:

Jul 11 13:05:14 wolfalice python3[18424]: Exception in thread Thread-13 (_run):
Jul 11 13:05:14 wolfalice python3[18424]: Traceback (most recent call last):
Jul 11 13:05:14 wolfalice python3[18424]: File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
Jul 11 13:05:14 wolfalice python3[18424]: self.run()
Jul 11 13:05:14 wolfalice python3[18424]: File "/usr/lib/python3.11/threading.py", line 975, in run
Jul 11 13:05:14 wolfalice python3[18424]: self._target(*self._args, **self._kwargs)
Jul 11 13:05:14 wolfalice python3[18424]: File "/home/chris/src/tashrouter1/tashrouter/service/name_information.py", line 326, in _run
Jul 11 13:05:14 wolfalice python3[18424]: router.route(Datagram(hop_count=0,
Jul 11 13:05:14 wolfalice python3[18424]: File "/home/chris/src/tashrouter1/tashrouter/router/router.py", line 155, in route
Jul 11 13:05:14 wolfalice python3[18424]: entry.port.unicast(datagram.destination_network, datagram.destination_node, datagram)
Jul 11 13:05:14 wolfalice python3[18424]: File "/home/chris/src/tashrouter1/tashrouter/port/localtalk/__init__.py", line 167, in unicast
Jul 11 13:05:14 wolfalice python3[18424]: self._send_frame_with_short_header(node, datagram)
Jul 11 13:05:14 wolfalice python3[18424]: File "/home/chris/src/tashrouter1/tashrouter/port/localtalk/__init__.py", line 152, in _send_frame_with_short_header
Jul 11 13:05:14 wolfalice python3[18424]: self.send_frame(bytes((destination_node, self.node, self.LLAP_APPLETALK_SHORT_HEADER)) + datagram.as_short_header_bytes())
Jul 11 13:05:14 wolfalice python3[18424]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jul 11 13:05:14 wolfalice python3[18424]: File "/home/chris/src/tashrouter1/tashrouter/datagram.py", line 125, in as_short_header_bytes
Jul 11 13:05:14 wolfalice python3[18424]: raise ValueError('invalid hop count %d, short-header datagrams may not have non-zero hop count' % self.hop_count)
Jul 11 13:05:14 wolfalice python3[18424]: ValueError: invalid hop count 1, short-header datagrams may not have non-zero hop count

 

[Tashtari]

I spoke too soon. After that first print the IMII disappeared from the network. There are these errors:

Hmm. So this is caused by LkupRouter routing a datagram that it's pretending it didn't originate, which means it'll have a hop count of 1, which means it can't be short-form... but it tries to make it short form and fails. I could solve this one of two ways:

One, I could force the generated LkUp-Reply to be a long-form DDP datagram. This is what I'm inclined to do, but I'm worried about this creating incompatibilities with edge cases like the Apple IIe Workstation Card trying to print to an ImageWriter on a different LocalTalk network. That is, the Workstation Card sends a BrRq to TashRouter on its network, this gets converted to a LkUp on the ImageWriter's network, whose LkUp-Reply gets sent by the braindead ImageWriter to the router address on its own network, which the LkupRouter realizes should have been sent to the Workstation Card, so it sends it to the Workstation Card... which doesn't understand long-form DDP datagrams. Anyone know if this is a valid concern? Does the Workstation Card understand long-form DDP datagrams? Is it even capable of sending BrRqs to a router?

Two, I could mark the generated LkUp-Reply as being originated from TashRouter, which means it'll have a hop count of 0 and therefore be able to be a short-form DDP datagram. But... this is an outright lie rather than a corrected error. However, if the situation I described above with the IIe Workstation Card is a real possibility, this may be the only way to proceed.

Paging @NJRoadfan - what do you think of this? (Anyone else welcome to weigh in too, of course.)