TashRouter: An AppleTalk Router

[NJRoadfan]

TAP is a virtual interface. They are generally used to allow your machine to connect to a VPN or some other network tunnel (such as a client VM). Basically they create a link between your machine's network stack and somewhere else at the layer 2 level. Generally they aren't used to directly forward traffic to/from a physical interface as normally you would use a router for that (nftables, etc.) As an example, A2SERVER's MacIP support creates an IPv4 network with a TUN interface that macipgw feeds traffic to. It connects to the rest of the network by using nftables and a NAT gateway similar to what your home router does with the internet.

libpcap on the other hand has raw access (with root permission) to traffic on network interfaces on the system. This allows you to see all packets and inject packets on a specified interface (this is how tcpdump and WireShark can capture traffic). This is similar to what VirtualBox does in "bridged" networking mode. I think there are other methods to do this in Linux, but generally client applications are supposed to talk via a layer 3 network stack on an interface (ie: use sockets via the kernel's IP stack, or AppleTalk). That being said, you could in theory connect your TAP interface as another port using netatalk's atalkd. It would be pretty redundant, but gets the packets onto a physical network without needing root. The downside is you are dependant on the host's AppleTalk stack and netatalk still.

 

[tashtari]

Taps are virtual interfaces, true - but strictly speaking, what they are (on Linux, at least) is a means by which a userspace program can receive and send Ethernet frames, which is what TashRouter needs and the same thing that libpcap offers. Are there some EtherTalk-specific issues that taps have that libpcap doesn't?

 

[cheesestraws]

tap interfaces are a way for user space processes to introduce frames into the kernel, not to send and receive packets from interfaces. It's a somewhat important difference.

 

[NJRoadfan]

EDIT: Ninja'd by cheesestraws

Thats the key, userspace programs don't generally have access to raw (layer 2 802.2/3 frames) data from network interfaces. You need to "see" layer 2 data from your physical Ethernet adapter to intercept AppleTalk traffic, but for security reasons you can't. I ran into this problem when looking into a user-mode TashTalk driver for Linux. The end result was the same, a TAP interface that would have to talk to atalkd to route packets onto a physical network. That being said, MacVTap attempts to solve this problem and is likely the solution. I would look into directly creating a macvtap interface, vs a standard tap interface+forwarding though.

Emulators wishing to add network support have the same problems with AppleTalk. I don't think Basilisk II, Sheepshaver, and MAME can reliably pass DDP AppleTalk traffic to a physical network unless they are using libpcap style injection. The other methods using a TUN/TAP interface (or vmnet on MacOS) are IP only from what I've seen. @Arbee would know more about this.

 

[NJRoadfan]

Also, I wouldn't throw out what was written already. The TAP interface is handy if someone wants to run TashRouter and netatalk on the same machine. I plan on doing exactly that to see how well it works routing between my TashTalk, minivMac, and Ethernet connected machines.

 

[Arbee]

I'm told that macOS vmnet *can* pass AppleTalk traffic if you use bridged mode instead of shared. I haven't had time to try that yet with MAME but hope to soon.

 

[tashtari]

Fair enough. I guess experimentation will tell us more. I did try to leverage libpcap to make an EtherTalk port driver based on it, but ran into some strange problems. Maybe I'll take another crack at it sometime, though there are things higher on my list at this point...

Anyway, I did some more digging and finally found what that header is about... did I mention documentation for MACVTAP is almost nonexistent? I found the answer in some random Github project. Bleah.

In any case, the EtherTalk ports are a bit less rough around the edges now. MacvtapPort will automagically populate its hardware address from sysfs and pick up the right /dev/tapX device, given the macvtapX name.

 

[tashtari]

It took a couple of bug-fixes and forehead-slaps, but I've had my first success getting TashRouter to interoperate on a heterogeneous network with another router!

The 630 (running System 7.5) is connected via a crossover Ethernet cable to the SE (running System 6.0.8 and AppleTalk Internet Router), which is connected to an RPi (running TashRouter) via PhoneNet, which is connected to Mini vMac (running System 7.1) via LToUDP, and the 630 and Mini vMac can see one another's AppleShare shares.

Progress!

 

[NJRoadfan]

What is seeding the network information on the PhoneNet segment? The SE running ATIR, or TashRouter? Sounds like TashRouter is soft seeding networks properly if the SE is providing the network number and zone information.

 

[tashtari]

What is seeding the network information on the PhoneNet segment? The SE running ATIR, or TashRouter? Sounds like TashRouter is soft seeding networks properly if the SE is providing the network number and zone information.

The SE is. TashRouter is able to be a seed router or a non-seed router on the networks it's connected to, though it doesn't (yet?) support the case where it only seeds the network if it doesn't find an existing seed router.

 

[tashtari]

I think at this point I can say that TashRouter is basically feature complete. I'm sure it's still got some bugs in it, but it should be competent to take on some real-world workloads.

This morning I added virtual ports and networks to its repertoire of port drivers, which will be a key step in getting automated tests set up as well as testing situations that require more real hardware than I own (or am willing to set up). Now you can pretend you're on an enterprise-grade AppleTalk network from the comfort of your own Python interpreter!

To anyone who's interested in giving this a try, please do, and let me know if I can assist. Also good to hear would be any ideas for features that could make this more useful. (...But don't suggest EtherTalk Phase 1.)

 

