When do we need the new com.apple.developer.networking.multicast entitlement?

Code Signing Entitlements
phirk OP
Created Jul ’20
Replies 15
Boosts 0
Views 4.9k
Participants 6
My team maintains a (proprietary) communication library that allows other developers in our company to write Apps that communicate with devices on the local network. To discover these devices we currently use SSDP, for which we use broadcasting on IPv4 and multicasting on IPv6.

Thus, we expect that we will need the new com.apple.developer.networking.multicast entitlement on iOS 14 (for the short term; we consider migrating to Bonjour later - that requires rewriting the firmware for those devices).

We have installed iOS 14.0 Beta 3 (18A5332f) on an iPhone XS (model A2097) and performed these two tests:

  • Xcode 11.6 (11E708) / iOS 13 (Enterprise) build: we get the local network privacy dialog (with the default reason text) and after that discovery works, as expected

  • Xcode 12.0 beta 3 (12A8169g) / iOS 14 (Debug) build, without the new entitlement: we again get the local network pricacy dialog (with the reason we put in Info.plist) and after that discovery still works, which we did not expect...

Why does that iOS 14 specific build still work without the new entitlement?

How should we test this instead to prepare for iOS 14's Local Network Privacy?

(PS: We requested the entitlement, but we did not get it yet)
Replies  15
Boosts  0
Views  4.9k
Participants  6
DTS Engineer OP
Apple
Aug ’20
I just want to clarify one thing about your report:

Xcode 11.6 (11E708) / iOS 13 (Enterprise) build

Did you mean to say iOS 14 here? I don’t see any way that iOS 13 could be putting up this dialog.

Or perhaps you meant to say “iOS 13 SDK”?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
Engineer OP
Apple
Aug ’20
iOS 13 apps will indeed trigger the user dialog, since they don't require any changes to get user permission.

For your iOS 14 app, not having the entitlement does not cause the dialog to not show up. It also does not in the beta restrict a socket from receiving packets that may come over multicast or broadcast. However, without the entitlement, your app should not be able to send multicast or broadcast UDP packets.

Please confirm if you are able to send packets with the entitlement. You could verify this with a packet capture on your local network, for example.
0
phirk OP
Aug ’20

Or perhaps you meant to say “iOS 13 SDK”?

I meant: "a build with the base SDK of Xcode 11.6 and deployment target iOS 11.0 (iPhone & iPad)".

For your iOS 14 app, not having the entitlement does not cause the dialog to not show up. It also does not in the beta restrict a socket from receiving packets that may come over multicast or broadcast. However, without the entitlement, your app should not be able to send multicast or broadcast UDP packets.

We (still) don't have the entitlement yet, but the dialog does show up and the App does seem to *cast UDP packets (M-SEARCH):

Code Block text
No.	Source				Destination			Protocol	 Length	Info
84.	192.168.1.13	239.255.255.250	SSDP			 148		M-SEARCH * HTTP/1.1
85.	192.168.1.117	192.168.1.13		SSDP			 325		HTTP/1.1 200 OK

(where 192.168.1.13 is the iPhone and 192.168.1.117 is the device)


0
phirk OP
Aug ’20
SSDP still works on iOS 14 Beta 4 (18A5342e) for the Xcode 12 Beta 3 build (without the entitlement).

Will try a Xcode 12 Beta 4 build later (Xcode download is terribly slow).
0
phirk OP
Aug ’20
Same with Xcode 12.0 beta 4 (12A8179i).
0
phirk OP
Aug ’20
Note: above results are for our existing custom SSDP implementation which uses CocoaAsyncSocket.

We're also trying to migrate to NWMulticastGroup for iOS 14+ (short term solution; migrate to Bonjour later), but our test App crashes (EXC_BAD_ACCESS (code=1, address=0x10)):

