TashTalk USB

Since its now available, the Phase 2 Addendum is a good document to review: https://bitsavers.org/pdf/apple/com...se_2_Protocol_Specification_Addendum_1989.pdf

Inside AppleTalk covers this, but not all together in one place.

@iigs123, does the ImageWriter appear to other Localtalk clients when the iPrint is turned off? LocalTalk has no concept of networks over the line and devices like the ImageWriter generally use non-extended DDP packets if no router is present. If I recall, one of the NBP related bugs involved the card not filling out the extended DDP header response correctly, although this shouldn't be a problem on a non-routed network.

The other bug is that it basically puts trash data in the DDP checksum field, so if TailTalk is verifying DDP checksums, it could be dropping the packets. Note that by default, Apple's network stacks on Macs do not verify DDP checksums.
 
I dont believe we care at all about DDP checksums - I found most devices seem to just set it to zero so I've never bothered to check them. Wouldn't I need to use NBP broadcast requests though for it to work for LocalTalk to EtherTalk? TailTalk only does NBP Lookups today as it doesn't know anything about routers so I guess the iPrint wont forward it on if I understood your previous post correctly.

Thanks so much for the addendum too, will enjoy reading through that tonight.
 
On a single network (no router), the client should broadcast a NBPLookup packet to the network. On networks with a router, the client sends a NBPBroadcastRequest packet directly to the router, which will in turn broadcast the NBPLookup to all its ports or forward it to other routers.
 
Since its now available, the Phase 2 Addendum is a good document to review: https://bitsavers.org/pdf/apple/com...se_2_Protocol_Specification_Addendum_1989.pdf

Inside AppleTalk covers this, but not all together in one place.

@iigs123, does the ImageWriter appear to other Localtalk clients when the iPrint is turned off? LocalTalk has no concept of networks over the line and devices like the ImageWriter generally use non-extended DDP packets if no router is present. If I recall, one of the NBP related bugs involved the card not filling out the extended DDP header response correctly, although this shouldn't be a problem on a non-routed network.

The other bug is that it basically puts trash data in the DDP checksum field, so if TailTalk is verifying DDP checksums, it could be dropping the packets. Note that by default, Apple's network stacks on Macs do not verify DDP checksums.

The Imagewriter works just fine direct to the G3 with the iPrint off.
 
I pulled out my LCII and installed AppleTalk Peek on it. Is there a better program to capture the localtalk packets? I setup a localtalk only network between the ImageWriter, LCII and G3. I captured the NBP packets by using the chooser to browse for file servers & imagewriters, and captured this:

Code:
[B ] S: 244 D: 255 T: 15622      dT: 807        (0016)  L: 29
     FF F4 01 00 1A 02 FD 02 21 03 00 00 F4 FD 00 01       ........!.......
     3D 09 41 46 50 53 65 72 76 65 72 01 2A                =.AFPServer.*

[B ] S: 244 D: 255 T: 16146      dT: 524        (0017)  L: 31
     FF F4 01 00 1C 02 FD 02 21 04 00 00 F4 FD 00 01       ........!.......
     3D 0B 49 6D 61 67 65 57 72 69 74 65 72 01 2A          =.ImageWriter.*


the IW responded:
Code:
[  ] S: 155 D: 244 T: 16151      dT: 5          (0018)  L: 41
     F4 9B 01 00 26 FD 02 02 31 04 00 00 9B 8A 01 0B       ....&...1.......
     49 6D 61 67 65 57 72 69 74 65 72 0B 49 6D 61 67       ImageWriter.Imag
     65 57 72 69 74 65 72 01 2A                            eWriter.*


I separately captured the tailtalk running nbp-lookup:

Code:
[B ] S: 59  D: 255 T: 14806      dT: 14806      (0001)  L: 21
     FF 3B 01 00 12 02 02 02 21 01 00 00 3B 02 00 01       .;......!...;...
     3D 01 3D 01 2A                                        =.=.*
 
The TailTalk GUI has a pcap option that should dump everything to a Wireshark compatible format if that’s easier? It’s right at the bottom of the window and has a little checkbox
 
The TailTalk GUI has a pcap option that should dump everything to a Wireshark compatible format if that’s easier? It’s right at the bottom of the window and has a little checkbox

I was going to run another test by capturing from tailtalk - i added capture to the nbp-lookup - but I wanted to observe and capture what the 'real' devices were doing, too.
 
Ohhh right of course sorry - it’s possible to make the TashTalk device be in essentially promiscuous mode by getting it to pick up all node traffic but I don’t think I have that exposed. Probably time for me to make one honestly.
 
So I managed to get NBP from LocalTalk (via TashTalk USB + TailTalk's nbp-lookup tool) to be able to discover a TailTalk AFP server running on EtherTalk bridge via my AsanteTalk and vice versa based on the advice from NJRoadfan above. I admittedly am not at all confident in the code as the AsanteTalk seems to be.. quirky to say the least.

@NJRoadfan if you dont mind a few more Amateur Hour AppleTalk questions - would you know if the AsanteTalk ever responds to ZIP GetNetInfo or RTMP Requests on EtherTalk (or LocalTalk)? I am not seeing it acknowledge either of them and instead just see it spit out RTMP info once every 10 seconds to 0.255 on both the LocalTalk and EtherTalk sides. If I watch for that and stick it in to the routing table and direct NBP broadcast requests to it, all seems to work well, but I am not sure I like the "wait and see if a packet comes in" style for discovering it. I am not sure if I am missing something important or if this device is just utterly bizarre.
 
ZipGetNetInfo is never used on LocalTalk, its a Phase 2 thing. I don't have an AsanteTalk, but I know real routers (FastPath, Netatalk's atalkd) have to respond to them on Ethernet. Its the only way to get the default zone on a Phase 2 network. The "wait for RTMP packet" method is how most LocalTalk devices work based on observation.

See Inside AppleTalk page 5-17 "Node on Non Extended Networks". I don't recall a Mac ever using the RTMP request packet (that would require some work on a programmer's part!), they just passively listen via the RTMP stub.
 
Last edited:
I tried your zip-support branch to see if my iPrint adapter would show any results, and it does not. I think the iPrint device is a pretty dumb router really intended for a basic network to bridge an old printer to ethernet. The fact that it also bridges AFP might have been "unsupported." I haven't gotten further on my comparison of the "real" NBP lookups and the tailtalk NBP lookups yet either.
 
Back
Top