TashRouter: An AppleTalk Router

[tashtari]

For those of us not lucky enough to own a Shiva...

Introducing... TashRouter!


Elevator Pitch

It's an AppleTalk router written in Python that runs on modern hardware and supports LocalTalk (via TashTalk), LToUDP, and EtherTalk.


Project Status

Minimally functional. Currently, on a network where it is the only router, it has been tested to be able to pass data between a TashTalk network and an LToUDP network. Support for other routers on an internet is implemented but not tested.


Caveats

Currently I only expect this to fill the use case of an internet (an internet, not the internet) router for AppleTalk, not the "half router" or "backbone network" cases detailed in Inside AppleTalk, but it's possible that may change. Other than that and the fact that it's not done yet, nothing, really.


What's Next

A port driver for EtherTalk is high on the list of plans, as is testing, testing, testing - I've been very much in move-fast-and-break-things mode, trying to build my somewhat anemic knowledge of networking as I go. If I'm successful, it's my intention that this becomes part of a larger effort to liberate us from boondoggles like Netatalk 2.x and the rotting AppleTalk code in the Linux kernel.


Code

GitHub - lampmerchant/tashrouter: An AppleTalk router that supports LToUDP and TashTalk.

An AppleTalk router that supports LToUDP and TashTalk. - GitHub - lampmerchant/tashrouter: An AppleTalk router that supports LToUDP and TashTalk.

github.com

Special thanks to @cheesestraws for advice and encouragement. I'd love for any adventurous types out there to give this a try in its current state and/or give the code a look - suggestions and comments are welcome.

 

[twelvetone12]

Very cool! When I'm back I'm going to try this asap, I also have a fresh batch of fixed LT2USB waiting for me.

 

[dochilli]

Could this be used as a Localtalk-Ethernet bridge? The old Asante bridges became expensive in the last years...

 

[tashtari]

Could this be used as a Localtalk-Ethernet bridge?

It can definitely be used to interconnect LocalTalk and EtherTalk networks, if that's what you're asking. Others can explain the technical specifics better than I can, but the short version is that a bridge (such as the AsanteTalk) does some hackery that makes it incompatible with AppleTalk routers, whereas a router such as TashRouter will play nice with the rest of any AppleTalk internet, no matter how it's laid out.

 

[Phipli]

with the rest of any AppleTalk internet

Is this internet, or intranet? I thought one within a building would be intra... But this really isn't my topic. "Inter" means "between" though, and "intra" means "within", is what I'm thinking that.

 

[tashtari]

Is this internet, or intranet?

I'm mirroring the use of the word "internet" from Inside AppleTalk, where I think the idea is that it refers to a set of interconnected networks which may span buildings or geographical sites, potentially using things like point-to-point links.

 

[Phipli]

I'm mirroring the use of the word "internet" from Inside AppleTalk, where I think the idea is that it refers to a set of interconnected networks which may span buildings or geographical sites, potentially using things like point-to-point links.

I see, I'd mention it, but possibly avoid that terminology as it has changed with time and doesn't sound like it aligns with the current nomenclature!

 

[cheesestraws]

An internet is a network of networks. The Internet (capital I) is the biggest internet, but not the only one.

An intranet is a marketing buzzword for a LAN that runs TCP/IP and has a web server on it. Like most marketing terms, it should be treated only with the deepest contempt and avoided by all sensible people.

 

[Phipli]

An internet is a network of networks. The Internet (capital I) is the biggest internet, but not the only one.

An intranet is a marketing buzzword for a LAN that runs TCP/IP and has a web server on it. Like most marketing terms, it should be treated only with the deepest contempt and avoided by all sensible people.

Does anyone still call multiple linked LANs an internet?

It sounds like an aweful way to confuse people, regardless of the historic definition.

 

[cheesestraws]

Does anyone still call multiple linked LANs an internet?

Yes, it is a technical term, along with the verb "to internetwork".

In this context, an AppleTalk Internet Router is a specific thing, as defined in Inside AppleTalk. If this were a "hey end users here's a new thing" thread I might agree with you, but I wouldn't recommend new users use a brand new and un-debugged AppleTalk router without knowing what they're getting into - no disservice to @tashtari of course, I'd say the same thing if it were mine. So since this thread should really be a discussion thread about the technical details of a very specific thing among people who understand the ins and outs of that thing, using the right name for that thing is a good idea.

 

[Phipli]

Yes, it is a technical term, along with the verb "to internetwork".

In this context, an AppleTalk Internet Router is a specific thing, as defined in Inside AppleTalk. If this were a "hey end users here's a new thing" thread I might agree with you, but I wouldn't recommend new users use a brand new and un-debugged AppleTalk router without knowing what they're getting into - no disservice to @tashtari of course, I'd say the same thing if it were mine. So since this thread should really be a discussion thread about the technical details of a very specific thing among people who understand the ins and outs of that thing, using the right name for that thing is a good idea.

