Cloning the AsantéTalk, or not

trag

Well-known member
I don't know if this is at all helpful, but here are some pics of the circuit board for the Asante Micro AsantePrint, which was the predecessor to the AsanteFast. I once asked Asante and they said the only real difference is that the Asantefast dispenses with some of the network statistics functions that the AsantePrint supported.

IMG_1745[1].JPG


IMG_1746[1].JPG



IMG_1747[1].JPG


IMG_1748[1].JPG



It looks like at its heart it has an 80C188 processor. To the left of that is DP83902 ethernet chip (?). Then some kind of custom Asante thing, AD20037, Orbit 6294A. Finally a Zilog Z8530. Oh, and the little chip center top is some kind of DRAM, 514256-45.


The back side has a voltage regulator, which I suspect is dead on this unit, which is why it's in a drawer in pieces, a 74LS240 buffer and an AT27C512 EEPROM.


Oh, almost missed them, also on the backside are a couple of DS75176B RS485/RS422 transceivers and a 93C86 serial EEPROM (MAC storage?)
 

Tashtari

PIC Whisperer
One Ethernet MAC responds to multiple AppleTalk node numbers (easy to do with AARP). Its no different then a computer's Ethernet adapter having multiple IPs on the same network (common with bridged VM configurations). The bridges only support 10 or so LocalTalk clients. Most of them have configuration programs that can set the zone (if the EtherTalk network has multiple) those LocalTalk devices appear on. On startup, the bridge itself has to send a ZIP GetNetInfo packet to get a network range and default zone along with a ZIP request to get additional zones if needed. No response to ZIP GNI puts the bridge into responding to all network numbers and the "*" zone. At that point, it can randomly assign one network number and a zone name to the LocalTalk clients. I think laqENQ and laqACK are relayed as AARP requests on the Ethernet side.
Interesting, I suppose I was thinking of a more complicated mapping logic, but perhaps it's not necessary.

I don't know if this is at all helpful, but here are some pics of the circuit board for the Asante Micro AsantePrint
Thanks for the pictures! I suppose I should clarify that by "cloning the AsantéTalk" I didn't mean making a direct clone of existing hardware on which to run existing software, but building an entirely new LocalTalk/EtherTalk bridge...

...Which might well be possible using the ENC28J60 and TashTalk and a PIC such as the PIC16F1825. Going to have to think about this. And possibly build it in Python first.
 

Tashtari

PIC Whisperer
How does this logic sound:

The bridge has a zone name and network number that can be manually configured. On startup it does a GNI to verify that they're valid if there's a router on the ET side of the network. If GNI response says they are, great. If the GNI response says the zone name is not valid, the bridge adopts the default zone name. If the GNI response says the network number is not valid, the bridge adopts the first network number in the range. If there is no GNI response, the bridge adopts "*" as its zone and the last known network number as its network number (or a random one in the startup range if there is no last known network number). We only do the GNI query on startup. The bridge does not care if a router appears after startup. In any case, having acquired a zone name, it starts listening on the corresponding multicast Ethernet address.

When AppleTalk or AARP frames are seen on the ET side of the network from the bridge's network number, their source node numbers are marked as in use on the ET side by the bridge (with a timeout of some kind), which then alerts TashTalk to respond to ENQs and RTSes on their behalf. Likewise, when frames are seen on the LT side of the network, their source node numbers are marked as in use on the LT side by the bridge (again, with a timeout). When AARP request or probe frames come in on the ET side for node numbers on the bridge's network number that the bridge has marked in use on the LT side, the bridge responds to them appropriately. By way of keeping the node table up to date, before timing out an entry, the bridge will send AARP probes (for nodes on the ET side) or ENQ frames (for nodes on the LT side) to prompt the node to respond and have its timeout reset.

When AppleTalk frames come in on the ET side for the bridge's network number, they are translated across to LT frames and sent on the LT side. When frames come in on the LT side for node addresses known to exist on the ET side (or broadcast frames), they are translated across to ET frames and sent on the ET side (frames for unknown addresses won't be known to TashTalk and won't get CTS frames, so they won't be relayed).
 

