Linux kernel drops AppleTalk Networking

in the same news, the code will be moved to github.com/linux-netdev/mod-orphan

Based on this, I understand it should be possible to build an external module.

Also, while looking for an alternative, I stumbled upon this project
github.com

GitHub - FeralFirmware/TailTalk: A modern async user space AppleTalk stack with Rust + Tokio

A modern async user space AppleTalk stack with Rust + Tokio - FeralFirmware/TailTalk
github.com github.com

It aims to create a userspace implementation of AppleTalk
 
My understanding is maintaining an out-of-tree module can be challenging: the whole "we don't break userspace" mantra doesn't apply to the kernel's internal interfaces which can rapidly change without much warning.

I think TaliTalk is being done by @Bolacore here?Absolutely no disrespect to what they're doing, it's quite interesting, but Netatalk has been around for a long time (I mean, I've been a user for like 20+ years). There's something to be said for codebases that have decades of testing and bugfixes applied. I personally won't be looking for an alternative unless the devs decide they don't want to continue work on the project.
 
That’s me yes, but it targets a very different purpose than Netatalk. TailTalk is a really primitive stack by comparison as we don’t do any packet routing, zones, or things like that as I figured if you needed those you’d use the battle tested software made for that purpose (I.e Netatalk). Maybe that will change in the future, I just didn’t want to bite off more than I could handle at this point.

Quite a shame to see it dropped, but I can’t say I’m surprised either. Just hoping the out of tree sources now won’t be too hard to keep updated against the newer kernels.
 
If there is enough feedback the removal will be postponed. That is the most straightforward approach now. If nobody complains, then the kernel networking folks will be justified.

They need an active maintainer who can chug through the AI generated bug reports.
 
very disappointing but not surprising given the real AI chaos around the kernel right now, appletalk in the kernel has been in danger for a while

I haven't looked closely at the code, but (hubris incoming) it's only a few thousand lines, I wonder how difficult a small interface would be (especially considering netatalk is more or less the only user of the kernel appletalk stack).
 
NJRoadfan said:

Linux Finally Ends AppleTalk Protocol Support - Phoronix

www.phoronix.com www.phoronix.com

Thanks AI....

Can't say I'm surprised given the slop of AI bug reports flooding everything. Overall it seems to be driving maintainers of open source software to the point of quitting at an alarming rate. Hopefully it won't be too hard to compile out-of-tree or be replaced with something user space. Really puts a damper on work I did for Netatalk and A2SERVER.
Click to expand...
I thought the kernel gurus had agreed to back off on this due to community pushback?
 
slipperygrey said:
the commit is unambiguous with the intention:

"Remove AppleTalk. Let it join hamradio in our out of tree protocol graveyard, I mean, repository."
Click to expand...

Here is the patch that "broke the camel's back": https://patchew.org/linux/20260614095226.1210-1-zhaoyz24@mails.tsinghua.edu.cn/

Luckily some major fixes were applied with help from @dougg3 and others before this happened. I don't have any issue moving this to a userspace stack, but some more warning would have been appreciated. The kernel only implemented DDP packet handling and AARP, the rest of the lower level protocol suite was provided by Netatalk's atalkd daemon.

This mod-orphan repo is new, so we don't know how future distros are going to handle these modules. There is some commitment to patch them though since LTS distros still include this support.
 
Last edited:
Maybe it is not the right thread for this, but, I did toy around the past couple days on what it would take to have the full Netatalk suite run using TailTalk as a replacement for the dropped kernel driver and the answer seems to be not a _huge_ amount. Screenshot is from Netatalk 4.x serving an AFP share via a TailTalk shim and a TashTalk USB device - still uses atalkd and afpd as usual, Netatalk fully remains in control of addressing and such, with the shim being a low level replacement for the existing kernel calls.

Have roughly 300 lines changed in C code and 100 or so for build system changes to make it opt-in.
 

Attachments

  • Picture-1.png
    Picture-1.png
    60.7 KB · Views: 6
Bolacore said:
Have roughly 300 lines changed in C code and 100 or so for build system changes to make it opt-in.
Click to expand...
This number seems high for a "shim" for some reason, particularly the build system changes. This is meson we're talking about here, not autotools. 🤪

There is an open issue for this now: https://github.com/Netatalk/netatalk/issues/3116

The atalkd daemon naturally has the most hooks into the kernel level stuff (routing tables, enumerating and handling network interfaces). The other AppleTalk daemons and client applications are dealing with shuffling ATP DDP packets around and shouldn't be too complicated beyond sending and receiving DDP packets over a given port.
 
NJRoadfan said:
This number seems high for a "shim" for some reason, particularly the build system changes. This is meson we're talking about here, not autotools. 🤪

There is an open issue for this now: https://github.com/Netatalk/netatalk/issues/3116

The atalkd daemon naturally has the most hooks into the kernel level stuff (routing tables, enumerating and handling network interfaces). The other AppleTalk daemons and client applications are dealing with shuffling ATP DDP packets around and shouldn't be too complicated beyond sending and receiving DDP packets over a given port.
Click to expand...
Hah I will admit I have never touched meson before, so it was mostly me trying to get it to compile and bring over the C library I was exposing to hook in to and start the Rust side runtime. It probably should be waaaay less by someone who knows what they are doing :)

The C code was kinda a lot of ifdefs. I found most of the bits went through netddp which was super handy for redirecting most of the traffic, then it was just hacking in a way to query what interfaces TailTalk had, then replacing all the kernel calls like where it enables multicast, “select” on the ATP file descriptor, setting the address and so on. The git diff was 300 but most of it was “if has kernel drv, do original code, otherwise call TailTalk equivalents”. I am of course no Netatalk expert so I am sure there would be better ways of doing this, it was just a crappy proof of concept 😅

EDIT: had a read through of the issue ticket and the option kinda sound like what I ended up with. I made what is a Unix domain socket with an API on it, and a C-callable library exposed. It lets the caller specify the DDP protocol type, control the addresses, and so on. It also shifts routing over to it in that you tell it what interface to send the packet over, rather than assuming. I didn’t realise you had already started on this though sorry! Didn’t mean to just butt in 🫠
 
Last edited:
You must log in or register to reply here.

Similar threads

slipperygrey
Yet Another Netatalk 2.2 Fork
9 10 11
Replies
214
Views
61K
slipperygrey
slipperygrey
demik
Benchmarking Mac II NuBus Networking (A/ROSE, OpenTransport)
Replies
3
Views
3K
demik
demik
C
MacSD: Trip Report
Replies
3
Views
3K
Byte Knight
Byte Knight
V
Configuring MacIP gate on Debian server
Replies
6
Views
1K
mactjaap
mactjaap
Back
Top