Doc request: compatibility table

[paulie-g]

It would improve the usability of this fantastic effort of yours greatly if there were a compatibility table that clearly listed what combination of MacOS versions, MacTCP/OpenTransport versions, transports (ethernet, IP, localtalk) and, most importantly, netatalk authentication methods were compatible. I had to abandon trying to get it set up because the combinatorial complexity exceeded my tolerance for uninformed jiggery-pokery. At a minimum, it would be lovely if the authentication methods had their compatibility documented. I accept this info might be somewhere, but I couldn't find it in a reasonable amount of time.

[rdmark]

@paulie-g Totally agree with you that better documentation in this area would help tremendously. It would definitely have saved me time early on! In general, if functionality in my fork is equivalent with upstream Netatalk, my preference is to document this upstream as well. I could kick off an FAQ in the upstream wiki and take it from there. What do you think?

The UAMs are fairly well documented upstream, actually, with a decent compatibility matrix you can refer to.

What I recommend based on my own somewhat limited testing is:

• For OSX 10.2 through Monterey (and beyond) use DHX2
• For anything earlier, use Cleartxt

There may be corner cases where you want to use DHX or Randnum but I have yet to encounter any.

[paulie-g]

Upstream no longer cares about our use case, right? I would definitely upstream docs as a matter of politeness/giving back where applicable (although since they no longer support our MacOS versions, I'm not sure it'd be "applicable"), but I would prefer a short wiki page on 'getting started' and compatibility/things to try first here, clearly pointed to from readme.md.

I would supply such a write-up, but I abandoned getting this working because it'd already taken too much time, I knew I could have ftp set up in < 5 mins and only needed floppies or CD-Rs to arrive in the mail to get Stuffit/MacBinary/Binhex on the Mac box. This is sad.

None of it is rocket surgery, and I'm sure I'd have gotten it working eventually. I also fixed the TUN handling in the currently most popular fork of Basilisk II and, if I were prepared to drop my long-running connections (which I wasn't at the time) and switch to a bridged rather than masqueraded config, I'd have gotten that working too I'm sure. It just wasn't worth the time investment, after I'd already sunk time into debugging all the compile issues - I had a MacOS box I'd managed to wipe Stuffit off (MacOS doesn't create aliases on drag, which I'd forgotten) and I just needed to get, at a minimum, MacBinary or binhex on there to undo my screw-up. In the end, it was just easier to wait until floppies arrived in the post the next day and set up ftp ;)

I see no reason this has to be hard, or require fishing upstream. A good "getting started" page with example configs should make getting this working trivial.

[rdmark]

I've started fleshing out the fork's README.md with examples, basically the simple "universal" setup that I've ended up using everywhere after much experimentation.

Several months back I wrote a fairly comprehensive step by step guide geared in particular for running Netatalk in parallel with RaSCSI on a RPi. I plan to adapt more of that content over.

If you like, you can also try the easy install script that I ported over from the RaSCSI project today. If it works, it should pretty much do everything you need to replicate my go-to setup. Again, Debian centric. Sorry. I'm lazy that way. :)

[rdmark]

There, I've captured pretty much the extent of my knowledge in the README.md. It should now serve as a guide for setting up a universal AppleShare that should work on every single networked Mac OS version (I think.) The only real gap is that I haven't really tested it with Apple II or Lisa systems. But I now have both a IIgs and a Lisa 2 in my workshop so it's only a matter of time... :)

Let me close this out for now. Please let me know if you find any gaps in this documentation!

[paulie-g]

Your write-up is absolutely fantastic. Don't worry about it being Debian-centric, people who use something else will figure it out. I didn't notice anything particularly remarkable.

After reading, the one question I have remaining is the kernelspace appletalk implementation. Does Netatalk need it? I saw a reference to all code being removed from Netatalk as it was committed to linux mainline. Does this apply to this branch or did it happen later? It's going to be a loadable kernel module for most people and will need to be modprobed presumably. I never did before, but Netatalk didn't complain. Either it doesn't need it, or it's somehow not erroring out despite PF_APPLETALK not being present.

[rdmark]

Good call. I added section about the AppleTalk kernel module. https://github.com/rdmark/Netatalk-2.x/blob/branch-netatalk-2-x/README.md#appletalk-kernel-module

And yes, to answer your question, Netatalk relies on the kernel to provide AppleTalk / DDP support. If it doesn't find a kernel module it will error out The built-in support was deprecated long before Netatalk 2 I believe. In my experience, again with Debian based distros, the module is either always loaded, or loaded dynamically when atalkd starts up. It was only with one older version of Raspbian where I had to compile support into the kernel.

[paulie-g]

Yes, turns out you're correct - atalkd loads the appletalk kernel module if available. That's the reason it didn't error out for me.

Btw, a better test for whether the appletalk module is available in the first place is:

sudo modprobe -v appletalk

[rdmark]

Thanks for the tip. When I tried the modprobe -v command in my environment I'm not getting anything on stdout when appletalk is already loaded though. I'll play around with it a bit more.