Tashtari

PIC Whisperer
I must be getting confused between those and RS232 - what is the difference?

128k/512k Serial PortsLater Mac Serial PortsPC Serial Ports
StandardRS-422RS-422RS-232
Signalling VoltageDifferentialDifferentialUnbalanced
Host ConnectorDE-9 FemaleminiDIN-8 FemaleDE-9 Male
Handshaking SignalsHSKi OnlyHSKi/HSKoDSR/DTR and RTS/CTS
+5V and +12V PowerYesNoNo
 

NJRoadfan

Well-known member
Here are some pointers based on the behavior of EtherTalk devices like Macs and routers:

Bridge Startup:
-Do an AARP request in the startup range.
-Broadcast a ZIP GNI packet with no zone name.
-If a GNI Reply shows up, do AARP request in new network range. Add Default Zone to table. Do a ZIP GetZones request to get the rest if needed.
-If no GNI Reply shows up, set network range to all networks. Assume you are in the * zone. See Inside AppleTalk page 4-8.

LocalTalk Client Address Selection:
-When a LocalTalk client comes online and sends a lapENQ, the bridge will rely that as an AARP probe to Ethernet.
-If the AARP Probe receives a reply (node in use), rely back to LocalTalk as a lapACK and repeat until no conflict. If no response, update the client table in the bridge.
-The bridge will handle routine AARP requests with replies. It should monitor traffic and time out/removes a client's node if packets aren't seen from a node after a certain period of time.
-If someone connects a LocalTalk client that was already powered on and has an assigned ID, you can likely force them to reacquire a new ID (and update your device table) by spamming it with lapACKs. Inside AppleTalk is vague on what to do with LLAP node conflicts.

LocalTalk Side Services:
-All RTMP packets must be short form DDP packets. Otherwise they likely can be relayed as-is from the EtherTalk network.
-The bridge likely has to support ZIP and only respond to ZIP requests with the configured zone name.
-Stick with long form DDP packets for everything including NBP, since even though there is no router, devices still need to know what network number the packets are destined for. I don't know how the LLAP header would address things though since they only have nodes. I would have to do a packet trace on a bridge. Maybe the bridge always sends "fake" RTMP data to force the clients to send traffic to the bridge node that is destined to other network numbers?
 

Mk.558

Well-known member
that's a nice table tashtari.

Why? because. If you want a Mini-DIN-8 to RS232 DE-9 adapter, there's not too many of them left, or you can wire up your own. Anything involving a serial terminal, serial console or anything like PPP works way better with RS232. RS232 to USB adapters are still around, will probably be around for awhile, and that is one way people can use their vintage equipment.

DB25 RS232 is a different story, but most stuff does fine with DE9.
 

Iesca

Well-known member
I just acquired an AsanteTalk (for much less than $100, thank goodness), and also have an iPrint LT. It will be interesting testing between the two. Should work more or less between a Plus and an iBook G4, right?
 

Tashtari

PIC Whisperer
The bridge is going to have to have its own node address, at least on the LT side, isn't it? Otherwise, where do LT nodes send packets bound for different network numbers (and where do such packets come from when inbound?) It sort of sounds like the concept of a "bridge" requires the bridge to look like a router to the LT side, with the stipulation that another router cannot be connected on the LT network.

Like, suppose there's no router on the ET network and the bridge chooses 65532 (0xFFFC) as the network number for the LT network. If there's a node 65532.1 on the ET side and it sends a packet bound for 65532.2, the bridge can relay that packet to the LT side with an LLAP header with destination = 2, source = 1. But what if there's a node 65533.1 on the ET side and it sends a packet bound for 65532.2? The LLAP header can't have source = 1, because that would imply the packet is coming from 65532.1, not 65533.1. Such a packet would have to be "routed" by the bridge as a long-form DDP packet with the LLAP source being the bridge (65532.254, say) and if 65532.1 would have to respond with a long-form DDP packet with the LLAP destination being the bridge, which would then relay it on the ET network.

