TashRouter: An AppleTalk Router

Tashtari

PIC Whisperer
Ah, okay, we're back to getting checksum errors. Can you put verify_checksums=False in the parameters to TashTalkPort? i.e. something like TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=2, seed_zone_name=b'TashTalk Network', verify_checksums=False),
 

RolandJuno

Active member
Ah, okay, we're back to getting checksum errors. Can you put verify_checksums=False in the parameters to TashTalkPort? i.e. something like TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=2, seed_zone_name=b'TashTalk Network', verify_checksums=False),
Yes! I've successfully been able to print four documents without issue on the ImageWriter II via LocalTalk/TashTalk!

I also tried my ImageWriter LQ with LocalTalk card. First thing I noticed is the name of the LQ was "ImageWriter LQus1?" so I decided to use The Namer to try and rename it. It shows up in The Namer, allows me to rename it and appears in the list as the new name (Just "ImageWriter LQ") but when I scan again, it shows up as the same with new random characters tacked onto the end "ImageWriter LQ4:" Not sure where the issue is (hardware or network) so I've attached a log just in case.
 

Attachments

  • tashrouter-rickards12-debugout.txt.zip
    7.8 KB · Views: 6

NJRoadfan

Well-known member
What happens if you choose a name without a space in it? Something is a bit off there. Oddly I don't see the ESC sequence in the debug being sent to the printer to rename it.
 

RolandJuno

Active member
What happens if you choose a name without a space in it? Something is a bit off there. Oddly I don't see the ESC sequence in the debug being sent to the printer to rename it.
I tried renaming it to "ImageWriterLQ" and scanned again and it read back as "ImageWriterLQ1?" sans space but with extra characters. I've included a log.

On a whim, I tried to rename the ImageWriter II. To my surprise, it too now has a strange name showing up in both The Namer and the Chooser. See screenshot.
 

Attachments

  • Screenshot 2024-03-28 at 11.18.17 PM.png
    Screenshot 2024-03-28 at 11.18.17 PM.png
    84 KB · Views: 14
  • tashrouter-rickards13-debugout.txt.zip
    7 KB · Views: 4

NJRoadfan

Well-known member
I have a feeling that the terminating null character is somehow getting eaten, or the length of the string. This looks like a buffer overrun of some sort.

EDIT: Looking at the dumps someone did here on a real LocalTalk network, looks like Namer is working fine and sending the correct packets to your printer. TashRouter appears to be forwarding them correctly as well. I would try the same copy of Namer running on a Mac directly connected to LocalTalk. There is a problem "somewhere", but I can't pinpoint where, because the debug logs show no problems "on the wire".

It could also be that the printer is really being renamed correctly and TashRouter is somehow mangling the NBPReply packet when acting as a "proxy" for the NBP bug workaround.
 
Last edited:

Tashtari

PIC Whisperer
Boy, this is a weird one. The first time we see the '4' and later the ':' added to "ImageWriter LQ", it's coming back as a BrRq from the printer, presumably to check whether that name's in use elsewhere on the network...

