I'm in the process of converting existing XPC C code (from another developer) to NSXPC Obj-C code. So I can't say and have no idea whether it ever has been seen by the original XPC C code.

On the server side.

As far as I understand, once loaded and user approved, your network extension will be started automatically on the next restart (which was not the case with kernel extensions loaded manually). The issue is actually more with the companion app/process if this is a Mac App Store solution. For the companion app/process to be started at boot time, you would need to use a launchd daemon. And launchd daemons are persona non grata in the MAS AFAIK.

I don't really see "conversion" C issues with packet filter since basically we are just provided with a bytes buffer. I'm more interested by the Filter Packet case. For instance, in Ob-C, we have NEFilterDataProvider which has those entry points: (NEFilterNewFlowVerdict *)handleNewFlow:(NEFilterFlow *)inFlow; (NEFilterDataVerdict *)handleInboundDataFromFlow:(NEFilterFlow *)inFlow readBytesStartOffset:(NSUInteger)offset readBytes:(NSData *)readBytes; From the NEFilterFlow, you, AFAIK, can only get a NWEndpoint. So I'm wondering if there is a "raw" C-equivalent for NEFilterDataProvider.

OK but are there entry points for the Network framework’s C "types" for a filter packet provider or a filter data provider? I see only the Obj-C API in the Network Extension framework and there are no public ways to "convert" a NW Obj-C "type" to a NW "C" type. I'm looking for the ease of Obj-C and, when needed, the speed of C.

Thanks. This looks to fix the issue. Found out that -67061 is defined in CSCommon.h.

AFAIK, NEFilterPacketProvider should allow you to see all the IPPROTO_ you want.

Problem is still there in 10.15.7 and 11.0 beta 9. I thought I could work around this issue by polling the enabled state of the NEFilterManager but it turns out that, if the Network Extension has been removed manually from the Network Pref pane list, when you try to reload the Network Extension, the enabled state is set to YES before the Allow dialog is validated.

It seems that beta 9 solves this problem. At least on one of the 2 Mac platforms. I can't say about the other one.

I hadn't thought that Instruments could be used. Finally found the origin of the issue… in my code (readonly property name was not matching the ivar name). Thanks for the tip.

If only there was a public queue property associated to NEFilterFlow object…

The background process of the Network Extension is still running. The flows are not processed anymore. I can't help thinking that the management of Network Extensions is unreliable in Catalina and Big Sur. For the record, even the Network Preference Pane does not report correctly the changing state of the Network Extension: Make a network extension inactive (+ Apply). => It's correctly displayed as "Not running". Re-enable the network extension from the embedding app. Qui the embedding application since you will never get the notification. Wait. Sometimes, but rarely, the Network Extension will switch back to the "Running" state in the Network Pref Pane. Most of the time, you have to quit System Preferences (1) and then reopen System Preferences for the Network Extension state to be displayed as "Running". [1] switching to another Pref pane and then back to Network is not enough.

Thanks for the answers. On both platforms, attempting to enable a content filter configuration beyond the limit will fail.  Regarding iOS (even though I don't care at all about it), the documentation in the header file says that setting this property "will disable filter configurations of other apps". So this does match what you're writing. To ensure performance on the system and to try and separate filtering conflicts as much as possible. IMHO, this will create technical support nightmares for 3rd party developers.

2 stupid questions: is the handleNewFlowCall made on a concurrent queue? assuming it's not: why not just run the async call on the same queue as the handleNewFlow call? This way, the async block will never run before the return pause() call.

Same here.