That implies that the bridge would have to put out RTMP packets on the LT side advertising its presence and the network numbers it's able to route to. In the case above, that'd be 65280 (0xFF00) to 65531 and 65533 to 65534 (0xFFFE), since 65532 is implied to be directly connected. This all sounds like it'd have further implications. Like, what if there is a router on the ET side. Wouldn't the bridge have to keep track of what networks that router can get to so it can report this to the LT side? At that point, you're building a routing table and the project starts to get complicated...
 

NJRoadfan

Well-known member
When I have time, I'll pull out Apple's LocalTalk Bridge and do some packet sniffing on the LocalTalk side. Something that is real easy to do now as I can feed it to a TashTalk and just run a bunch of minivmac sessions over LToUDP.
 

NJRoadfan

Well-known member
OK, I've looked at what LocalTalk Bridge does...... its interesting.

On the LocalTalk side, the bridge (node 1) always broadcasts RTMP data, claiming to be network 65278, with next net being the bridge itself.
1720380955942.png
NBPLookUps is where things get fun. The bridge is rewriting the extended DDP headers. Here is a BroadCastRequest from LocalTalk
1720381164773.png
Nothing special in the reply, but the Ethernet side is network 1-1, so the bridge is mapping/rewriting headers for the fake network, so NBPReply from LocalTalk hosts show as being on Network 1. It looks like node numbers and 1:1 on the host Ethernet network, but I don't have a large multi-network range setup. It might do dynamic remapping for all I know. Everything on the LocalTalk side is in its happy world of network 65278 unaware that they are appearing on network 1 as nodes.
 

NJRoadfan

Well-known member
Looking further into LocalTalk Bridge, this looks like straight NAT for AppleTalk networks. I managed to get one of the LocalTalk clients to get a different node number from what it was appearing as on the Ethernet side. So the bridge is keeping track of nodes on both sides and remapping them if needed.

The whole thing is a hack. By sending that RTMP data with a "fake" local network number (which is randomly picked on boot), it forces any LocalTalk client that has a destination outside of that network to send its packets to the bridge. The bridge handles ZIP requests and relays NBP broadcasts to the Ethernet side.

Packets from the Ethertalk side to a LocalTalk client have the addresses rewritten in the extended DDP header. EX: A server sends out a NBPReply to 1.115, the bridge intercepts this and changes the destination to 65278.115 and transmits it over LocalTalk. Same happens on outgoing data to Ethernet. The "source" address is rewritten from the LocalTalk one to Ethertalk in the DDP headers. Basically EtherTalk clients have no idea they are talking to LocalTalk clients or that the "fake" network exists. The only exception is if there are services running on the bridge Mac. That has an address on the "fake" network so packets don't need to be re-written.

Router vs non-router operation is exactly the same. The difference is that ZIP GetMyZone requests on the LocalTalk side get a response with zero zone names if there is no router. LocalTalk Bridge uses whatever zone is set on the host Mac in the case of multi-zone networks.
 

Tashtari

PIC Whisperer
Very interesting! Thanks for digging into this. I might be able to do this on a PIC, though it seems only marginally less complicated than implementing a router, heh. I guess the principal data structure is simpler, at least, which helps when you've got a very small amount of memory to work with...
 

Tashtari

PIC Whisperer
I've been thinking about this project a lot over the past few days and I've come to the unfortunate conclusion that it doesn't make sense. The complexity of the task is such that it's too much for an 8-bit PIC, and if I move on up to a system like an ESP32, at that point, why not just implement a full-on router? The LT Bridge control panel seems halfway to implementing a router anyway, it doesn't seem like they saved much by just making it a bridge.

There's more I could do to work on and evangelize TashRouter and I should, I've sort of been neglecting it ever since jrouter and GlobalTalk became a thing.

I guess the question for the general audience isn't "why use a bridge, bridges are broken" so much as "why use a bridge when you could have a router". If the answer is "because bridges are plug and play", then the response needs to be to make routers plug and play, too.
 
Top