MacIP Integration

[H296]

Netatalk has been very good recently. It's been updated and combed through V2 to make it more modern and fix a lot of issues over the years.

However most people these days will find that we may be relying more on serial port communications for 68K and early PPC boxes. Ethernet adapters are drying up and some, like PowerBook Duos, are stuck without a MiniDock. When was the last time you saw an EtherDock or UltraDock 16sce?

As part of this, people like to use Netatalk to serve files to their older machines. We may want to do more than that, by adding TCP support, which is readily available in System 6+. While this is possible with the macipgw project, it hasn't been updated in 9 years, and incorporating it in the Netatalk package would be smart as right now we have some qualified people on the project who, from what I can tell, know it fairly well from the vintage Mac side but also the modern side.

As lowly user, I would appreciate a simple, easy to use .conf file I can edit which adjusts the parameters of the gateway and NAT service. Obviously the user would have to enable port forwarding, but that's easy enough with a single command in a shell.

The alternative, if you don't want to use macipgw, is to use a fake PPP dialup instance over a serial port. If you are wondering if that is slow, the answer is yes. Slower, that is, than MacIP.

You could also use something like IPNetRouter or something else, but considering the difficulty I've had in getting AppleTalk to work with Basilisk II, I'd still consider the macipgw route a better choice. Windows has been very fussy for me on bridging TAP connections and macOS 10.13+ is a solid "No" for me.

I am not active on Github and this is the first post I've ever made. Please find me on 68kmla or Tinker Different if you'd like to reach out to me, as I will likely forget I made this post with how much is going on.

[NJRoadfan]

macipgw is likely licensed under an incompatible license (BSD like) which would preclude it being integrated into netatalk 2.x. Its easy enough to compile, although it needs additional setup depending on the machine and network its connecting to.

[rdmark]

Thanks for raising the ticket. For posterity: This came out of a discussion thread at TD: https://tinkerdifferent.com/threads/netatalk-2-4-0-released.3653/#post-31081

There are a bunch of considerations to unpack here, but let's start with the license, since an incompatibility is something that would make it a non-starter.

I'm using the FSF's list of compatible and non-compatible licenses as reference.

The macipgw copyright statement is here: https://github.com/jasonking3/macipgw/blob/master/COPYRIGHT

I can see three distinct copyright holders and licenses:

• Stefan Bethke / BSD-2-clause
• Regents of The University of Michigan / MIT(X11)
• The Regents of the University of California / BSD-4-clause

According to the FSF's list, the first two are compatible with GPLv2, while the third isn't...

BUT, the University of California is a special case, because they retroactively revoked clause 3 (the so-called advertising clause) of their 4-clause license around the turn of the millennium. Here are a few pieces of historical records as proof:

https://krbdev.mit.edu/rt/m/ticket/history?id=4561 https://spdx.org/licenses/BSD-4-Clause-UC.html ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

Additionally, Netatalk already contains code that are under the UMich MIT license as well as the University of California modified BSD license. So while IANAL all signs points towards licensing not being a blocker.

Any other takes here? I might be overlooking some crucial detail.

[rdmark]

For reference, here is a breakdown of the license grants and copyright holders for each file in the netatalk2 source tree, courtesy of Debian's semi-automated copyright tools:

https://salsa.debian.org/netatalk-team/netatalk/-/blob/debian/old/debian/copyright

[NJRoadfan]

The code compiles cleanly on current distros of Linux. It likely works fine on *BSD as well. The biggest issue I see is with the installation. Its not a nicely packaged daemon with a configuration file, one usually has to trigger it with a shell script to setup other networking stuff. Due to differences in end user equipment, there are multiple ways of setting it up.

The most reliable setup I've found is NAT, but that requires playing with the host OS's tunneling and firewall, which has changed multiple times over the years on Linux. The instructions on the macipgw page are already obsolete as Linux, has once again, rewritten its firewall stack and moved from iptables to nftables.

The other big problem is that distros (notably Debian) are still shipping kernels with IPDDP handling enabled. This is a non-starter for macipgw as this filters out all MacIP traffic at the kernel level. If you want to use the software, you are going to have to recompile the AppleTalk kernel module. Not a pleasant experience for an end user. This should be a non-issue in the future as IPDDP was removed completely from the kernel late last year in 6.7.

[rdmark]

The upcoming Debian Trixie currently uses kernel 6.9.7 - which also contains the fix for AppleTalk routing on multiple interfaces - so the future looks bright in this regard.

Last night I dove into the macipgw codebase and forks. The jasonking3 fork that we have been focusing on so far has one big drawback: It completely strips out the BSD bridge code, and leans into Linux-specific calls.

Stefan's original git repo is still online on SourceForge, and he seems to have done some updates in 2013 to add support for Linux, in addition to FreeBSD, which aren't reflected in Jason's fork (AFAICT).

Finally, the author of the now-defunct netatalk-classic fork of netatalk did exactly what this ticket suggests, and made macipgw a module of netatalk. He modernized the code 4 years ago, and made it properly cross-platform with compile time support for Linux and BSD (NetBSD to be exact, since other BSDs have removed AppleTalk networking.)