[NJRoadfan]

I'm going to have to try this bridging Ethernet to TashTalk and netbooting the Apple IIgs. My only question is, does this do translation of DDP headers from longform to shortform? While LocalTalk clients should handle the longform DDP headers, I don't know if the ROM based AppleTalk stack in a circa 1987 ROM 01 IIgs (or the IIe Workstation Card) is going to handle it.

 

[cheesestraws]

This doesn't do l2 bridging, it only does routing, so the long form DDP headers are mandatory or the network numbers will get lost.

 

[NJRoadfan]

I can't get this working on my RPi for unknown reasons. For some stupid reason, I can't add a macvtap interface, says "Unknown device type". Meanwhile a Debian VM works fine. This means I have to compile a kernel module...WHY?

 

[finkmac]

I can't add a macvtap interface, says "Unknown device type". Meanwhile a Debian VM works fine. This means I have to compile a kernel module...WHY?

Yup, the regular 32bit raspbian kernel doesn't have the macvtap driver. This is currently my stumbling block... I've tried to compile it as a kernel module unsuccessfully.

 

[tashtari]

I can verify that Void Linux does have it if you want something that supports macvtap out of the box, I use it on my RPi: https://voidlinux.org/download/#arm platforms

And it doesn't have systemd!

 

[NJRoadfan]

I gave this a test drive last night. I seem to be encountering some issues.

Configuration #1 "Keeping it Simple":
-TashTalk with HP LaserJet 4MP connected via LocalTalk
-Mini vMac connected via LToUDP

I can see zones no problem. I can also see the LaserJet....... but when I try to connect to the LaserJet the emulated machine just hangs. Packets are getting lost somewhere. Note that the same configuration using the tashtalkd bridge works fine, so it is not a hardware issue. I also tested this with a Fastpath 5 on the LocalTalk segment. I can see the zones from the FastPath, but I can't see the Fastpath itself on the network oddly enough.

Configuration #2 "Heisenberg's AppleTalk Network":
-TashTalk with HP LaserJet 4MP connected via LocalTalk
-Mini vMac connected via LToUDP.
-tap0 using TapPort() (not macvtap) "linked" to netatalk's atalkd.
-atalkd configured for two networks, tap0 and eth0 which has Macintosh clients on the Ethernet network.

This was.......well...... it kinda worked. Note that atalkd needs to seed the zones and network numbers on tap0, not TashRouter, otherwise stuff breaks. Here is the rundown.

-EtherTalk connected "Mac" (Basilisk II with pcap): I can see all zones and the netatalk server's resources. I can't see anything on the TashTalk or LToUDP side of the network at all.

-Mini Vmac: I was able to see and use all services on the netatalk machine (AFP and PAP). As above, I was able to see the LaserJet printer, but not communicate with it. I could not see the AFP shares at all on the Basilisk II machine.

From what I'm seeing, it looks like anything two router "hops" away is not accessible at all. When I get macvtap working, I can test this theory.

What is puzzling me is why I can't do anything with TashTalk connected devices via the router. Of all things, a simple LToUDP-to-TashTalk network should be working. Clearly ZIP, RTMP, and NBP packets are getting thru. I will be experimenting further with this later in the week.

 

[tashtari]

Thanks for giving it a run. Configuration 1 not working is definitely the most perplexing thing - what you describe was working for me with AppleShare but I don't have any AppleTalk printers to test PAP with so it might be a different animal. Can you run it with the latest from the repo and copypaste the full output with network traffic? Hopefully that will shed some light on the matter.

 

[NJRoadfan]

I need to pull out my beige G3 or Q605 and get some actual computers on the TashTalk side of things. I was pleasantly surprised it worked off of a TAP interface with little issue. I don't know if anyone actually used netatalk's atalkd in a production environment for routing between networks, but it certainly is a fussy beast that wants to always be in control.

 

[NJRoadfan]

Here is a copy of the log. When using Mini vMac, I open Chooser, select LaserWriter 8, the printer, and click "Setup". The dialog pops up that it is communicating with the printer (making PAP queries to determine make/model, etc.) but just hangs. I'll get a real Mac on that side of the network next.