Code Block 
libnetwork.dylib`__57-[NWConcrete_nw_listener handleInbound:addProtocolInbox:]_block_invoke:
    0x1b02130c8 <+0>:  ldp    x8, x1, [x0, #0x20]
    0x1b02130cc <+4>:  mov    x2, x8
->  0x1b02130d0 <+8>:  ldr    x3, [x2, #0x10]!
    0x1b02130d4 <+12>: mov    x0, x8
    0x1b02130d8 <+16>: braa   x3, x2

Is this because we still don't have received the entitlement?

What do we need to do to get this entitlement?

(Other developers in our company that create App Store Apps using our communication library requested the entitlement at the same time and they all received it for those App Store Apps, but we still did not receive ours for in-house testing).
0
phirk OP
Aug ’20
Update: we did eventually get the entitlement, but using the NWMulticastGroup our test App still crashes as before.
0
Systems Engineer OP
Apple
Aug ’20
Thank you for reporting. If you are using NWMulticastGroup with the expected entitlement on iOS 14 and you are still experiencing a crash, please open a bug report. On your bug report please include any Symbolicated Crash logs and a focused sample project (minus 3rd party libraries) that can be used to reproduce the issue. Once you have opened the bug report please follow up with the Feedback ID here for tracking purposes.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com



0
phirk OP
Aug ’20
Matt, we had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far.

However, SSDP is still failing for us due to an address already being in use, as discussed in this thread.

Would be great if you could give us some assistance there!
0
inturi OP
Sep ’20
Is it mandatory to use NWConnectionGroup to communicate with a group of endpoints on a local network? Or can we continue to use Sockets to send and receive multicast packets? 
If NWConnectionGroup is not mandatory does an App still requires com.apple.developer.networking.multicast restricted entitlement?
0
DTS Engineer OP
Apple
Sep ’20

Is it mandatory to use NWConnectionGroup to communicate with a group
of endpoints on a local network?

No.

Or can we continue to use Sockets to send and receive multicast
packets?

Yes. Indeed, if you have existing BSD Sockets code it makes sense to stick with that. You should re-evaluate that decision once your deployment target hits iOS 14 and you can thus rely on NWConnectionGroup.

IMPORTANT I strongly encourage you to build a prototype that uses NWConnectionGroup. If this API doesn’t meet your needs, it’s important that you discover that sooner rather than later.

If NWConnectionGroup is not mandatory does an App still requires
com.apple.developer.networking.multicast restricted entitlement?

This entitlement will be required for all folks who use multicast or broadcast directly (rather than, say, through Bonjour). Currently this is not enforced for folks using BSD Sockets. We expect that to change at some point in the future, probably during the iOS 14.x software update cycle.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
1
inturi OP
Sep ’20
Just to be clear, even when my deployment target is iOS 14+, I can continue to use BSD Sockets correct? NWConnectionGroup is just a recommendation that developers can consider at their wish correct?

Yes. Indeed, if you have existing BSD Sockets code it makes sense to stick with that. You should re-evaluate that decision once your deployment target hits iOS 14 and you can thus rely on NWConnectionGroup.


0
DTS Engineer OP
Apple
Sep ’20

I can continue to use BSD Sockets correct?

Yes. We’d prefer folks switch over to NWConnectionGroup [1] but there are no plans to ‘break’ BSD Sockets.

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

[1] And you might prefer it too, because BSD Sockets is a horrible API (-:
0
SimonApption OP
Oct ’20
Following up on this, our app (built with the iOS 14 SDK) sends and receives broadcast packets and doesn't appear to need this entitlement. All network communication in our apps is currently working as expected, assuming the Local Network Access permission is granted.

Is this expected behaviour? If so, I'm curious when we would need the entitlement - the request form specifically states that it is for apps that "interact with their local network by sending multicast and broadcast IP packets". We don't use multicast communications though - only ever broadcast or unicast. Is that the key difference?

We're using BSD sockets, rather than the Network framework, since we currently need to support as far back as iOS 10.
0
DTS Engineer OP
Apple
Oct ’20

Is this expected behaviour?

That depends on what you mean by “expected”. In the long term we expect things to be behave as documented:

Your app must have this entitlement to send or receive IP multicast or
broadcast on iOS.

As I mentioned previous this is not currently enforced for BSD Sockets clients. However, I expect that will change and I encourage you to apply for the multicast entitlement if you depend on IP multicasts or broadcasts.

We're using BSD sockets, rather than the Network framework, since we
currently need to support as far back as iOS 10.

Well, Network framework doesn’t currently include broadcast support (NWConnectionGroup is all about multicasts) so BSD Sockets is still your own choice right now.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
0
When do we need the new com.apple.developer.networking.multicast entitlement?
First post date Last post date
 
 
Q