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.
-
Hello Guest! We're hosting a challenge to welcome vintage Intel macs to the MLA during the month of July! See this thread for more information. -
We've made some quality of life improvements to the Trading Post. More info here.
TashTalk USB
- Thread starter Bolacore
- Start date
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.
wireshark decodes exactly the same, and only shows the frame length being different. The two extra bytes are 91 5E.
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?
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.
I do sometimes see Localtalk framing error/aborted warnings. Perhaps the response was dropped or ignored on the tailtalk side.
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.
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.
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.
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.
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.
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.
@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"
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.
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.
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.
