If there's anything else that you or others would like to know to narrow this down, please do let me know, either here on in the feedback issue FB15368430 Unfortunately, the discussion in that issue stalled because none of the logs that were shared could identify what was causing this issue. We still keep running into this almost every week, so I went ahead and looked into the "xnu" source code that Apple publishes to understand what could cause this problem. Based on what I see in the code, I've updated this issue with the possible cause of this problem. I think this investigation could have been much more simpler if there was some level of logging/debuggability in these socket filters area. Given what I see in the "xnu" related to socket filters, I have now opened an enhancement requesting for some logs at the right places to understand what socket/interface filters are in use on a given system and which one of those is returning a non-zero error during filtering of BSD socket operations. The feedback id for that enhancement is FB19570486. I plan to pursue FB15368430 further but I may have reached the dead end because I don't have access to these socket filters' implementation code. So I hope someone who has access to those might be able to provide some hints/inputs on that feedback issue.

An update on this one - Apple replied to the FB18173706 issue that I had filed and they noted that the issue has been resolved starting Beta3 of macos 26. As part of the fix, the man page of sw_vers continues to remain the same as it was previously but the support for the environment value SYSTEM_VERSION_COMPAT is no longer present in macos 26. i.e. irrespective of what value you set to SYSTEM_VERSION_COMPAT or even if that environment variable is unset, the macos version reported by sw_vers will always be 26. So this behaviour now matches what's noted in the man page for sw_vers.

Hello Quinn, Oh, and you should definitely test on the macOS 15.6 release candidate that we’re currently seeding. It contains at least one important local network privacy fix. Would it be possible to tell a bit more of that fix in 15.6 release candidate? We had numerous issues in 15.x releases related to local network privacy (some of which I've raised in these forums previously). There weren't any solutions we could come up with for these problems because the local network privacy configuration couldn't be automated (on test machines). So we had to temporarily disable several tests that were running into issues local network privacy issues. If there's some specific fix in this area, then I would like to try it out on a separate system and see if it helps us in some manner.

Hello @torarnv, you are right - with XCode 15.4, I just tried: NSOperatingSystemVersion osVer = [[NSProcessInfo processInfo] operatingSystemVersion]; on a macos 26 Beta 4 system and it returned: majorVersion=26 minorVersion=0 patchVersion=0 This wasn't the case in a previous Beta version of macos 26. So it looks like this got addressed in a recent Beta release. I hope this is an intentional change/fix from Apple (and not accidental) so that we can rely on this change in the upcoming 26 release.

Thank you both for the help. I've added a comment to the feedback issue requesting to have it placed in the correct category.

Do you think it would be possible to reconsider how these BSD socket APIs report these local network privacy restrictions with a more appropriate errno? Instead of this and other related BSD socket APIs returning errnos like EHOSTUNREACH, which have a pre-established meaning, would it be possible to instead return EPERM from these APIs? I am considering filing this and the other issue about the user switch causing the launchd daemon, running as root, losing its local network permission as two separate issues through feedback assistant later today. Would that be OK?

Hello Hoffman, While this seemingly is a bug somewhere in the macOS network stack, UDP apps absolutely need to be coded to expect packets to vanish with no errors reported to the sending app. Right, that part about UDP is understood. The reason I opened this thread is to have this behaviour analyzed to be certain that this isn't due to bug(s) in the local network restriction implementation, which is new to 15.x macos. If it indeed is a bug, it would be good to have it addressed to prevent hard to debug issues (like we are currently having).

Hello Quinn, Earlier you posted an excerpt from your launchd property list file, but not the whole thing. I’m specifically curious if: ... If this script, or anything in the chain between it and the Java code that’s calling sendto, is changing the user ID. For example, by calling setuid or setgid or using tools like su or sudo. I had a look at the process launching code involved in this entire hierarchy. So the flow is as follows - there's a launchd daemon process (launched through a plist file in /Library/LaunchDaemons) which acts as a task management "server". Just for additional information, it's a third party framework that's implemented in C++ (so it's not a Java program in itself). That launchd daemon receives regular requests for launching "tasks". You can imagine a task to be a process that this server launches on the same macos host. The task request that comes in to the launchd daemon has the ability to say that the task needs to be run as a specific user. The launchd daemon then creates a new process. If a user is specified, then the newly launched process first identifies the "uid", "gid" and "grouplist" of the chosen user through system calls getuid(), getgid() and getgroups() respectively. The newly launched process then calls the setuid(), setgid() and setgroups() system calls to change the user id of itself. In our setup where we are noticing this issue, the launchd daemon (running as root) launches processes which then have their user changed to a different user. These processes, running as a different user, then ulimately end up launching the java executable which then, as part of the application code, end up calling the sendto() system call. In general, a launchd daemon shouldn’t be troubled by local network privacy. That includes the daemon itself and any processes that it spawns. I’ve seen cases where that’s not the case but, at least so far, those are associated with daemon that change their user ID, either via the UserName property or explicitly. That can cause problems on macOS because macOS maintains a bunch of execution context beyond that standard BSD user and group IDs [1]. So yes, it appears that switching of the user is playing a role here. Having said that, is this a bug in macos? The implementation of local network restrictions appears to have identified the launchd daemon, running as root, as the top level application against which (as per the local network documentation) it is evaluating the permissions. Yet, it appears to be tripped by the user id of the leaf (and intermediate?) processes when making this decision. Would you have some suggestion on how to get past this?

