Exactly.

Won't that just allow me to get audit_token for my own process? as I'm not able to call task_info for any other process (as I can't get it's task port)

So what might cause the crash, if network extension is not even in the stack trace? Also, we have been seeing a lot of issues when trying to attach to signed processes with Instruments (even when signed for debug), is there a way around it?

Hi Matt, This crash doesn't sound Extension related, and yet it happens only when extension is installed. Also - I am struggling with attaching instruments to Network Extension, As I keep getting: Unable to acquire required task port I am compiling the extension in debug mode with get-task-allow entitlement, and disabled hardened-runtime. It is signed with development provisioning profile. is there anything else I am missing?

Sorry, I forgot to mention that part - macOS

Thought that too, but I do not see any new flow when calling ping. Same as with raw sockets. EDIT: saw you wrote NEFilterPacketProvider. It is not possible using DataProvider? Also, in what way can I get packet type in PacketProvider?

Thanks! That will solve our issues with that. Is there a way to extract source app for a packet with packet filter? I see there is a context, but I'm not sure what and how we can extract from it.

Hi, Those crashes still occur, repeatedly. It does not matter if we reduce functionality for FilterDataProvider, or even not collect statistics for UserEventAgent (in this case we receive crashes on remoted daemon, which causes network to halt, and in a few minutes the machine to crash). With the attached spindump from the moment of the crash, it seems very likely this is an OS issue (kernel deadlock). Is this a known issue? Is there a workaround we can manage? We have several hundreds of machines with Network Extension installed, that repeatedly crash. Attached is a spindump from the moment of the crash: spindump - https://developer.apple.com/forums/content/attachment/bb57fa48-5619-4b73-bc96-b7300c6984f1 Panic log: panic.log - https://developer.apple.com/forums/content/attachment/067ff188-1512-449a-9a0c-ce0949704080 Just before remoted crashed I can see in system.log: Nov 26 15:19:21 TLVMAC62Y1JGH6 Console[37400]: BUG in libdispatch client: vnode, monitored resource vanished before the source cancel handler was invoked { 0x600000fc2c00[source], ident: 6 / 0x6, handler: 0x7fff6f54dc0c } Also opened ticket: FB8906238, But solution I was given (to upgrade to 11.1 beta version) is of course not a possible solution for customers.

Hi, We are seeing the same issue. It seems like ARC is not closing previous mach service before the upgrade.

Since I did not receive any response, Created also bug report: FB8966904

Hi Eskimo, It's been a year now since this question was asked, and caching mechanism is still undocumented. Is there a plan to add documentation to it anytime soon?

Hi, Following on that, does anyone know if there is a workaround for that? If not, I'll file a relevant bug report, as Quinn suggested.

Hi Matt, I have seen this is a common issue, experienced by many (by the number of threads on this forum). Opened FB9076102.

Hi Matt, Is there an update on this issue? We have filed a bug report FB8922584

Providers are meant to provide network data collection (statistics for existing connections), in addition to some firewall capabilities - network isolation for an endpoint, connection dropping etc. Both providers are needed since DataProvider does not supply protocols other than TCP/UDP. This means if we want to achieve complete network isolation for an endpoint, or firewall capabilities for ICMP for example, we must use PacketFilter as well. Usually there isn't any network effect to our usage - Just in the cases I have mentioned above. In both cases PacketFilter is actually configured as pass-through, without any action performed.