I’m struggling to receive udp multicast messages in a program I’ve written, when compiled for mac. I’m sure it used to work, so I’m wondering if this is a recent change in Mac OS Sequoia. The code works fine on a PC and even in windows running from Parallels on the same mac.
When I run the code in OSX, I can see the join request to the multicast has happened as all the packets show up in Wireshark and stop when I quit the app. However the app never receives any data. The app is listed in the Security and Privacy page under the Local Network permissions page.
In the mac build only, I have to send some kind of message (even just an empty write to the multicast group) before I receive any data at all. This is not needed in the Windows build. This happens in Sonoma too.
However in Sequoia, I’m having to put a delay of 3secs after opening the app before I attempt to write to the group or I get an error 65 ‘no route to host’.
This is fast becoming the most irritating sequoia ‘feature’. I’ve written a bunch of different apps. Signed/Hardened/Sandboxed with entitlements and the reason for network access. All have been notarised by Apple. Occssioanlly the app launches and receives its first packet over the network and the privacy permissions box appears, but more often not. So the install works on some macs but not others. (all running same version of sequoia)
There doesn’t seem to be a pattern…
One app subscribes to a multicast address. Wireshark can even see the packets arrivng when the app is running, but for some reason the OS is failing or refusing to pass on the packets to the application. When I quit the app, the packects are no longer seen in wireshark, proving that at least the app is able to make subscribe and leave requests…
Is there a way to manually force the permissions pop up to activate???
Any help to this incredibly annoying feature gratefully received… the windows build works just fine!
@Richard_Burford I’m using multicast UDP just fine in my own production Sequoia app (non-MAS). Works fine for my customers too. If you have iOS in the mix, you’ll definitely need the entitlement though as IIRC things were a bit sketch until that happened (e.g. it would haphazardly work in development but not work at all in production). If it helps, see the findings I shared here:
Otherwise, on the macOS side of things, I don’t think I had to do anything special other than accept the “Do you want to allow XYZ to access your local network?” dialog.
In my experience this should reappear if you delete all copies of your app that uses the same bundle ID on your Mac. Otherwise you can theoretically try and zap the permissions with tccutil from the Terminal, but the last time I tried under Sequoia I couldn’t get it to work (but I’ve used in many years ago just fine). Of course you can also try and fiddle with:
System Settings » Privacy & Security » Local Network » Switch for your app
Note that if you have multiple versions of your app on disk, you’ll have multiple listings. In this scenario, I couldn’t get the switches to work properly on my own system. At the time I was testing things, I think I was able to get the dialog to reappear by simply deleting the debug version of the app and recompiling from scratch.
I found, having the privacy window open and toggling the setting for my app, whilst it was building for a debug run, occasionally the program would run without the error 65 (no route to host). Now I’ve put in a connection delay of 10 seconds if the build is a debug and this seems to work consistently without having to fiddle with the privacy settings…
Perhaps the OS is getting confused between ‘debug’, ‘built’ and ‘built + signed’ versions of my app. And has to check everytime I build a new version? My privacy table for local lan is full of multiple copies of the same app. I’ve not changed the bundle id at any point.
Error 65 happens when the port or address + port is already in use.
MacOS happens to really use alot of ports, for sharing over network, monitoring etc etc.
The MBS Plugins UDPSocketMBS and RawSocketMBS have ReusePort and ReusaAddress setting those (or one of) to true, gives you the ability to close, disconnect, reopen etc and still use the port/address (and combination).