While at it, coming to this point: In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application. I would like to note that this (and one other error message that I'm investigating), I feel, are a bit misleading. Do you think it would be possible to reconsider how these BSD socket APIs report these local network privacy restrictions with a more appropriate errno? Instead of this and other related BSD socket APIs returning errnos like EHOSTUNREACH, which have a pre-established meaning, would it be possible to instead return EPERM from these APIs? man errno states: 1 EPERM Operation not permitted. An attempt was made to perform an operation limited to processes with appropriate privileges or to the owner of a file or other resources. This feels much more closer and accurate to what these local network operation restrictions are about. Of course, returning EPERM errno from these APIs would also mean that the man pages of relevant BSD functions like connect(), sendto() and such would have to be updated to state that this is now one of the possible errno they return. If that can be done, then I think this can reduce the confusion and at the same time more accurately represent the nature of the operation failure.

The C program which has been provided as a reproducer in this thread was hand crafted to demonstrate more easily what the issue is. The real world code which reproduces this in Java program is as trivial as the following: import java.net.*; public class LocalNetworkTest { public static void main(final String[] args) throws Exception { final byte[] hello = "hello".getBytes(); try (final DatagramSocket ds = new DatagramSocket()) { final int arbitraryDestPort = 12345; final InetAddress destAddr = InetAddress.getByName("ff01::1"); final DatagramPacket packet = new DatagramPacket(hello, hello.length, destAddr, arbitraryDestPort); System.out.println("attempting to send a packet to " + destAddr); ds.send(packet); System.out.println("successfully sent packet to " + destAddr); System.out.println("application will now do some unrelated work for a second"); doSomeOtherWork(); // send again System.out.println("application will now again attempt to send a packet to " + destAddr); ds.send(packet); System.out.println("(again) successfully sent packet to " + destAddr); } } private static void doSomeOtherWork() throws Exception { Thread.sleep(1000); } } Save this code to a LocalNetworkTest.java file and then go to the Terminal (i.e. macos Terminal app) and just do: java LocalNetworkTest.java You should see the output as follows attempting to send a packet to /ff01:0:0:0:0:0:0:1 successfully sent packet to /ff01:0:0:0:0:0:0:1 application will now do some unrelated work for a second application will now again attempt to send a packet to /ff01:0:0:0:0:0:0:1 Exception in thread "main" java.net.NoRouteToHostException: No route to host at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method) at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798) at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857) at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178) at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593) at LocalNetworkTest.main(LocalNetworkTest.java:17) Notice how the first attempt gives an impression that the send has succeeded then the second attempt (after a delay of 1 second within that program) ends up with that "no route to host" exception. Like I noted earlier, there are no pop-ups or notifications asking for permission to allow local network access. Plus, this was launched from the Terminal app, yet the local network restrictions seem to be applied which goes against what the documentation here https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy states: macOS automatically allows local network access by: ... Command-line tools run from Terminal ...

Whether that’s a bug or not depends on your context. And speaking of context, what’s the context here? I suspect that this is coming out of a test suite. Is that right? Or do you have real world code that’s running into problems because of this behaviour? The above native C code was hand crafted from a Java program which runs as part of our large testsuite. Although that program is part of a testsuite, the actual program is very trivial and matches what one would expect out of a normal Java real world application. This current thread uses ENETDOWN as an example of demonstrating an issue where the sendto() doesn't report back errors promptly. After I opened this thread, I noticed a variant of this issue where the error starts getting reported on subsequent calls to sendto() if the program adds a small delay between the 2 calls. I explain that in a separate thread here https://developer.apple.com/forums/thread/776630. I will add a Java program to that thread, which demonstrates a real world usage where this current behaviour is problematic. I'm sorry about these 2 duplicate threads, but I only realized later that these 2 issues are just a variation of each other. I think it would be easier to just continue this discussion in that other thread.

Hello Quinn, Earlier you posted an excerpt from your launchd property list file, but not the whole thing. I’m specifically curious if: The launchd property list has a UserName property to run the job as a user other than root. No, the plist file doesn't have a UserName. For reference, here's the complete plist file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>polo-foobar</string> <key>ProgramArguments</key> <array> <string>/opt/marco-foobar/start-marco-foobar.bash</string> </array> <key>WorkingDirectory</key> <string>/cores</string> <key>RunAtLoad</key> <true/> <key>OnDemand</key> <false/> <key>EnvironmentVariables</key> <dict> </dict> <key>StandardErrorPath</key> <string>/var/log/foo-err.log</string> <key>StandardOutPath</key> <string>/var/log/foo-out.log</string> <key>KeepAlive</key> <true/> <key>HardResourceLimits</key> <dict> <key>Core</key> <integer>9223372036854775807</integer> <!-- RLIM_INFINITY --> </dict> <key>SoftResourceLimits</key> <dict> <key>Core</key> <integer>9223372036854775807</integer> <!-- RLIM_INFINITY --> </dict> <key>ProcessType</key> <string>Interactive</string> </dict> </plist> If this script, or anything in the chain between it and the Java code that’s calling sendto, is changing the user ID. For example, by calling setuid or setgid or using tools like su or sudo. I will look into that part and get back with the details. [1] The very old, but still surprisingly relevant, TN2083 Daemons and Agents covers this in much more detail. Yes, that's a very good documentation. I've been reading through it the past few days.

I see that 15.3.2 of macos has been released. So I gave this a try after upgrading to that version and this issue continues to reproduce there too. And no notification/pop-ups either. Any suggestions on how to address this?

7384 is a process launched through launchd with the /opt/marco-foobar/start-marco-foobar.bash bash script file as the executable. When I say launchd, I may not be using the right term here. I think the /opt/marco-foobar/start-marco-foobar.bash bash script gets launched whenever that macos system starts (I will confirm that today). I've confirmed that this process is indeed launched by placing the plist file in the /Library/LaunchDaemons directory. That plist file, as noted in my previous post contains: <key>ProgramArguments</key> <array> <string>/opt/marco-foobar/start-marco-foobar.bash</string> </array> So the 7384 process that has been identified as the root top level app/process is a LaunchDaemon.

Understood, thank you. I'll try to find a way to reproduce this on a system where I have local control.