Not likely. If its using something similar to libpcap to inject packets into the host's interface (like VirtualBox's "bridge" interface option), other VMs on the machine can't "see" those packets. Many VMs have provisions to allow this to work properly with TCP/IP, but it doesn't extend to other layer 2 protocols like AppleTalk/DDP.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Netatalk 4.0 - Future-proofing Apple File Sharing
- Thread starter slipperygrey
- Start date
You should be able to connect the two via a tap interface. Looking at jrouter, it can be configured with an alternate MAC address to allow for this.
gitea.drjosh.dev
I would try uncommenting the ethernet_addr: line as a first step. If that doesn't work, create a tap interface, point both netatalk and jrouter to it (still with ethernet_addr: uncommented).
jrouter/jrouter.yaml at main
jrouter - **WIP** Home-grown alternative implementation of Apple Internet Router 3.0
gitea.drjosh.dev
I would try uncommenting the ethernet_addr: line as a first step. If that doesn't work, create a tap interface, point both netatalk and jrouter to it (still with ethernet_addr: uncommented).
Can you please try building with "-Dwith-quota=false" and see if that makes a difference in behavior?
We have had long-running trouble with the built-in libquota on NetBSD. See f.e. https://github.com/Netatalk/netatalk/issues/1900
Home from work. I had already had ethernet_addr uncommented in jrouter.yaml, with a different MAC than my server's ethernet adapter in it. Left that uncommented. Also commented out the ATALKD_OPTIONS for netatalk.You should be able to connect the two via a tap interface. Looking at jrouter, it can be configured with an alternate MAC address to allow for this.
jrouter/jrouter.yaml at main
jrouter - **WIP** Home-grown alternative implementation of Apple Internet Router 3.0
I would try uncommenting the ethernet_addr: line as a first step. If that doesn't work, create a tap interface, point both netatalk and jrouter to it (still with ethernet_addr: uncommented).
Created a tap interface, gave it an up command, set an IP address for it, pointed both jrouter and netatalk to it. When I start jrouter, it seems to be behaving normally and connecting to other AIR servers across the internet. When I start netatalk, it starts as normal, but makes up its own AppleTalk address on the 65280 net, as opposed to the one I've set in jrouter.
Also fun: now my 7300 is hanging on boot when it tries to load the AppleShare extension, so I seem to have really angered the AppleTalk gods hahahaha
Thank you for your help, I'm going to go back to connecting to the afp server over IP instead and consider using a Pi for a separate server in the future.
Thanks, that seems to have fixed the problem! I did a meson setup --reconfigure build with the new options, including "-Dwith-quota=false", and I'm now up and running with 4.2.0dev.
Now this has got me thinking. I've got a jailbroken Airport Extreme running NetBSD (default OS). This seems like an obvious target for running Netatalk 4.2.0, especially since it supports HFS+ volumes via USB and has lots of ethernet ports. Has anyone attempted that yet? Is DDP working in NetBSD?
DDP works in NetBSD if the kernel was configured to include it. The question would be: is that support present in the kernel that Apple configured in the Airport Extreme? You can try running atalkd and if it errors out with "address family not supported" or similar message, then you would need to build a new kernel from source. See https://github.com/Netatalk/netatalk/wiki/Installing-Netatalk-on-NetBSD.
Excellent, I'm glad that it wasn't a new bug. We'll figure out how to implement NetBSD quota properly one of these days. Until then, I'm going to go ahead and hard code the build system to disable quota when building on NetBSD. This kind of insidious fail state is the worst.
I'm still using a couple of the last Airport Extreme APs (2013, 6th generation, 802.11ac) for my home network, they pass AppleTalk just fine, WiFi to/from Ethernet as well as Ethernet off the main unit to Ethernet of the 2nd unit. I even have an older 3rd gen that I sometimes bring up to bridge Ethernet for old Macs to WiFi when I turn my dinning room table into temp work space.
It seems the Apple folks on the Airport AP team didn't get the memo to remove AppleTalk support
Note: I don't use the native Airport Extreme file print server functions, I use a MacIPRpi server for that.
Last edited:
With 4.2.0dev, I have seen at least 2 atalkd crashes in the past 24 hours. Not sure if it's specific to the new version or just due to more zones getting added to GlobalTalk, but according to the core dump, it's crashing here:
Code:
arm64# gdb atalkd /atalkd.core
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000200106ed8 in rtmp_delzonemap ()
(gdb) bt
#0 0x0000000200106ed8 in rtmp_delzonemap ()
#1 0x000000020010781c in rtmp_free ()
#2 0x0000000200104f30 in as_timer ()
#3 <signal handler called>
#4 0x0000fedcb4c08c50 in __select50 () from /usr/lib/libpthread.so.1
#5 0x000000020010b94c in main ()And you're running the bleeding edge code, right?
I might have caused the crash with this commit. Can you try reverting this and see if runs more stably then?
Yes. I reverted just that commit, and atalkd has been up for ~12 hours now without a problem. Will keep an eye on it.
That sounds promising. Would you be able to test this solution? https://github.com/Netatalk/netatalk/pull/1992
It should take care of the initial problem of accessing freed memory, while not introducing memory corruption.
FYI: after reverting the problematic commit, my build was still going strong after 24 hours.That sounds promising. Would you be able to test this solution? https://github.com/Netatalk/netatalk/pull/1992
It should take care of the initial problem of accessing freed memory, while not introducing memory corruption.
I made a local test branch from latest `main` (with all your new Sunday commits), merged `rdmark-atalkd-rtmp-loop` into it, and rebuilt. Looks good so far. Will see if it's still up and running tomorrow!
Are you using zones in your network by any chance? There is a small logic change here, where we break out of the inner while loop when we hit the end of the linked list containing routing information, and goes back to the outer while loop that iterates over zones. I *think* this is the correct logic, but don't have an AppleTalk environment to test in at the moment.
Over 13 hours uptime so far with the latest fix. It seems to be working OK. Yes, there are currently 64 zones visible on the network.
2 of those are my local zones; the rest are coming from Apple Internet Router.
Last edited:
