What should a hobbyist-focussed AppleTalk router do?

[cheesestraws]

As a companion / follow-on piece to AirTalk, I've been considering trying to build a new AppleTalk router (either just software or a software/hardware combination) aimed at hobbyists. I'm starting this thread to try to get some opinions and/or interest going around what, in broad terms, this should look like. I'm especially shamelessly pinging @NJRoadfan, @slipperygrey and @mactjaap for opinions as people I know have delved into Dark AppleTalk Magic recently, but please everyone else jump in too.

Let's start with "why not use netatalk's routing?" as a starting point. I think this will give us a good set of starting points, because netatalk is good software but aimed at a very different use case from the home user/hobbyist situation.

• Netatalk is really for managing networks with large numbers of computers in complicated topologies. This can be fun to fiddle with, but for people who just want to be able to string computers together, it's a serious detriment. The proposed system should be designed to be easy to use with 20 computers, not 200.
  
  
• Netatalk heavily relies on the underlying AppleTalk support in the kernel and specifically will only try to talk AppleTalk on things that the underlying OS thinks are network links. Again, this makes a lot of sense in the context it was designed for, but means that to add support for things like TashTalk would either require kernel-level driver writing, prosthetic bridging to Ethernet, or refactoring of netatalk. The proposed system should be designed to maintain a distinction between an AppleTalk "port" and a layer 2 network interface.
  
  
• Netatalk has lots of complicated options. The bridges and routers that made most inroads into the end-user space had very few verging on none. They just plugged LocalTalk into Ethernet. Apple Internet Router sits rather in the middle: it provides quite a few features, but not a huge amount of detail on those features. Personally I find this just as frustrating, because you can break something and it won't tell you exactly why. The proposed system should have extremely simple configuration based on sane defaults, but should allow people to see what's gone wrong in detail if something does.
  
  
• Netatalk modifies its own configuration based on soft-seeding and AppleTalk hints. The proposed system should always be reset to a known state by a power cycle even if this slightly slows down startup.

This all sounds more like a low-end bridge. So, why not just use one of those?

• They're not very available. The proposed system should... um.... exist?
  
  
• They tend to have a very simplistic view of the structure of the network. Nowadays, people like using netatalk for file sharing (which can sometimes result in network complications). I want this also to work with AirTalk, so that's a three-lobed network, not a two-way conversion, and I think it'd be useful for it to do be able to play nicely with things like long-distance AppleTalk over the internet or ARA (as I know we have members playing with that). So the proposed system must tolerate and play nicely with network complexity without enforcing it.
  
  
• Some of them do hair-raising things to support Phase I EtherTalk. The proposed system should only speak protocols anyone cares about: does anyone use Phase I EtherTalk?

So, taken as a starting point, we seem to be converging on something that has the kind of plug and play experience as the AsantéTalk or the Farallon iPrint boxes but which does proper AppleTalk routing—a luxury we can now afford because of faster CPU speeds.

What do people think?

 

[olePigeon]

Seems like a great idea. If you plan on doing an all-in-one solution on something like a Raspberry Pi or whatever, I think a good starting point as a project box would be any old Netgear 8-port hub/switch/router. I don't think Netgear has change the physical case for their networking stuff for over 35 years, so someone could just go to Goodwill or computer recycler and pick up a Netgear for $5, and it really doesn't matter what the heck type of Netgear product it is. The cheaper the better.

 

[NJRoadfan]

Pretty much nothing uses Ethertalk Phase 1. Apple quickly phased it out and added Phase 2 support to everything. An added wrinkle is that Phase 1 and Phase 2 clients can't directly talk to each other. Routers like the Fastpath had a "transitional" bridge mode for them. The only tiny benefit I see to it is that Phase 1 DDP packets might actually be able to traverse Wifi without a problem since they don't use SNAP, but I have not been able to test this.


Netatalk's atalkd is generally well behaved. The biggest problem is AppleTalk's "zero configuration" nature getting in the way. The whole seed router and soft seed setup was always a headache back in the day. Vendors like Asante taking shortcuts and not implementing RTMP and AARP fully only added to the chaos.

