Post not yet marked as solved
Are you running into a local network privacy prompt or TLS failure? For example, when using XCUITests does a local network privacy prompt show up for connecting to a local network device?
Post not yet marked as solved
I'm glad to hear that everything is working, but quick point about:
it seems that the com.apple.developer.networking.multicast entitlement is not needed in this case.
You will need the multicast entitlement, i.e., com.apple.developer.networking.multicast to use the API for NWMulticastGroup on iOS. If you test this with a new iOS device that has never run your app before, I suspect that the NWMulticastGroup API would not work without this entitlement. Just wanted to put that out there for anyone following along.
Post not yet marked as solved
Can anyone think of anything I have missed which would cause Xcode to continue packaging it as an appex rather than a sysex?
Are you signing your container app with this entitlement:
<key>com.apple.developer.system-extension.install</key>
<true/>
Are you using the OSSystemExtensionRequest API to install your Network System Extension?
Post not yet marked as solved
Thanks Matt for reminding me about Developer Mode; that indeed was the impediment to debugging locally. (It's been over a year since I've had occasion to work on this extension, and was doing so on another machine, so I'd forgotten all about that necessity.) Having done so, the call succeeds and ES seems to work.
No problem at all, glad that's working.
Regarding:
(I've also observed some anomalous behaviours of System Settings; e.g. it will sometimes put up an empty alert after authorizing the extension.)
If you continue to see odd behaviors like this please open a bug report with screen shots and a sysdiagnose.
Is there any limitation for Apps installed via Test Flight with Network Extensions?
For iOS a Content Filter Provider Network Extension, such as NEFilterDataProvider can only be used on a supervised device unless used in-conjunction with FamilyControls / Screen Time APIs. Please see the overview section for Content Filter Providers on iOS. I suspect that is why you are not seeing it working in TestFlight. Check the logs when you try to enable the Content Filter APIs in this environment.
Post not yet marked as solved
Is there a more bulletproof, built-in way to correlate the resolved DNS names to the vast majority of the network traffic?
There is not. When working with other system traffic IPs, the hostnames will need to be derived by hand as you pointed out because only a small subset of the URLs on the system are available.
Post not yet marked as solved
There isn't a proxy setting that would allow you to configure response types in CFNetwork, just to configure and setup the proxy itself. I would recommend talking to the server side folks about the usage of chunked vs fixed length responses in the Content Length header as this should be something that you can work with them on.
Post not yet marked as solved
Note: All our Root and intermediate CA certificates are custom certificates and not available outside.
This is the key point. Thank you for adding this bit of information so that it is known that these certificates DO NOT exist in the current macOS trust store.
Regarding:
But how is trust evaluation successful when one of intermediate CA certificate is missing? Is macOS caching the intermediate CA certificates we have provided to SecTrustSetAnchorCertificates some other time and using it the next time when it is missing one of intermediate CA certificates since the documentation says intermediate CA certificates are looked up in different location including
The first place I would check is the Keychain to make sure that you did not install the Intermediates previously on a test or through some MDM function. If these Intermediates are in the Keychain already then that would cause what you are seeing.
Post not yet marked as solved
Do I still have to add each service into info.plist although I have added multicast entitlement?
If you are browsing for a Bonjour service with either NWBrowser or NetServiceBrowser, then yes, you will still need to declare this in the Info.plist.
The Multicast Entitlement is also needed here because interacting with this particular service utilizes multicast under the hood.
Post not yet marked as solved
When I attempt to do so (build & run from Xcode), the system throws an alert “App containing System Extension to be activated must be in /Applications folder” when attempting to activate the extension. Obviously that would be expected in a production build, but this happens in debug when building with development provisioning on Ventura; the same does not occur on Monterey, where the development build will load and activate from its build location
My recourse in the interim has been to drag the build product into /Applications, launch manually, and then attach the debugger.
You'll need Developer Mode on to build, run, and test a System Extension from Xcode in any directory. I would keep adding the bundle to the /Applications directory as this is what your users will do.
Regarding:
Despite this, even after allowing the extension in the “Privacy & Security” panel of System Settings, and ensuring that both entries are enabled under Full Disk Access (yes, there are two, identically named; one with the app icon, and one with a lego brick extension icon), the call to es_new_client() still fails.
If you have the entitlement configured correctly, and you can test this from the /Applications directory on a fresh machine, and this still fails then I would open a bug report with a sysdiagnose.
Post not yet marked as solved
The documentation related to network extensions (in this case NEFilterDataProvider) in apple docs said explicitly that Mac catalyst is available.
@eskimo @meaton please let me know if there's a bug with it.
This is not a bug. This is intentional to let you know that creating a provider for Mac Catalyst does not work as you would expect because you need to create a Network System Extension, and not a Network App Extension on macOS.
The symbols are in the documentation because they are available in Mac Catalyst. It would be worth a bug report to update the documentation for this.
If you want to target both plaforms, one course of action would be to add two targets, one for iOS and one for macOS to your Xcode project. The macOS route would instantiate a Network System Extension and then the iOS route would instantiate a Network App Extension. Then, there would be a group in the project that contains all of the shared code for your business needs that can be added to both targets. This is not the greatest solution because you end up maintaining and deploying two targets instead of one, but it should let you get off the ground in the immediate future.
Post not yet marked as solved
Thank you for sharing this information on how the container app is signed.
What is going on here:
Executable=/Applications/SampleGUI.app/Contents/Applications/SampleSysExtHost.app/Contents/MacOS/SampleSysExtHost
I would expect that the container app bundle structure look like the following:
SampleGUI.app
Contents/
MacOS/
SampleGUI
_CodeSignature/
embedded.provisionprofile
Info.plist
Library/
SystemExtensions/
my.sysext.bundleid.systemextension
PkgInfo
Resources/
Having helper apps in other places inside your macOS bundle outside of the designated locations will cause syspolicyd to evaluate the execution of your app / extension as code that is bundled incorrectly. See the link provided the proper location on Helper apps.
Post not yet marked as solved
To be abundantly clear: if we want to enable owners of our device to stream to it, do we need to persuade the developer of every app they want to use it with need to embed our extension, or can we ship it in our app to provide the streaming target system wide? Obviously the demo project would answer that if I could get it to work…
The short answer is that you can provide one app / extension that allows the discovery of local devices on the network that is providing a Bonjour service endpoint. Once that service is discovered, it will be up to your app / extension to delegate how the AV content is communicated over the local network connection.
Post not yet marked as solved
In what context are you sending these packets over the network on both the iPhone and iPad? Is it in the foreground, or is it in some type of background session on the device?
Post not yet marked as solved
Interesting. I just ran a test using rvictl with macOS 12.4 on Xcode 13.4 with iOS 15.2 associated with a Wi-Fi network was able to see ARP packets...
ARP, Reply xx.***.***.1 is-at xx:xx:xx:xx:xx:xx, length 46
Now, when I ran the capture I used a macOS application to send these ARP packets over the network so you should be able to see them?
If you continue to have issues here I would open up a bug report.
