
Hacking up a fix for the broken AppleTalk kernel module in Linux 5.1 and newer - zdw
https://www.downtowndougbrown.com/2020/08/hacking-up-a-fix-for-the-broken-appletalk-kernel-module-in-linux-5-1-and-newer/
======
tyingq
_" In this case, someone submitted a patch 10 months ago and was asked to
tweak the patch. Then life got in the way (I totally understand), and he
finally tried again about 9 months later...

He was also asked to tweak the second patch because of a minor style issue
(which I also understand). A third try at submitting the patch hasn’t been
attempted as of this writing."_

I've been there. I understand both sides, but it's a bit frustrating from the
_" outside contributor"_ standpoint sometimes.

For example, I use git quite a lot, but not GitHub. As a result, a pretty
simple _" couple of lines"_ fix I tried to contribute remains uncommitted
because I wasn't able to format things in a way that made the target project
folks happy. The pull request remains sitting there. Though I still
occasionally get "thank you" messages from people that accidentally find and
use it.

So, some number of folks lose out on a good fix roughly because what would
take me several hours, but take someone else a few minutes, just doesn't get
done.

Some sort of web based _" force this minor tweak for a pull request"_ feature
might have a decent upside.

~~~
stormbrew
Is there some kind of cultural reason in the process of submitting patches to
linux that someone else couldn't come along and, while giving due credit, do
the style fixups on one or the other of the patches themselves and submit that
as a v3/v2?

Like, why should every attempt start from scratch as people lose interest?

~~~
dougg3
That's exactly what I was mulling over in my head today (I'm the author of
this blog post). If there's some way to simply provide a v3 of this patch
while leaving the credit with the original author, I'd love to do it. I just
didn't want to step on anybody's toes, and I don't know the etiquette. I think
this kind of thing happens more often than we realize. I've seen similar
situations before on other drivers.

~~~
l1k
Download the raw patch from lore.kernel.org, apply it with "git am", fix up
the commit message with "git commit --amend", add your "Signed-off-by" below
the existing one, submit with "git-send-email" or "git format-patch" \+
"msmtp".

That way the commit author remains the same because "git format-patch"
includes a "From:" line in the message body which "git am" will interpret as
the commit author when the maintainer applies the patch.

Your Signed-off-by is necessary to keep the DCO chain intact:
[https://www.kernel.org/doc/html/latest/process/submitting-
pa...](https://www.kernel.org/doc/html/latest/process/submitting-
patches.html#sign-your-work-the-developer-s-certificate-of-origin)

However, that is now done:
[https://lore.kernel.org/netdev/086b426f44bc24360cc89476fe18d...](https://lore.kernel.org/netdev/086b426f44bc24360cc89476fe18d2758a2652af.1596344622.git.lukas@wunner.de/)

Thank you for the report.

~~~
dougg3
Thank you! That is very useful to know for the future.

------
jhallenworld
If you want this fixed forever, a regression test needs to be created for it.
I have no idea how this works for the Linux kernel, but Google search reveals
this project:

[https://lwn.net/Articles/625969/](https://lwn.net/Articles/625969/)

------
ficklepickle
That was a really fun debugging ride. I've never really had to debug kernel
stuff before, so I also learned some things. Then you topped it off with some
serious hacks. You sure know the way into my heart. Thanks for writing about
it!

While I don't have a personal use for AppleTalk support, it makes me happy
that support for old protocols lives on.

------
saagarjha
Ah, stripping the signature from a binary you have modified. Glad to hear that
others get to enjoy this previously mostly macOS-unique diversion now ;)

------
userbinator
_The problem here is that Ubuntu’s kernel modules are signed._

It's easy to bypass, as the article shows, but also sad that this user-hostile
practice has spread to Linux. I'd expect this for Windows or Mac, but not
Linux.

~~~
Jonnax
It's not a user hostile practice if you have control over it.

Do you consider signing keys in apt packages to also be user hostile?

------
maallooc
Is there an advantage to enable AFP on my NAS?

I have a Macbook but smb seems kinda shady there.

~~~
ianlevesque
Newer macOS prefers SMB3 over AFP, even for time machine backups. There’s no
reason to use AFP anymore on a modern Mac.

~~~
duskwuff
And you don't even need the AppleTalk module for AFP. (I don't think modern
macOS even supports AppleTalk anymore.) AppleTalk only comes into play when
you're dealing with _really_ old Mac systems which didn't support AFP-over-TCP
yet.

~~~
joezydeco
What hardware do you use to connect the two?

~~~
rjsw
All the things described are running over ethernet, there isn't any special
hardware.

The kernel module implements the stuff described in the sections on EtherTalk
and AppleTalk phase II on this [1] wiki page.

[1]
[https://en.wikipedia.org/wiki/AppleTalk](https://en.wikipedia.org/wiki/AppleTalk)

~~~
joezydeco
So just a LocalTalk to Ethernet bridge?

~~~
rjsw
No, the old Macintosh uses its ethernet controller to connect to the Linux
server, LocalTalk isn't used.

~~~
joezydeco
I see.

When the article mentioned AppleTalk I envisioned a way to get files off of my
old SE using something that hooked into the ADB networking ports.

~~~
dougg3
That too is possible (serial ports though, not ADB). There are existing
LocalTalk-to-Ethernet bridge products from long ago that are getting harder
and harder to find. I was actually working on a new one for a while but ran
out of the time/motivation to finish it up.
[https://mac68k.info/forums/thread.jspa?threadID=275&start=0&...](https://mac68k.info/forums/thread.jspa?threadID=275&start=0&tstart=0)

~~~
joezydeco
Great info, thanks

------
rjsw
AppleTalk works fine on NetBSD. Doesn't require some long process to fix
anything that breaks.

~~~
rjsw
My point was that maybe the Linux development process isn't a good match for
niche areas like this. With NetBSD+pkgsrc, I can (and have done) just commit
fixes to the kernel and userland AppleTalk code directly without needing to go
through gatekeepers who may not have used this feature.

The blog author might want to look at a recent pkgsrc patch to netatalk 2.2
that makes it work with current CUPS.

