Local network access disabled after macOS restart

My application needs local network access.

By “application”, do you mean something that’s packaged as a .app that the user launches in the Finder? Or are you using that term in a more generic sense?

If this is an app, does it ship on the Mac App Store? Or do you distribute your product independently?

Finally, have you tried replicating this in a VM? These privileges are commonly mixed up on development machines. If you encounter something weird, it’s good to verify it on a VM that’s never seen your app before.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for your prompt reply.

My application is packaged as a .app package. It is distributed independently, not on the App Store.

I have tried two other apps (.app packages) that do similar things to my app. One is distributed via the App Store and works immediately after a macOS restart. The other is distributed independently and has the same issue as my app after a macOS restart.

I am testing by deleting my test volume, then creating a new empty test volume and installing Sequoia from scratch in that volume. This is simpler for me than creating a VM. Following a hint in TN3179, I have also tried creating a new user account to get a "clean sheet" of local network privacy settings and I see exactly the same issue when starting my app from this new user account.

I have tried running the Console app to see what is going on when the working app starts and when the failing app starts. The output from Console shows that the working app is populating a local network privacy cache when it starts, with messages like the following:

default 11:14:35.343586+0000    nesessionmanager    NESMPathControllerSession[com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7:A0036093-7F67-4D6A-AB13-F90153F11724]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules
default 11:14:35.343694+0000    nesessionmanager    Sending a message to populate the cache with UUIDs from configuration A0036093-7F67-4D6A-AB13-F90153F11724
default 11:14:35.345021+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with UUIDs for 8 app rules
default 11:14:35.361911+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with 1 UUID(s) for uk.co.linn.linn
default 11:14:35.361993+0000    nehelper    com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Saving the cache
default 11:14:35.473344+0000    nesessionmanager    UUID cache miss for com.minimserver.server
default 11:14:35.485558+0000    nehelper    Caching 2 UUID(s) for com.minimserver.server
default 11:14:35.487837+0000    nesessionmanager    UUID: Found for com.minimserver.server: (
    "D4B6F942-5D28-3D52-B279-C5766B3B0F70",
    "6CA3C8E4-0DBD-3B47-BD57-70CE30DB0547"
)

The app uk.co.linn.linn is the app that works immediately after a macOS restart and the app com.minimserver.server is my app that does not work immediately after a macOS restart. After this cache population has happened, all apps in the Local Network section are working normally.

Thanks for all the extra info. I’d like to try replicating this here in my office and there’s one critical piece of extra info I need: In the tests you’re running, is your app triggering the local network request via network traffic or via DNS?

That is, is the first local network operation you perform a DNS operation, like a Bonjour browse? Or does it immediate generate traffic on the wire, via a TCP connection or a UDP datagram?

Oh, if it’s a UDP datagram, is that a unicast, broadcast, or multicast?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks very much for all your help with this.

My app is a UPnP server. It creates a multicast socket that joins multicast group 239.255.255.250, which sends an IGMPv2 Membership Report message to the multicast group address 239.255.255.250. This is the first message sent to the local network. After this, the app sends an SSDP NOTIFY message to the multicast group 239.255.255.250 and waits for UDP unicast responses from other UPnP devices. There are no DNS messages sent.

When local network access is disabled, the IGMPv2 Membership Report message is sent (confirmed by using Wireshark) but the NOTIFY message is blocked.

There is another variation on this (UPnP client mode) where an SSDP M-SEARCH message is sent after joining the multicast group instead of sending a NOTIFY message. Again, the IGMPv2 Membership Report message is sent but the M-SEARCH message is blocked.

There is another case where the app accesses a remote internet server before joining the multicast group as described in my previous post. In this other case, a DNS request is sent via the gateway router. I have tried both cases (no DNS request and gateway router DNS request) and the problem occurs in both these cases.