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.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
TashRouter: An AppleTalk Router
- Thread starter tashtari
- Start date
cheesestraws
Well-known member
Oh, that's plausible and clever.
tashtari
PIC Whisperer
Ick, I disagree, it's not clever, it's lazy and halfassed. =/
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.
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.
Last edited:
tashtari
PIC Whisperer
That is so weirdly specific in its incorrectness, I wonder how they managed to screw it up like that.
That makes me sad. =(
cheesestraws
Well-known member
clever (derogatory)
tashtari
PIC Whisperer
Okay, good. =D Sarcasm over the internet doesn't translate well.
cheesestraws
Well-known member
Less sarcasm, more a kind of aesthetic appreciation for misapplied laziness :-D Anyway, not to thread derail any further...
OK, found a reference to ImageWriter use and the FastPath.
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).
groups.google.com
groups.google.com
groups.google.com
DDP checksums
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
Importance of DDP checksums?
groups.google.com
papif checksum errors
groups.google.com
Last edited:
tashtari
PIC Whisperer
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.
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.
tashtari
PIC Whisperer
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.
tashtari
PIC Whisperer
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
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.RolandJuno
Active member
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.
tashtari
PIC Whisperer
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)
RolandJuno
Active member
There's a Python exception when I select the ImageWriter LocalTalk driver in the Chooser. Log attached.
RolandJuno
Active member
Same as before, the ImageWriter II on LocalTalk/TashTalk doesn't appear in the Chooser in Mini VMac LToUDP. Log attached.
RolandJuno
Active member
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.
