TashRouter: An AppleTalk Router

[Tashtari]

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]

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.

 

[NJRoadfan]

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]

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.

 

[NJRoadfan]

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.

 

[Tashtari]

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]

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]

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]

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]

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]

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.

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)

 

[RolandJuno]

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.

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.

 

[NJRoadfan]

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.

 

[NJRoadfan]

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]

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

 

[RolandJuno]

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.

 

[Tashtari]

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]

...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.

 

[Tashtari]

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...

 

[RolandJuno]

Ohhh, foo, I see what I did, I created a deadlock condition. This should fix it. Thanks for bearing with me...

Unfortunately, I don't see any change from before. Log attached.