68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
TashRouter: An AppleTalk Router
Posted by: NJRoadfan on 2024-03-21 15:41:03
Its too bad I don't have an ImageWriter to confirm this, but I suspect this card is dumber than anyone expects. Its entirely possible that it just checks for DDP packets of type = 2 (NBP) and sends a response. That is, if anyone sends a NBPLkup on the network, even for types that aren't an ImageWriter (ex: looking for type AFPServer), it unconditionally sends out a NBPLkupReply with the printer's information. It also solves the problem that the card would need to respond to different NBP types depending on the type of printer it is installed in (The IWLQ responds with type "LQ" instead of "ImageWriter"). No need to waste CPU resources parsing the NBP tuple at all! Very Woznian if the engineers at Apple did it like that.
Posted by: cheesestraws on 2024-03-21 15:42:46
Oh, that's plausible and clever.
Posted by: Tashtari on 2024-03-21 16:01:46
Very Woznian
plausible and clever
Ick, I disagree, it's not clever, it's lazy and halfassed. =/
Posted by: NJRoadfan on 2024-03-21 16:06:36
OK, more investigation revealed that the Fastpath is actually sending the source network's router in the NBPLkup extended DDP packet, which may not be the Fastpath itself. I didn't notice because my source node doing the lookup was also a router (netatalk's atalkd). Turning off netatalk and letting the Fastpath run the show, and I now see its Ethernet side address popping up as the source on long DDP NBPLkups from the Ethernet side.

So.... the ImageWriter likely is parsing the NBP tuple for the reply address.... but only if it is in a long DDP packet. I also don't think the Fastpath verifies DDP checksums, so if the ImageWriter were to send out a bad one, the FastPath just passes it along or it gets stripped off to 0x0000.... or if DDP checksum option is set to "on", generates a new one.
Posted by: Tashtari on 2024-03-21 17:52:28
So.... the ImageWriter likely is parsing the NBP tuple for the reply address.... but only if it is in a long DDP packet.
That is so weirdly specific in its incorrectness, I wonder how they managed to screw it up like that.

I also don't think the Fastpath verifies DDP checksums, so if the ImageWriter were to send out a bad one, the FastPath just passes it along or it gets stripped off to 0x0000.... or if DDP checksum option is set to "on", generates a new one.
That makes me sad. =(
Posted by: cheesestraws on 2024-03-21 17:52:31
Ick, I disagree, it's not clever, it's lazy and halfassed. =/

clever (derogatory)
Posted by: Tashtari on 2024-03-21 17:53:58
clever (derogatory)
Okay, good. =D Sarcasm over the internet doesn't translate well.
Posted by: cheesestraws on 2024-03-21 17:57:43
Less sarcasm, more a kind of aesthetic appreciation for misapplied laziness :-D Anyway, not to thread derail any further...
Posted by: NJRoadfan on 2024-03-21 19:21:57
OK, found a reference to ImageWriter use and the FastPath.

DDP checksums

groups.google.com groups.google.com

Looks like the faulty checksums are passed thru the Fastpath and some clients balked at them. NBP was working for them though. I have both K-STAR 8.1.1 and 9.1.2, I could load each one and see how checksums are passed from the LocalTalk side of things.

I have no way to confirm whether or not the 1989 post about the MultiGate is true. The poster clearly stated that the IW was reading the header data, not the NBP tuple for the source address, which makes more sense from a lazy programmer's perspective. Also looks like one router caches NBPBrRqs to compensate for the bug: https://groups.google.com/g/comp.protocols.appletalk/c/2so0gBHgv6g/m/ZoW3RK1JHx4J

Also DDP Checksums were poorly supported. Macs disabled them by default (can confirm in System 7) and there is other hardware that screws it up (early LaserWriter NTR ROMs).

ForceDDPCheckSum

groups.google.com groups.google.com

Importance of DDP checksums?

groups.google.com groups.google.com

papif checksum errors

groups.google.com groups.google.com
Posted by: Tashtari on 2024-03-22 03:30:08
Uffa. Adding options concerning checksum calculation and checking to TashRouter would be a pain. They're supposed to be hard-coded parts of a data structure, not parameters that require tuning. But I might have to do it anyway.

I don't fault Apple for making them optional. The experience with writing PicoATP showed me that in embedded devices, you really want the option not to generate one, and I suppose in a way the ImageWriter's faulty behavior in calculating the checksum drives it home... but jeez, what a mess.
Posted by: Tashtari on 2024-03-22 04:07:54
Okay, it was less difficult than I feared. I added two new parameters to all types of ports, verify_checksums and calculate_checksums. They default to True, because that's how it should be... but you can set them to False on an individual port basis. I considered optionally storing and passing the incoming checksum, right or wrong, but I really don't see a case where that'd be desirable functionality.
Posted by: Tashtari on 2024-03-23 03:29:40
Paging @RolandJuno - it's gotten a bit buried now, but can you test this on your ImageWriter?

I'm wondering if you'll get checksum errors trying to print because the ImageWriter has to send long-header datagrams in the course of handling a print job from a machine on a different network (or if it only gets the checksum wrong when generating an NBP reply)... if you do, though, you can add verify_checksums=False to the TashTalkPort constructor.
Posted by: RolandJuno on 2024-03-27 16:06:57
Paging @RolandJuno - it's gotten a bit buried now, but can you test this on your ImageWriter?

I'm wondering if you'll get checksum errors trying to print because the ImageWriter has to send long-header datagrams in the course of handling a print job from a machine on a different network (or if it only gets the checksum wrong when generating an NBP reply)... if you do, though, you can add verify_checksums=False to the TashTalkPort constructor.
I deleted my current install, pulled the latest repo, and replaced the "service/name_information.py" file with the one from your previous post.

Unfortunately the ImageWriter II on LocalTalk/TashTalk doesn't show up in the Chooser in Mini VMac via LToUDP. So I wasn't able to print anything. I can see the IW II printer name "Itchy & Scratchy" showing up in the log though. Tashrouter log attached.
Posted by: NJRoadfan on 2024-03-27 18:04:51
The printer is responding to the NBPLkup packets back to TashRouter as expected. The changes to TashRouter are supposed to relay/transmit the response back to the requesting machine.
Posted by: Tashtari on 2024-03-28 05:45:42
Hmm, TashRouter is not routing the reply from the ImageWriter as expected. I found and fixed a small error that could explain why, also added some more debug output in case I'm wrong... can you drop this on top of name_information.py and retry? (You shouldn't have to re-pull, this is the only file that's changed)
Posted by: RolandJuno on 2024-03-28 07:29:30
Hmm, TashRouter is not routing the reply from the ImageWriter as expected. I found and fixed a small error that could explain why, also added some more debug output in case I'm wrong... can you drop this on top of name_information.py and retry? (You shouldn't have to re-pull, this is the only file that's changed)
There's a Python exception when I select the ImageWriter LocalTalk driver in the Chooser. Log attached.
Posted by: Tashtari on 2024-03-28 07:45:01
Aw, ding dangit, I knew I was going to make another dumb mistake. Can you insert the line import logging at the top of the file and retry? =)
Posted by: RolandJuno on 2024-03-28 07:51:51
Aw, ding dangit, I knew I was going to make another dumb mistake. Can you insert the line import logging at the top of the file and retry? =)
Same as before, the ImageWriter II on LocalTalk/TashTalk doesn't appear in the Chooser in Mini VMac LToUDP. Log attached.
Posted by: Tashtari on 2024-03-28 08:25:48
..hah. I forgot how regular expressions work. Okay, THIS time for sure.
Posted by: RolandJuno on 2024-03-28 08:40:09
..hah. I forgot how regular expressions work. Okay, THIS time for sure.
Ok, this time the ImageWriter Itchy & Scratchy DOES show in the Chooser on Mini VMac LToUDP and I'm able to select it. I then attempted to start a print job but the printer doesn't do anything (aside from ejecting the paper randomly long after I stopped the job). I went to the Chooser and it's still listed, and attempted to print again a couple of times. No printing on the printer. Log attached.
< 17 >