Random global network outage triggered by NEFilterDataProvider extension – only reboot helps, reinstall doesn't

I’m presuming that this is on the Mac. If not, lemme know.

it suggested the possibility that the kernel might have marked the extension as untrusted

That’s nonsense.

As to the actual cause, it’s hard to say. I’ve definitely seen similar reports, but I don’t remember the resolution.

As soon as I stop the extension … the network immediately recovers

Does that terminate your sysex process?

If it does, then that’s a strong indicating of an OS-level bug, because something in the OS is holding on to the bad state that causes the problem to come back when your start your filter again.

OTOH, if it doesn’t then it’s possible that the bad state in being stored within your sysex process. In that case — and this is only as an experiment not as an actual workaround — try killing that process. Does that clear the bad state and allow your filter to function again?

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

@DTS Engineer

I’m not quite sure what you mean by the 'sysex process.' I have tried numerous ways to restore the network state without rebooting, including a clean uninstallation of my application—system extensions, the wrapper program, and all related auxiliary tools included—followed by a fresh reinstall.

I’m increasingly convinced this is a system bug. My testing shows it occurs far more frequently in version 15.6 than in 26.2. While the issue still persists in 26.2, the probability has significantly decreased. What I urgently need to know is: Is there a way to forcibly reset the entire network stack to clear out potential 'bad states' without having to restart the machine?

I’m not quite sure what you mean by the 'sysex process.'

OK, lemme clarify.

On macOS, content filters must be packaged as a system extension [1], aka a sysex. A sysex is much like a launchd daemon, in that it can potentially run for the entire boot cycle, that is, start when you boot the Mac and not stop until you shut down [2]. Your Network Extension provider instances are created within that sysex process. So, consider this sequence:

1. You boot your Mac.
2. Your sysex starts.
3. NE instantiates your content file provider within that sysex process.
4. You stop the filter.
5. NE stops the content filter provider.
6. At this point the system may or may not stop your sysex process. But let’s consider what happens if it doesn’t…
7. You start the filter again.
8. NE instantiates your content file provider again, still within the same sysex process.

So, my questions are:

• Are you seeing the sysex process stop at step 6?
• If not, if you force the sysex process to stop at step 6, do you still see the problem after step 8?

You can stop the sysex process in a couple of ways:

• Run the kill tool as root.

• Run launchctl as root:

  % sudo launchctl stop LABEL
  

  where LABEL is the sysex’s job label.

I’m increasingly convinced this is a system bug.

Yeah, I’m not disagreeing with you there, and if the problem persists when you forcibly stop the sysex process then that’ll confirm that. OTOH, if forcibly stopping the sysex process clears the issue, it’s might be an OS issue or it might be an issue in your code [3] and we can explore more debugging options.

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

[1] See TN3134 Network Extension provider deployment.

[2] The exact behaviour here varies based on the type of sysex, for example, Endpoint Security system extensions always start at boot time whereas DriverKit system extensions start when the relevant accessory is attached.

[3] For example, your code might be leaking a resource that the NE infrastructure relies on.