09:00:07:FF:FF:FF is the default broadcast address for EtherTalk Phase 2 and it could change depending on zone. Only Phase 1 used FF:FF:FF:FF:FF:FF. Network "0" should only appear on broadcast packets (ie: 0.255), otherwise its not valid. The ImageWriter LocalTalk card has a few NBP bugs too, which makes things fun.
TashTalk USB
- Thread starter Bolacore
- Start date
I put together a little PR that should fix the broadcast MACs. I admittedly mostly use Phase 1 so had not noticed things did not work with Phase 2. If you have time to check it out of course before I merge: https://github.com/FeralFirmware/TailTalk/pull/18
I'm kinda curious though why you had to use a network of 0 with the NBP lookup on EtherTalk - maybe @NJRoadfan knows? I would have thought that a network number not matching your own would mean the client would respond back to the wrong address (i.e 0.$SOCK instead of $NET.$SOCK that the client auto assigned), or does Netatalk/normal clients just ignore the net num for responses?
I'm kinda curious though why you had to use a network of 0 with the NBP lookup on EtherTalk - maybe @NJRoadfan knows? I would have thought that a network number not matching your own would mean the client would respond back to the wrong address (i.e 0.$SOCK instead of $NET.$SOCK that the client auto assigned), or does Netatalk/normal clients just ignore the net num for responses?
From Inside AppleTalk:
Node ID $FF indicates a broadcast to all nodes with a network number equal to that indicated by the specified network number. As long as this network number is nonzero, the packet is refered to as a network-specific broadcast. Although it will be received by all AppleTalk nodes on the data link, it should only be accepted by those with the indicated network number.
If the network number is zero, node ID $FF indicates either a network-wide or zone-specific broadcast. A network-wide broadcast is sent to all AppleTalk nodes on the data link and should be accepted by all those nodes. A zone-specific broadcast is sent to a particular zone multicast address. DDP should always accept such a packet, however higher level protocols like NBP and ZIP will discard the packet if it is not intended for the node’s zone (see Chapter 8, “Zone Information Protocol,” for details of zone multicast addressing).
Node ID 0 indicates any router on the network specified by the network number part of the node address. Packets addressed to node ID 0 are routed through the internet until they reach the first router directly connected to a network whose range includes the indicated network number. The packet is then delivered to that router. This facility is used by NBP.
Node ID $FE is reserved on EtherTalk and TokenTalk networks and should not be used as a node ID. This address is a valid node ID on LocalTalk networks
Node ID $FF indicates a broadcast to all nodes with a network number equal to that indicated by the specified network number. As long as this network number is nonzero, the packet is refered to as a network-specific broadcast. Although it will be received by all AppleTalk nodes on the data link, it should only be accepted by those with the indicated network number.
If the network number is zero, node ID $FF indicates either a network-wide or zone-specific broadcast. A network-wide broadcast is sent to all AppleTalk nodes on the data link and should be accepted by all those nodes. A zone-specific broadcast is sent to a particular zone multicast address. DDP should always accept such a packet, however higher level protocols like NBP and ZIP will discard the packet if it is not intended for the node’s zone (see Chapter 8, “Zone Information Protocol,” for details of zone multicast addressing).
Node ID 0 indicates any router on the network specified by the network number part of the node address. Packets addressed to node ID 0 are routed through the internet until they reach the first router directly connected to a network whose range includes the indicated network number. The packet is then delivered to that router. This facility is used by NBP.
Node ID $FE is reserved on EtherTalk and TokenTalk networks and should not be used as a node ID. This address is a valid node ID on LocalTalk networks
Last edited:
@iigs123 PR updated to match the above and seems to work OK in my first tests - NBP now defaults to 0.255 for sending requests regardless of if it is EtherTalk or LocalTalk (and if both are enabled it will query both). Will hold off on merging of course til you confirm an improvement.
@slomacuser I have merged in https://github.com/FeralFirmware/TailTalk/pull/19 which should have Sierra compatible image on the next release.
@slomacuser I have merged in https://github.com/FeralFirmware/TailTalk/pull/19 which should have Sierra compatible image on the next release.
thanks, waiting for release.@slomacuser that is what I get for only checking "vtool" on the binary and not checking the Info.plist 
If you override it in the App file it will work. I am pushing a fix here in a moment and will release 0.5.1 to make it official. Sorry about that!
If you override it in the App file it will work. I am pushing a fix here in a moment and will release 0.5.1 to make it official. Sorry about that!Just to make sure I understand it - the TailTalk side is on the LocalTalk side via an TashTalk USB right? Or is this with us as an EtherTalk node?
Any chance you could record a capture on the TailTalk side and send it to me or post it here? I don’t have an iPrint to test with unfortunately but I wonder if I can replicate it with my AsanteTalk. Is your iPrint setup running in Phase 2 mode?
Any chance you could record a capture on the TailTalk side and send it to me or post it here? I don’t have an iPrint to test with unfortunately but I wonder if I can replicate it with my AsanteTalk. Is your iPrint setup running in Phase 2 mode?
Clients on the iPrint should be sending NBP Broadcast Request directly to the router on the network. NBP Lookups should only be coming from a router. Does the iPrint support networks with zones (and thus routers)? It goes without saying that you need to turn the iPrint on after you turn on TailTalk or whatever router is controlling that Ethernet segment so it knows that its on a routed network.
As an aside: Bridges like the iPrint and the evil AsantéTalk usually use network address translation. They spoof the clients into thinking they are on a routed network by sending out RTMP packets with an internal non-routed network number. Traffic not matching the internal network number of the LocalTalk segment is directed to the bridge's address and packets have 1:1 mapped NAT applied to them. This is what I observed with Apple's LocalTalk Bridge, but I don't think the hardware devices are much different.
As an aside: Bridges like the iPrint and the evil AsantéTalk usually use network address translation. They spoof the clients into thinking they are on a routed network by sending out RTMP packets with an internal non-routed network number. Traffic not matching the internal network number of the LocalTalk segment is directed to the bridge's address and packets have 1:1 mapped NAT applied to them. This is what I observed with Apple's LocalTalk Bridge, but I don't think the hardware devices are much different.
It’s been a while since I’ve tried but I know that TailTalk with AsanteTalk in Phase 1 mode could discover my LocalTalk LaserWriter just fine from the EtherTalk side. TailTalk does not do any routing or even know what a zone is beyond “this client is on EtherTalk or LocalTalk at address X”, so it very well could be missing something important.
I’ve kinda taken the position that zones and routing is just beyond what I want the project to do, and if you need it then Netatalk is the right project instead because it actually does all of this.
I’ve kinda taken the position that zones and routing is just beyond what I want the project to do, and if you need it then Netatalk is the right project instead because it actually does all of this.
The heavy lifting of LocalTalk-to-Ethertalk Phase 1 or 2 would be handled by the bridge device, not TailTalk.
For Phase 2 operation, if there is no router found on the network after issuing a ZIPGetNetInfo request, TailTalk should grab a random address via AARP from the startup range (65280 to 65534) and consider packets from all network numbers valid. The AsantéTalk should too, but it has that weird, evil Phase 1/2 autodetect stuff that doesn't always work.
That being said, if there is a router on the Ethernet network putting out RTMP packets, TailTalk needs to parse the ZIPGetNetInfo response and determine the valid network range and available zones, along with issuing another AARP request to fetch an address on the proper network. Once configured, only packets from the configured network range are considered valid.
For Phase 2 operation, if there is no router found on the network after issuing a ZIPGetNetInfo request, TailTalk should grab a random address via AARP from the startup range (65280 to 65534) and consider packets from all network numbers valid. The AsantéTalk should too, but it has that weird, evil Phase 1/2 autodetect stuff that doesn't always work.
That being said, if there is a router on the Ethernet network putting out RTMP packets, TailTalk needs to parse the ZIPGetNetInfo response and determine the valid network range and available zones, along with issuing another AARP request to fetch an address on the proper network. Once configured, only packets from the configured network range are considered valid.
The iPrint device is pretty straightforward and has no configuration. Basically plug in a phonenet cable and ethernet and go. I use it to bridge various Macs and a IIgs to netatalk, even hopping over wifi. since the pi that runs netatalk is only on wifi right now.
The TailTalk is connected to a phonenet box, which is connected via phone cable to a Powerbook G3, ImageWriter II and the iPrint box.
TailTalk can see the G3 only, but nothing else. I'll try to connect tailtalk directly to the IW at some point but when I tried this before it wasn't seen.
i'll look at capturing via pcap.
The TailTalk is connected to a phonenet box, which is connected via phone cable to a Powerbook G3, ImageWriter II and the iPrint box.
TailTalk can see the G3 only, but nothing else. I'll try to connect tailtalk directly to the IW at some point but when I tried this before it wasn't seen.
i'll look at capturing via pcap.
Yeah I’m missing just about all of that - I envisioned it very much as an ad-hoc only client running without routers so expressly skipped all of it. The primary use case was just modern computer hooked directly to old Mac computer with a LocalTalk or Ethernet cable and no router involved.
Outside of that I figured it was time to break out Netatalk because it is built for this kind of use case instead. But maybe I can rethink this, as it doesn’t sound like a heap of work either although it does raise the scope more. I’ll have a think about this tonight. Thanks as always NJRoadfan - I owe you more than a few beers worth of dollarydoos as thanks.
Outside of that I figured it was time to break out Netatalk because it is built for this kind of use case instead. But maybe I can rethink this, as it doesn’t sound like a heap of work either although it does raise the scope more. I’ll have a think about this tonight. Thanks as always NJRoadfan - I owe you more than a few beers worth of dollarydoos as thanks.
