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.

TashTalk USB

Posted by: Bolacore on 2026-07-10 13:19:35 Anything interesting of note different between those two caps? I think I remember @NJRoadfan mentioning a few of the quirks of the IW II in that we should use DDP Long headers for NBP as otherwise it responds to all of them (or did I have that backwards?). I'm sure he would have a good idea based on the capture too.

Posted by: iigs123 on 2026-07-10 13:34:42 Here is a small capture of the LCII looking up Imagewriters. This is from a little rust program that I added that just opens tashtalk & capture, closing when you hit enter. Two extra bytes at the end when compared to nbd-lookup's packet. wireshark decodes exactly the same, and only shows the frame length being different. The two extra bytes are 91 5E.

Posted by: Bolacore on 2026-07-10 13:38:50 Interesting, nothing looks that different beyond it using NBP broadcast requests which we dont do yet. Any chance you could take a capture of the ones TailTalk makes for comparison? I assume that was the one that had the extra 0x91 0x5E right?

Posted by: iigs123 on 2026-07-10 13:42:11 Here is nbp-lookup's capture for entity =:ImageWriter@*

Posted by: Bolacore on 2026-07-10 13:48:56 ahh yeah that seems like just the CRC then - I think this is likely us not using the broadcast request option. Out of curiosity if you have just these two in the network (So your modern machine direct to the ImageWriter) does it see it then? In the LC case I dont see any responses back either - was the IW on at the time?

Posted by: iigs123 on 2026-07-10 13:57:22 in the LC_IWII capture I did have the printer and LC II on, and the ImageWriter showed up in chooser. I didn't notice the lack of responses. Interesting - but they must have been on the wire for them to show up in the chooser. I do sometimes see Localtalk framing error/aborted warnings. Perhaps the response was dropped or ignored on the tailtalk side.

Posted by: Bolacore on 2026-07-10 14:08:49 Oh that would be kinda interesting - do you consistently see that framing / aborted warning after every tailtalk generated (Or even the LC II one when the IW would respond) NBP lookup?

Posted by: iigs123 on 2026-07-10 14:36:14 If you are interested, I was able to capture the NBP reply from the LC II. Attached.

Posted by: Bolacore on 2026-07-10 14:46:56 Thanks! Any chance you could try Tashtari's capture tool? Just to rule out anything funny TailTalk might be doing: https://github.com/lampmerchant/tashtalk/blob/main/tashtalkcap/tashtalkcap.py. Curious if that can see the ImageWriter response or not.

Posted by: iigs123 on 2026-07-10 15:05:12 Looks like tashtalkcap doesn't see the imagewriter either. I did a couple of captures, plenty of frames and 0 errors.

Posted by: Bolacore on 2026-07-10 20:21:07 Huh that's bizarre. If it doesn't work even with Tashtari's tool then it probably isn't our software at fault, but I cant see a reason why it wouldn't pick up the packets. Any chance you could test a direct connection as one last thing? _just in case_ it's something with the other topology. And in another note too I have printer emulation going and tested printing from my PowerBook on Mac OS 9 to a modern HP printer using the LaserWriter driver Still need to test it with the older systems of course and find the quirks NJRoadfan mentioned, but it feels pretty neat being able to direct print over LocalTalk to the modern world 🙂 It exposes the usual IPP attributes too, so tray selection, quality mode and all that works.

Posted by: NJRoadfan on 2026-07-10 20:25:52 The usenet posts documenting the NBP bugs in the ImageWriter are pretty confusing and unclear. That and a rant is interwoven about how the Webster Multigate is "well layered" and that any fix for the ImageWriter card will break it. AppleTalk ImageWriter problems groups.google.com Whatever, the card is a buggy mess. The issue seems to be that some routers send out NBP Lookups using DDP short packets. When this happens, the ImageWriter card sends the NBP replies to the packet sender (the ROUTER, which is VERY WRONG), instead of the client who sent out the original NBP Request. The fix is to have the router always use DDP long headers on NBP Lookups which have the client's source address in the packet header. See: https://groups.google.com/g/comp.protocols.appletalk/c/2so0gBHgv6g/m/PhT_40v2OnMJ Basically, Apple might have taken a shortcut in designing the card's firmware and assumed DDP short NBP Lookups only appeared on routerless networks. On those networks, the source of the request is always the actual client, not a router relaying the request. Note, unlike RTMP broadcasts, there is ZERO need to send NBP lookups with DDP short headers on LocalTalk. This applies even if its from a machine on the same network segment. For additional fun, the ImageWriter card generates invalid DDP checksums. Thankfully Apple never enabled checksum verification on Macs out of the box, otherwise they would drop every single packet this thing generates. Its odd that it even generates checksums because Apple's own products usually leave the field unused.

