Cloning the AsantéTalk, or not

[Tashtari]

In writing TashRouter, I denigrated AsantéTalk and LocalTalk/EtherTalk bridges in general as being hackish solutions replete with protocol violations... which they are, but they remain popular and regularly fetch $100+ on ebay. I'm realizing that's at least partially because they're pretty much plug-and-play, and that makes me wonder, is it worthwhile trying to make a clone? I don't think I can fit a full router in an 8-bit PIC, but a bridge might be possible using TashTalk and the ENC28J60...

In an ideal world, everyone would eschew LT/ET bridges entirely in favor of proper routers and I'm debating whether my efforts would be better spent on trying to make TashRouter more accessible - I just don't know whether it's possible to make it as plug-and-play as a bridge. Any way you slice it, it pretty much ends up needing a whole Linux system, and that means there's configuration and software updates to think of...

Anyway, just thought I'd start a conversation on the subject. What do folks think?

 

[Mk.558]

I'd much prefer the Farallon iPrint LT bridge instead. Never had a single issue with it, and it has a PhoneNET jack which means it can be used for multiple machines.

If we had a bridge for Ethernet to LocalTalk, then there's no reason to not have PhoneNET unless we were overclocking the serial port. Still think that's the way forward. Seeing a IIfx crank out just over 100KiB/sec over the serial port is surreal.

One option is to clone a DaynaTalk or Flashbox. Never heard of anybody owning one, never seen one. A November 1989 issue of BYTE talks about those (titled LAN Aid: Mac Booster Modules). Each had their plusses and minuses, some of which I think we could fix with what we know today.

 

[Tashtari]

I'd much prefer the Farallon iPrint LT bridge instead.

Well, whichever bridge it is, it's still a bridge, and that comes with the same set of caveats (mainly, won't play nice with an actual AppleTalk router).

overclocking the serial port

I'm still interested in making a TashTalk that provides its own clock to the serial port if anyone's interested in writing me a driver that makes this possible... but that's a different question than the one I'm posing in this thread. =)

 

[cheesestraws]

. I'm realizing that's at least partially because they're pretty much plug-and-play

Yup. The end user experience is the key in all this stuff. That's why I put as much time as I did into the concrete user experience for AirTalk, for example.

I just don't know whether it's possible to make it as plug-and-play as a bridge

I believe it is; I've got some sketches. It mostly boils down to sane defaults and autoconfiguration - and limiting the amount of ways for the user to shoot themselves in the foot.

Any way you slice it, it pretty much ends up needing a whole Linux system, and that means there's configuration and software updates to think of...

It does not require a whole Linux system to run a router; many routers do not. You seem to have a very bimodal view of computing hardware, where there's basically 8-pin PICs on one end and full general purpose Linux boxes on the other, and nothing in the middle. Whereas really this problem is the absolute epitome of an 'in the middle' problem: you need something like, again, AirTalk's hardware, or perhaps a 2040; a rather larger microcontroller with a certain amount more RAM, but not a general purpose OS.

