Linux kernel drops AppleTalk Networking

[NJRoadfan]

Nothing has actually been started. Just a discussion opened by @slipperygrey.

A preferred way to do this would be to abstract most of the changes. Netatalk already has the netddp functions defined in netddp.h to partly abstract socket communications. That alone should get afpd, papd, a2boot, and timelord working since they all rely on ATP, which calls netddp_open/close/send/receive. Being an external project originally, macipgw doesn't use it at all.

Oddly, the NBP, RTMP, and ZIP packet handlers in atalkd don't use these abstracted functions, but I don't see why they can't. Of course the comments in the code are minimal to none. The main atalkd handler also doesn't use them, but that code is "here be dragons" and I really hate touching it for fear of something blowing up.

TL;DR: Instead of a ton of ifdefs in the code, focus on routing everything thru netddp.h function calls and putting your entry points (kernel vs. userland ifdef macros) there. This makes code easier to maintain. When I have time, I'll look to see if abstracting the rest of the socket calls in atalkd can be done safely.

 

[slipperygrey]

@Bolacore no butting in whatsoever, on the contrary I would say that it's beneficial to be running multiple PoCs in parallel to see what works best!

 

[Bolacore]

One of the things I was curious about too is what you thought about using protobuf for the definition for the userspace daemon < - > atalkd/netatalk components. I thought it would be interesting to have a well defined format for it so the daemon side could be swapped fairly easily. This is what I used for the PoC with Prost for the Rust side and nanopb for Netatalk, encoded as varint length delimited + protobuf payload over Unix socks. I use gRPC heavily for work so I am sure you can see the influence bleeding through

Here was a link to the TailTalk userspace daemon using the above style that I cleaned up a little bit that ran the Netatalk demo I took a screenshot of: https://github.com/FeralFirmware/TailTalk/commit/66e2669773047bf0c3ea3323bc7a037d0e3c7b86 Not pretty by any means, but it does work reasonably well for a PoC I think.

I admit that trying to hook to what is a third party userspace daemon though probably isn't super fun for Netatalk maintenance, but I'd love to help out in any way I can to keep this project going regardless of if it uses TailTalk or not.

 

[slipperygrey]

if it means we can leverage your work on the DDP stack for the small price of building some glue code and maintaining a protobuf, then it sounds like a fine tradeoff to me

I only glanced through the code so maybe this is obvious, but I assume the tailtalk-broker would interface with atalkd which supplies the routing, zoning etc?

 

[Bolacore]

I think that's the other question I have honestly - Would it make sense to have the userspace daemon be a dumb one in that clients must be routing table aware (i.e "Send this exact packet via interface X" and the daemon does nothing more than fire it off just as you asked) or keep it like it is today in that the daemon gets programmed with the those routes/zones by atalkd and sends the packet out the right interface.

I did the former option for the demo but from looking at the rest of the Netatalk code I would imagine the latter is preferable right? That way atalkd stays in charge of routes and such but all the rest of the suite remains unaware of them all.