That being said, about 99% of people want a Localtalk-to-Ethernet bridge to get non-Ethernet clients on a network.

 

[cheesestraws]

Pretty much nothing uses Ethertalk Phase 1. Apple quickly phased it out and added Phase 2 support to everything

That was my understanding as well: the main reason I bring it up is the odd little dance that the Asanté bridges do on startup to check whether they're on Phase 1 or Phase 2 networks. I was intending to totally ignore Phase 1, and just wanted to give people an opportunity to shout about it.

The only tiny benefit I see to it is that Phase 1 DDP packets might actually be able to traverse Wifi without a problem since they don't use SNAP, but I have not been able to test this.

At least here (UniFi kit, FWIW), it is the other way around: Phase 2 packets get through fine because the SNAP header is just copied verbatim into the WiFi frame and then verbatim copied back out, whereas the AP doesn't know what to do with the AppleTalk ethertype, so it just pretends the frame isn't there and carries on.

Vendors like Asante taking shortcuts and not implementing RTMP and AARP fully only added to the chaos.

That being said, about 99% of people want a Localtalk-to-Ethernet bridge to get non-Ethernet clients on a network.

I think it sounds like we're agreeing here: that the most useful thing to build to the most people would be an LT <-> maybe LToUDP <-> Ethernet bridge that plays nicely with complicated configurations for people who like that kind of thing, but otherwise just acts like a bridge?

 

[NJRoadfan]

The Fastpath 4 came with a PROM based routing program that did simple LocalTalk-to-Ethertalk Phase 1 bridging if you reset the router and didn't install the K-STAR router software. It didn't support multiple zones or anything fancy. Basically what the Asante and other "simple" LocalTalk bridges did.

Appendix A (pdf page 149) of the Fastpath 4 Admin guide goes into detail: http://www.bitsavers.org/pdf/kineti...ics_FastPath_4_Administrators_Guide_Sep89.pdf

 

[EtherRad]

Are there parts of Novell Netware that could interface with this?

 

[Johnnya101]

Agree, your largest target audience, assuming you want to sell and try and make a little bit of a profit, would be in some sort of all in one Apple talk router plus Ethernet bridge type of thing. Maybe make it compatable with your airtalk project, so one could plug in an airtalk into a Mac, and have a wireless apple talk router nearby that then goes to Ethernet. Plus it would have multiple local talk ports for a wired setup.

That's if this dream device is even possible to create.

 

[beachycove]

This is probably asking too much, but a way of measuring throughput would sure be handy….

Beyond this, AppleTalk to IP and vice versa, Zones, LocalTalk to EtherTalk bridging [presumably wired to wireless bridging isn’t needed, is it?], and software mapping of the network (see shareware app Trawl) integrated with said throughput measurement would be on my imaginary ideal AppleTalk router list.

I speak as someone who for some five years used to run an LC475 as an Apple Internet Router box 24/7, mediating between some thirty older and newer machines in my collection, for which it was exceptionally handy — and rock solid. But it had its limitations, and some of these were some of them. Having it all on a single efficient device would be superb.

 

[slipperygrey]

I'm all for providing options to the community -- the software based solution (Netatalk) for those who already have servers around and enjoy tinkering with Linux or NetBSD; the hardware based solution for those who want the plug'n'play experience and don't mind paying for it. There's definitely a subsection of the community who don't have the know-how or willingness to put in the effort to set up Netatalk. An always-on, low-power and reliable LocalTalk bridge would definitely be a killer app that Netatalk doesn't provide anyways.

As for physical layout, I would imagine RJ-45 in and RJ-45 out, and then the 8-pin mini-DIN to connect it to a LocalTalk chain. Anything else?

 

[mactjaap]

Absolutely great you are planning to do this.