(In fact, I'd argue that the trend to move network equipment in general to using general-purpose OSes has resulted in a quality decrease overall; more to go wrong, &c.)

 

[Tashtari]

It does not require a whole Linux system to run a router; many routers do not.

Sure, I just mean to run TashRouter, specifically. I'm not super interested in writing a whole new router, that's why this thread is about the question of whether to work on evangelizing/adapting TashRouter or whether to write a bridge.

You seem to have a very bimodal view of computing hardware, where there's basically 8-pin PICs on one end and full general purpose Linux boxes on the other, and nothing in the middle.

I know that others exist, it's just that those are the two areas of computing hardware that interest me. I'd fully support someone writing a router targeting an in-the-middle embedded system (and perhaps using TashRouter as a guide), but I have no interest in doing such a thing myself.

 

[robin-fo]

You could try porting the TashRouter to MicroPython..

 

[robin-fo]

a router targeting an in-the-middle embedded system

I‘ve still got my „EmbeddedTalk“ router in the works which appears to run nicely on an STM32, but I won‘t release it until everything is tidied up.

 

[NJRoadfan]

Apple did write a "spec" bridge in the form of the LocalTalk Bridge control panel. It worked well whenever I've used it. The other bridge that I've gotten a ton of use from is the LLAP to ELAP bridge built into GSport/GSplus. All these bridges do is handle AARP on the Ethertalk side and straight packet translation. The other "big" thing they keep track of is how many LocalTalk clients are connected and what their addresses are. Nodes appear on the same network as the Ethertalk host machine and look like just another Ethertalk node.

As for the Asantétalk, part of the problem with it stems from how it auto detects the Ethertalk phase in use and how it enumerates LocalTalk clients. The firmware seems very brittle, but I have yet to examine one to know how it works inside. The issues with netatalk should be fixed though as the RTMP broadcast bug has been finally fixed.

I should mention @shirsch's 3D printed RPi "router" using the TashTalk. Nice compact hardware solution. Also, a STM32 is likely still WAY more powerful then what the routers of the past used. Both the FastPath and Gatorbox ran 8-10Mhz 68k CPUs with 512k of RAM tops and handled MacIP, IPTalk, and LLAP to ELAP routing without much problem.

Also, I have updated A2SERVER to include a daemonized TashRouter and setup a TashTalk if a user has one. Makes setup a breeze, even for my own testing.

 

[Tashtari]

It's been a while since I immersed myself in TashRouter or AppleTalk networking and I've forgotten some things, but I had the perception that bridges were inherently incompatible with routers... and now I can't remember why (or if) that is true. Stupid brain. Does anyone remember/know?

 

[LaPorta]

The iPrint works beautifully hooked to my Asante router, which itself is just a bridge to my AirPort which does the IP assignments. You literally just plug it in and information is passed. I use it currently to allow printing to my AppleTalk ImageWriter II from my Ethernet connected classics Macs.

 

[LaPorta]

When you say “ In an ideal world, everyone would eschew LT/ET bridges entirely in favor of proper routers”, then how exactly would you go about it? How else would you adapt mini-DIN or PhoneNet to Ethernet?

 

[Tashtari]

How else would you adapt mini-DIN or PhoneNet to Ethernet?

By using a router that has a LocalTalk port. TashRouter supports this with TashTalk (and LToUDP), and the Shivas and GatorBoxes have LocalTalk ports as well.

 

[LaPorta]

By using a router that has a LocalTalk port. TashRouter supports this with TashTalk (and LToUDP), and the Shivas and GatorBoxes have LocalTalk ports as well.

I suppose my next question is…

Why do that when something half-a**ed seems to work fine…and presumably without any configuration?

 

[Tashtari]

Why do that when something half-a**ed seems to work fine…and presumably without any configuration?

Well, that's what I'm asking myself, too.

 

[LaPorta]

Well that’s my only two cents. My final thought is that you already make so many good things as it is, I’m sure if you decide to clone one of these that it will work out well!

 

[Tashtari]

Well that’s my only two cents. My final thought is that you already make so many good things as it is, I’m sure if you decide to clone one of these that it will work out well!

Thanks. =) It's a legitimate question that should be asked, though, why use the complicated solution when a simpler one works just as well. Routers give you zones, which are useful in organizing big internets, I know that much, but I doubt even the most dedicated enthusiasts on this forum are running networks of vintage Macs so big that they really need zones...

 

[NJRoadfan]

The primary limitation is that you can't run an AppleTalk seed router on the LocalTalk segment being bridged. That is, don't hook up say a GatorBox or FastPath to an Asantétalk or iPrint LT. Not that anyone would ever do this, but stuff will break.... fast.

 

[Tashtari]

The primary limitation is that you can't run an AppleTalk seed router on the LocalTalk segment being bridged.

That doesn't seem like much of a disadvantage.

I'm having trouble visualizing how the bridge should resolve the difference between the nonextended (LocalTalk) and extended (EtherTalk) networks it sits between. Unlike a router, the bridge doesn't represent itself as a single node with addresses on both networks, it represents itself on one network as all the nodes on the other network and vice-versa. I guess that means the bridge must keep a mapping such that every node on the extended side is represented by a node on the nonextended side (hopefully there aren't more than 254). That takes care of the ET-to-LT direction, but what about the LT-to-ET direction? The nodes that live on the LT network need to be represented by a full network-and-node address on the ET side, and the bridge will have to acquire it for them - simple enough if the bridge uses the startup network range, but what about ET networks with a router, where every node is expected to have a network number in a given range? I guess the bridge initially assumes that each of the nodes on the LT network is represented by a network-and-node address randomly chosen in the startup range, but then reassigns them all when a router announces its presence with an RTMP broadcast. And the bridge would have to intercept NBP replies, too, so as to be able to change the addresses within according to its mapping. I guess there's no reason a bridge couldn't do all this, but it seems convoluted...

 

[NJRoadfan]

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.

Take a look at GSport's bridge source for how the packet translation and AARP handling is done: https://github.com/david-schmidt/gsport/tree/master/src/atbridge

Granted its only for one LocalTalk client, but it isn't hard to expand it to more. A good person to ask these questions to is the bridge's author, Peter Neubauer: https://bluerwhite.org/2013/08/talkin-about-localtalk/

 

[Mk.558]

Following that link...

http://bluerwhite.org/wp-content/uploads/2013/08/Talkin%E2%80%99-about-LocalTalk.pdf

Is there more presentation text to that? Seems like it's just the PowerPoint stuff.

It'd be a difficult project, but another thing I've advocated for is a so-called Universal Serial Adapter. It has RJ45 Ethernet input, RJ14 PhoneNET input, RS232 DE-9 input, ... don't think you'd need a Mini-DIN-8 jack but why not. Output is PhoneNET, DE-9 RS422 for 128/512K and Mini-DIN-8 directly to a machine.

You can thus use one box, which has of course blinkenlights for diagnostics, that uses a hardware switch to toggle between RS232 input -> RS422; switch to Ethernet and it can bridge TCP traffic, AFP traffic and overclock the serial port if you are not using PhoneNET. Of course RS232 could only go to the RS422 interfaces, and such a box could basically handle any input we normally use except WiFi (i'd prefer not to have that, tends to complicate things too much versus a dedicated WiFi->Ethernet device).