What I would do if we took on this project, is to fork Stefan's repo, replay the commits from the netatalk-classic fork, then look into cherry-picking specific improvements from the jasonking3 fork (that aren't Linux specific). Then devise a build system for the end product.

[rdmark]

@stblassitude Hi Stefan, are you by any chance the same person who created macipgw a few decades ago? If so, I would love your thoughts on this thread, if you have any advice or opinion on how future development of macipgw should be conducted.

There are no actively maintained forks at present, so the proposal here is to put macipgw under the netatalk umbrella and manage it as a module of netatalk proper.

[stblassitude]

I am indeed :-) I haven't done anything with that code in ages, and I don't have any hardware that this could be used with, so I don't really feel it's up to me, but if you want to put the code into netatalk, I would very much love to see that!

I'm happy to answer questions if I can.

I'm not sure I understand why the BSD license of macipgw would be incompatible with the netatalk license, but I'm happy to change the license if necessary (for my own code, can't speak for other authors).

[rdmark]

@stblassitude Thank you for your contribution to the community! I think all three of the current licenses in macipgw are compatible with netatalk's GPLv2, if we retroactively update the UCal BSD-4-clause to BSD-3-clause, as described above.

At the same time, if you're up for it, if you could explicitly dual-license the code you wrote under BSD-2-clause and GPLv2 (a choice of one or the other) it would be even better!

Were there other authors in your original codebase, apart from the code you borrowed from UCal and UMich?

[rdmark]

I have started a PR here https://github.com/Netatalk/netatalk/pull/1543

It builds and runs on Debian locally, and the CI jobs suggest that it also builds on FreeBSD, NetBSD, OpenBSD, and any Linux distro. (But fails to link on DragonflyBSD because of missing BSD tunnel symbols.)

If someone here has used macipgw in the past and has the know-how and means to test it, I'd love to get some feedback!

[NJRoadfan]

@jasonking3's fork still has important improvements that should be integrated. Looks like they should drop in for the most part. One notable fix is changing the DDP listening port to 72, which is the defacto standard. Most clients require this as they have the port hardcoded.

For setup and use, I have come up with a very janky way of running macipgw and the required networking setup as a shellscript run by a systemd unit. See:

https://github.com/NJRoadfan/a2server/blob/currentdev/files/macipgw.service.txt https://github.com/NJRoadfan/a2server/blob/currentdev/files/macipgw-start.sh.txt

[rdmark]

Good call. I’ve ported all of the patches from Jason’s fork that seemed relevant, now.

I also converted Stefan’s troff man page to xml, while documenting the new -u option for running as non-privileged user.

@NJRoadfan theres some mighty impressive scaffolding going on in your shell script there. The network stack and tooling can be quite different between distros. Do you think it’s worth trying to craft a generic version of this for distribution?

[NJRoadfan]

That is my one holdup with macipgw. Its a simple command line tool that handles basic gateway duties and wrapping/unwrapping of packets. The user has to figure out how to connect it to their network. Of course, every network and every OSes' handling of their network stack is different. I already had to rewrite that script once since Linux once again changed firewall software from ipchains to nftables.

Even hardware MacIP gateways were not plug and play and required manual configuration. The one benefit they had is that they supported proxy ARP so you didn't have to resort to subnets (a pain if your router doesn't support RIP) and NATs. It allowed one to specify a block of IPs on their main network as being dedicated MacIP clients.

[rdmark]

The one major improvement area that I can see right now would be support for a macipgw.conf file as an alternative to the CLI options, as suggested by @H296 . This would arguably make it easier to manage through the OS’s init system, since it anllows adjusting the configuration separately from the init script.

Edit: After giving this a thought, I think a config file can be a later improvement. Right now I want to get this stabilized and merged so that we can proceed with preparing for 4.0.0.

[rdmark]

Question for @jasonking3 and @aseering if you are seeing this message: Would you approve of re-licensing your code contributions to macipgw under the GNU GPL v2? The reason is to reduce the sprawl of licenses in this package.

Stefan, the original author, has granted his approval above. But we would love to also reuse your patches, if you have no objections.

Thanks for your consideration. :)

[jasonking3]

@rdmark - I have no problem with that. IIRC, I kept the same license that Stefan had used in order to keep it simple.

[rdmark]

Thank you @jasonking3 – yes it is clearly spelled out in your repo that you did not change the license.

[rdmark]

I have now pushed the GPLv2 relicensing commit to the PR. Thanks again to Stefan and Jason!

The two patches from Adam have been dropped from the changeset for now, just to be supremely mindful of open source manners.

They were these two, one a small arp cache fix for Linux and one an option to drop to running as a non-privileged user after startup.

• https://github.com/jasonking3/macipgw/commit/daa2620c6323ac0b563c5d16ef66f0e9a3749669
• https://github.com/jasonking3/macipgw/commit/5aacd8e498e4fdaa988c73bed295da9f9d28a54f