I would really love to see a device or devices which can replace the old LocalTalk bridges. If these devices could be serious parts of a AppleTalk network this would be fantastic. Until now all devices developed can do part of the job (like LToUDP) but there is no device which can do all. If your AppleTalk router can help in this…. And don’t forget MacIP! Must work of course!

 

[cheesestraws]

Thanks all for the feedback here. Once again, I want to manage expectations: I'm going to have a go at this, but I don't know whether it will actually go anywhere. I have not built a router from the ground up before for any protocol, especially not one with dynamic routing behaviour like AppleTalk.

I'm planning to do software development for this in public, and anyone who wants to join in is extremely welcome. This isn't like AirTalk where I couldn't release the source for ages because it had sensitive credentials hardcoded in it (I promise I'm a professional...).

So, here's the initial aim:

• The project aims to produce a LocalTalk to Ethernet gateway with knobs on. It will also support LToUDP, and, if practical, may support Basilisk II's Ethernet-over-UDP as well.
  
  
• It will focus initially on producing a plug and play, low user complexity device/system, although with an eye to adding more advanced features for power users in future software updates (i.e. it will be designed not to close the door on things like complicated zone setups, even if initially it won't allow users to create them).
  
  
• It will not be a MacIP gateway itself, but it will play nice with MacIP out of the box, so that it can be used as a gateway in front of something like macipgw.

I think I am initially going to target the FreeRTOS + esp32 basic platform, for these reasons:

• FreeRTOS is pretty portable and so even if the esp32 is the wrong choice, then moving to another platform later should be straightforward so long as I keep talking to the esp32 hardware suitably abstracted. There's lots of choice of platforms for FreeRTOS.
  
  
• The esp32 has lots of nice peripherals on-chip: notably it has an Ethernet MAC which supports RMII, which will obviously help considerably.
  
  
• The usability of the tools to build software for the esp32 is actually really good. I have been really enjoying building AirTalk, and it's somewhat rare that I enjoy writing software for modern machines. So I'm going to stick with what's fun, and hopefully it will turn out also to be practical.

Sound reasonable?

 

[Johnnya101]

Very reasonable, and exactly what this community needs. Excited to see what you can come up with!

 

[mactjaap]

Absolutely! Really great! Can’t wait to see it happen!

 

[mikes-macs]

Could it include a time server with automatic Daylight Savings time configuration?
Perhaps pass FTP for servers with too new AFP Protocol?

 

[jeremywork]

As a preface I'll say I really haven't delved further into AppleTalk bridges than performing a factory reset on a Shiva FastPath 5, figuring out how to see the settings from the FastPath utility, and noticing that it basically worked for browsing the internet on a few of my PowerBooks through a basic residential gateway, and sharing files between a string of LocalTalk machines and a handful of Ethernet machines.

Despite that I know little about the inner-workings, I think that would be an ideal experience from a device you're describing.

I picked up a second one recently which I may clumsily attempt to use over a VPN in order to access LocalTalk machines across WAN, but for now it's just sitting at arm's length from my desk chair.

If I can provide any info on the hardware setup or software config of the FastPath, I'd be happy to. For now I'm more comfortable with a screwdriver and multimeter than I am outside a GUI

 

[cheesestraws]

Could it include a time server with automatic Daylight Savings time configuration?

I like this idea. The problem is that none of the microcontrollers that I'm thinking of have a hardware RTC, so it would be totally reliant on getting a time via NTP.

in order to access LocalTalk machines across WAN

I was thinking that being able to set up LocalTalk "VPNs" (more tunnels) across the Internet would be a fun feature in version 2.0 of this.

What I suspect may happen is that it'll end up with multiple firmware images, the default one being nice and simple and no configuration, and perhaps another with bells and whistles and stuff. And then of course other people can come and play and either contribute firmware patches or come up with their own variants based on what they personally want.

Developing the default one will obviously be phase one, but I've designed my "sketch" prototype to accept firmware flashing over USB to make this easier...

 

[olePigeon]

@mikes-macs There's a Control Panel called Network Time. You can use it to sync your vintage Mac's clock to any NTP server. I think someone also resurrected an AppleTalk based NTP server called TARDIS.

 

[cheesestraws]

I think someone also resurrected an AppleTalk based NTP server called TARDIS.

That would also be me timelord is the timeserver, TARDIS is the client. You can run a timelord server as part of netatalk.

 

[mikes-macs]

I was hoping somehow an AppleTalk based time server could be implemented somehow as opposed to a TCP/IP one so that Macs not on a TCP/IP network could still get the correct time thru his router.. I understand the "Network Time" control panel is a TCP/IP based option.

Maybe it's not even possible. I'm just going thru all the features a standard router has that could be implemented on his.

On another note. In my current setup here I'm using AppleTalk Internet Router and Apple IP Gateway. Clients get an IP but are not necessarily on the Internet unless I configure them to be. When a client is set to use "Ethertalk" in the TCP/IP or Mac TCP control Panel, ftp and some other IP based protocols are not passed thru. HTTP does get passed. However, If the client is changed to Ethernet in the control panels and the cable connected gets an IP from the main router (bypassing AppleTalk Internet Router and Apple IP Gateway) then ftp is passed and it's on the Internet. This is why many admins back then hated supporting MacIP it didn't pass all IP protocols. I'd like to leave it running thru the AppleTalk Internet Router and Apple IP Gateway but if it can't pass all the protocols what good is it?

Perhaps you could identify this issue and implement support like this in your router. I'm surmizing that's a higher level MacIP thing and you're not including MacIP in your router?

 

[cheesestraws]

was hoping somehow an AppleTalk based time server could be implemented somehow as opposed to a TCP/IP one so that Macs not on a TCP/IP network could still get the correct time thru his router

There is one! This is what timelord and tardis are. Originally, you installed the Timelord control panel on your server Mac, and the Tardis chooser extension on the clients, and it would sync the time on startup (or when you selected a new time server in the Chooser). I never got the timelord control panel to work properly (though I didn't try very hard) and now I use my fixed timelord server that runs in netatalk2 (which is in macipgw and @slipperygrey's new shiny integrated patchset, and I believe now upstream!). But it's over AppleTalk, no IP involved at all. You don't need a new router for this

(It would be a nice feature to add timelord on the router itself, but it would come at the cost of adding a real time clock to the hardware, which my current prototype design doesn't have.)

On another note. In my current setup here I'm using AppleTalk Internet Router and Apple IP Gateway. Clients get an IP but are not necessarily on the Internet unless I configure them to be.

I too currently use Apple Internet Router. I had really weird issues with Apple IP Gateway, though, and couldn't get it to reliably do what I want, and I can see why admins—especially IP network folks—hated it at the time.

As far as I know, though, there's nothing in the MacIP protocol that prevents FTP and other stuff going through, it's just the way that IP gateway does forwarding. At risk of making a suggestion you've already considered, can I suggest experimentally trying out something like macipgw to see if that helps?

I'm surmizing that's a higher level MacIP thing and you're not including MacIP in your router?

I would really like to do MacIP using proxy ARP and proxy DHCP so that you don't need to do the network shenanigans on the IP side. But at the moment, I don't know quite how that would work, and it'd be a reasonably big project on its own. It also relies on having a working AppleTalk router. So—for the moment I think I'm going to concentrate on making sure that existing software like macipgw works with this properly, while also making sure there are hooks in the software for this kind of thing to happen in future.

Specifically, I suspect that integrating this with both the LToUDP and maybe Basilisk UDP features may be painful; when receiving an IP packet at my ethernet interface, I'd have to insert a shim between the ethernet interface and the IP stack (like I'm doing to catch ELAP frames) that differentiated packets destined for the MacIP interface from those destined for one of the virtual ports. This is doable, but I think is ambitious for the first iteration of the software.

However, this does tell me that I need to make sure that ethernet shims are chainable . So, again, please keep the suggestions coming, they're useful to keep the basic design flexible even if they don't make it into iteration one of the design.