Fair enough.

 

[Arbee]

Could you use a copy of TashRouter on each end of a WiFi connection to bridge EtherTalk over the connection when the router would otherwise corrupt the packets (or whatever exactly is going on there)? As far as I know LToUDP doesn't have any problems with WiFi.

 

[tashtari]

Could you use a copy of TashRouter on each end of a WiFi connection to bridge EtherTalk over the connection when the router would otherwise corrupt the packets (or whatever exactly is going on there)? As far as I know LToUDP doesn't have any problems with WiFi.

Interesting use case - I think that should work, yes. (Though I can't test it until I finish writing the EtherTalk port driver.)

 

[NJRoadfan]

See this thread with regards to my findings on why WiFi breaks AppleTalk: https://68kmla.org/bb/index.php?thr...hy-ddp-appletalk-doesnt-work-with-wifi.45811/

TL;DR DDP Phase 2 packets pass over WiFi fine. The issue is AARP. Many WiFi routers assume SNAP packets with a OUI of 0x00 0x00 0x00 should be converted to Ethernet II frames instead of remaining SNAP frames. The SNAP discriminator for AARP Phase 2 is 0x00 0x00 0x00 0x80 0xF3, so you can see where this is going. You land up with AARP "Phase 1.5" packets with Ethernet II framing (like Phase 1 used), but Phase 2 data (there is a network number in the payload).

The good news is open source router firmware based on OpenWRT and DDWRT handle this properly since they rely on Linux to do the translation. It can also likely be fixed with a machine sniffing packets on the Ethernet network and retransmitting them with the correct SNAP header.

 

[NJRoadfan]

With regards to TashRouter. One thing I don't think Inside AppleTalk covers in depth is the concept of "soft seed" routers. This is something the old hardware routers of the past offered. Instead of blindly seeding the network, they would check for the existence of another router on a port (Ethernet, LocalTalk, etc.) and if one was detected, configure that port automatically to that network. If one was not found, then the router would begin seeding its configured information. This is why netatalk's atalkd daemon takes so long to start!

 

[cheesestraws]

If you had unicast LToUDP with explicitly configured endpoints at each end you could do it over the Internet, just saying

 

[tashtari]

Well, I'm fairly sure the head-shaped dent in my desk is now permanent, but TashRouter now has a working EtherTalk port driver! And a non-working one, too, as it happens. Here's a brief summary:

My first thought was to use an Ethernet tap in Linux to send and receive EtherTalk frames, putting the tap with the actual physical interface on a bridge. This almost worked, except that it for some reason could not receive unicast frames directed to the tap, just broadcast ones. Nothing I did seemed to be able to change this - I enabled promiscuous mode, I played around with the MAC addresses, nyet. The port driver seems to be functional, though, so if you, dear reader, are better at networks than I am (this isn't a high bar to clear), you can make use of the tap driver at tashrouter/port/ethertalk/tap.py in the repo.

My next thought was to use something newer called a MACVTAP, which seemed like just the right thing for this use case. It's very scantly documented, though, and I still don't understand certain things about it, like what the meaning is of the ten bytes that precede the frame data... I might have to go diving in the kernel's code to find out. This had the opposite problem, that it could receive unicast frames but not broadcast ones. ARGH. In this case, however, turning on promiscuous mode let it receive broadcast frames, and I was able to access an AppleShare server running on Mini vMac 37 (a build with LToUDP) from my 630, connected via a comm slot Ethernet card. Success!

The whole affair still has some rough edges, chief among them the fact that you currently have to put the MAC address of the tap in the appropriate driver source file, but it works! It's aliiiiiive!

I'd love for some folks out there better versed in Linux networking than I to give this a try and let me know if you're able to make a tap/bridge setup in which the regular tap (not MACVTAP) driver works.

GitHub - lampmerchant/tashrouter: An AppleTalk router that supports LToUDP and TashTalk.

An AppleTalk router that supports LToUDP and TashTalk. - GitHub - lampmerchant/tashrouter: An AppleTalk router that supports LToUDP and TashTalk.

github.com

Happy routing!

 

[NJRoadfan]

The only approach that likely works reliably is to use libpcap and sniff/inject packets off of a selected Ethernet interface. EtherTalk is.... annoying with virtual interfaces.

 

[tashtari]

The only approach that likely works reliably is to use libpcap and sniff/inject packets off of a selected Ethernet interface. EtherTalk is.... annoying with virtual interfaces.

That's what a tap does, isn't it?

 

[finkmac]

bravo, incredible. i will try this out at my earliest convenience.
we praise your efforts.