Posted by: NJRoadfan on 2026-07-10 20:40:50 @iigs123 Your packet dump needs some context. The LCII's response has a network number which indicates a router is present on LocalTalk. If so, the NBP lookups with a network of "zero" (which are likely from TailTalk) are wrong. If a router is detected on the network, TailTalk needs to send a NBP Broadcast request to the router's address. The router then handles the NBP Lookup or forwarding on any network segments. See page 7-10 and 7-11 of "Inside AppleTalk"

Posted by: Bolacore on 2026-07-10 20:43:08 Yeah we are for sure wrong there (been on my list for a while now), but, what's odd is that TashTalk should still see the packets coming back from the ImageWriter when it was just a passive listener for the LC II < - > ImageWriter NBP queries. It is very odd that we can see the NBP Lookups but not the responses.

Posted by: NJRoadfan on 2026-07-10 20:49:30 Its likely the printer simply isn't responding to the incorrect NBP lookup packets. Once it gleans network information from a RTMP broadcast, the printer might ignore packets with network zero in the request.

Posted by: Bolacore on 2026-07-10 20:51:20 Sorry this was not TailTalk but rather the LC II querying the ImageWriter - TashTalk is purely a passive listener in this case. The ImageWriter _does_ respond as @iigs123 sees the device show up in Chooser. Thats what is throwing me.

Posted by: NJRoadfan on 2026-07-10 21:08:25 Something else on the network is generating NBP Lookups with a network of zero in the tuples. See packet #2 in tailtalk_capture_nbp-lookup and packet #2 in tailtalk_capture_LCII_reply.

Posted by: Bolacore on 2026-07-10 21:16:15 There were a few posted - that was the one TailTalk was looking up the LCII I believe. The one I was looking at was tailtalk_capture_LC_IWII.pcap:

Posted by: NJRoadfan on 2026-07-10 21:40:15 Notice that the packet in your screenshot is a NBP Broadcast directed to a router (at least the LC thinks it should be one) at node 129, not a NBP Lookup to the broadcast address. In this case, the router at node 129 should be re-transmitting those packets at NBP Lookups to the broadcast address. Without knowing @iigs123 's network configuration, its hard to know what is going on here. Plus there are multiple problems. This example appears to be a non-responsive router. while the issue in the other two packet captures with TailTalk is that it isn't handling being on a routed network correctly, which causes problems with NBP lookups. On non-extended networks, TailTalk needs to listen to RTMP broadcast traffic to glean the network number and node number of the router, then issue a ZIP query to the router to get the zone name. On extended networks, TailTalk needs to broadcast a ZipGetNetInfo request, get the correct network range, node number of the router, and default zone, issue a new AARP Probe inside that network range, followed by a ZIP query to the router to retrieve the rest of the zone list.

Posted by: iigs123 on 2026-07-11 05:06:40 My network media is phone net: ImageWriter -> LC II -> Tashtalk (with terminators on the ends) I sometimes bridge to ethernet/wifi when I'm transferring from netatalk on a pi: ImageWriter -> LC II -> Tashtalk -> Ethermac iPrint I'll redo the captures soon to ensure I didn't have the iprint plugged in. This is all on windows 11. TailTalk over ethernet/iPrint can see the ImageWriter, and a version of pap-print I made for text only seems to make some connection to the IW but is failing. The ImageWriter eventually resets and does a form feed which scared me the first time it happened!

< 9 >