I think I have a theory. It's difficult to follow exactly what's happening (there's so much noise...) but I think the printer is sending a LkUp-Reply to the router directly for some reason or other and the router is turning around and sending it back, which is confusing the printer in some way. Maybe in a misguided attempt to avoid naming collisions on the network, the printer adds a random character to the end of its own name if it thinks its assigned name is in use? That'd be weird, but... that doesn't mean it isn't what's happening.

I'm gonna have to ponder how to solve this one. Good gravy, what a mess...
 

RolandJuno

Active member
I have a feeling that the terminating null character is somehow getting eaten, or the length of the string. This looks like a buffer overrun of some sort.

EDIT: Looking at the dumps someone did here on a real LocalTalk network, looks like Namer is working fine and sending the correct packets to your printer. TashRouter appears to be forwarding them correctly as well. I would try the same copy of Namer running on a Mac directly connected to LocalTalk. There is a problem "somewhere", but I can't pinpoint where, because the debug logs show no problems "on the wire".

It could also be that the printer is really being renamed correctly and TashRouter is somehow mangling the NBPReply packet when acting as a "proxy" for the NBP bug workaround.
Another data point: I used an AirTalk to connect the LocalTalk network to LToUDP (sans TashHat/TashRouter). I was able to use Namer on Mini VMac to rename the ImageWriter LQ correctly and saw that the name of the ImageWriter II "Itchy & Scratchy" was already named correctly.

@tashtari Let me now if you'd like me to test any changes.
 

NJRoadfan

Well-known member
Something is incrementing the object field length in the NBP packets. TashRouter starts off sending the right name/length, but subsequent lookup/replies increase the length value by one, adding junk data to the end of the string.
 

Tashtari

PIC Whisperer
Something is incrementing the object field length in the NBP packets. TashRouter starts off sending the right name/length, but subsequent lookup/replies increase the length value by one, adding junk data to the end of the string.
I'm pretty sure it's the printer doing that (in response to getting its own LkUp-Replies back).
 

NJRoadfan

Well-known member
A LkUpReply shouldn't be broadcasted, but addressed directly back to the requester. In this "special" case when the router gets a reply directly addressed to it, it should only be forwarded to another network, never transmitted back on the network with the printer. Looking at the trace, I see what looks like the "fixed" LkupReply going out to both the LToUDP network and TashTalk (and tap/Ethernet if that matters).
 

NJRoadfan

Well-known member
The "yielding" debug line happens when a lookup reply is intercepted and re-transmitted. Seems that information sometimes has the printer's net/node/socket in it instead of the requesting machine's information..... from a BroadcastReq that the printer sent. That packet gets sent back to the printer instead of the machine and it appears that the printer is getting confused.

EDIT: try commenting out line 262 in name_information.py. We don't need to "remember" lookup requests if we are just transmitting them back to the same network anyway.

Code:
260        # if zone is still *, just broadcast a LkUp on the requesting network and call it done
261        if zone_field == b'*':
262          self._lkup_router.remember_lkup(nbp_id, object_field, type_field, zone_field, network, node, socket)
 
Last edited:

RolandJuno

Active member
The "yielding" debug line happens when a lookup reply is intercepted and re-transmitted. Seems that information sometimes has the printer's net/node/socket in it instead of the requesting machine's information..... from a BroadcastReq that the printer sent. That packet gets sent back to the printer instead of the machine and it appears that the printer is getting confused.

EDIT: try commenting out line 262 in name_information.py. We don't need to "remember" lookup requests if we are just transmitting them back to the same network anyway.

Code:
260        # if zone is still *, just broadcast a LkUp on the requesting network and call it done
261        if zone_field == b'*':
262          self._lkup_router.remember_lkup(nbp_id, object_field, type_field, zone_field, network, node, socket)
I'm afraid commenting out line 262 in name_information.py didn't work. I tried changing the name of the ImageWriter LQ from "ImageWriterLQy7" to "ImageWriter LQ" but it ended up named "ImageWriter LQx>" instead. See log attached.
 

Attachments

  • tashrouter-rickards14-debugout.txt.zip
    8 KB · Views: 1

NJRoadfan

Well-known member
Hopefully I'm reading this right.

TashRouter picks up the Broadcast request from the printer (why is the printer outputting NBP broadcast lookup requests?), and relays it to all zones, including the TashTalk network. Somehow a LookupReply from TashRouter makes its way back to the printer, which the printer then responses with a Broadcast Request with an extra charactor in the name tuple... which keeps looping.

EDIT: Figured it out. Printer is sending out a broadcast to see if there is a name conflict. TashRouter sends out a lookup request. Printer responds to its OWN lookup request with the same packet ID number. TashRouter is sending a LookupReply back to the printer in error. Printer thinks there is a name clash (since its too dumb to check the headers to see the request is from itself), so mangles the name by a digit and repeats the process.
 
Last edited:

NJRoadfan

Well-known member
OK, a possible solution already was found in this thread. After reading @RolandJuno's numerous logs, this is "what works" per tashrouter-rickards5-debugout.txt.

-Ditch the caching of NBP Lkups. Its not needed and clearly causing issues. Revert to the name_information.py on github.
-Use long form DDP packets for all NBP packets generated by TashRouter, BUT if it is a non-extended/LocalTalk network, you must address broadcasts using the actual network number in the header, not '0' like on extended networks. Ex: a LocalTalk network assigned a number of '10', must have 10.255 as the destination address of broadcasts in long DDP headers.
-Ignore long DDP checksum verification from LocalTalk networks. Either null them out, or pass them along to the destination network, or generate a new valid one.

To summarize, the ImageWriter is indeed generating proper NBPRequestReply packets with the correct destination in the extended DDP header. It only replies if NBPLkups in extended DDP packets are addressed to the current network, not network '0'.
 

Tashtari

PIC Whisperer
OK, a possible solution already was found in this thread. After reading @RolandJuno's numerous logs, this is "what works" per tashrouter-rickards5-debugout.txt.

-Ditch the caching of NBP Lkups. Its not needed and clearly causing issues. Revert to the name_information.py on github.
-Use long form DDP packets for all NBP packets generated by TashRouter, BUT if it is a non-extended/LocalTalk network, you must address broadcasts using the actual network number in the header, not '0' like on extended networks. Ex: a LocalTalk network assigned a number of '10', must have 10.255 as the destination address of broadcasts in long DDP headers.
-Ignore long DDP checksum verification from LocalTalk networks. Either null them out, or pass them along to the destination network, or generate a new valid one.

To summarize, the ImageWriter is indeed generating proper NBPRequestReply packets with the correct destination in the extended DDP header. It only replies if NBPLkups in extended DDP packets are addressed to the current network, not network '0'.
I'm not quite ready to give up on the LkUp-Reply routing solution, I really think it's the cleanest way to resolve this...

@RolandJuno can you give this name_information.py a try? As before, just overwrite name_information.py with the one in the zip file, nothing else needs to change (in particular, verify_checksums should still be False on TashTalkPort).
 

Attachments

  • name_information4.zip
    3.6 KB · Views: 2

RolandJuno

Active member
I'm not quite ready to give up on the LkUp-Reply routing solution, I really think it's the cleanest way to resolve this...

@RolandJuno can you give this name_information.py a try? As before, just overwrite name_information.py with the one in the zip file, nothing else needs to change (in particular, verify_checksums should still be False on TashTalkPort).
This version seems to work with Namer, allowing both IM II and IM LQ to be renamed properly!

However, now both printers will no longer start printing a job and Mini VMac eventually says the printer isn't responding. Checked the Chooser and they still appear. I have attached logs for both printers.
 

Attachments

  • tashrouter-rickards15-debugout.txt.zip
    2 KB · Views: 2
  • tashrouter-rickards16-debugout.txt.zip
    2.1 KB · Views: 2

Tashtari

PIC Whisperer
However, now both printers will no longer start printing a job
...Whaaaa. This is weird. Mini vMac is looking up the printer by name and for some reason TashRouter is not forwarding the lookup. Was there an exception traceback in the output before the part that you copied? I'm wondering whether some error I made in the NBP service caused it to just completely stop responding...
 

RolandJuno

Active member
...Whaaaa. This is weird. Mini vMac is looking up the printer by name and for some reason TashRouter is not forwarding the lookup. Was there an exception traceback in the output before the part that you copied? I'm wondering whether some error I made in the NBP service caused it to just completely stop responding...
No exception that I see. I tried it again, starting the router, selecting the ImageWriter II in the Chooser, then attempting to print which eventually leads to the error that it can't be found. Log attached.
 

Attachments

  • tashrouter-rickards17-debugout.txt.zip
    4.9 KB · Views: 1

Tashtari

PIC Whisperer
No exception that I see. I tried it again, starting the router, selecting the ImageWriter II in the Chooser, then attempting to print which eventually leads to the error that it can't be found. Log attached.
Ohhh, foo, I see what I did, I created a deadlock condition. This should fix it. Thanks for bearing with me...
 

Attachments

  • name_information5.zip
    3.7 KB · Views: 3
Top