Hi everyone,
I’m exploring Network Extension options for a use case where I need to log and filter network activity at the packet level. More specifically, I need the ability to detect and potentially block certain TCP behaviors during the handshake.
From everything I’ve tested, NEFilterPacketProvider seems to be the only Network Extension type that operates early enough in the flow.
NEFilterDataProvider appears to receive flows after the TCP handshake is already completed.
It also has some limitations with IP-based filtering (might include hostname instead of IP), inconsistent ICMP behavior, etc.
So I went with NEFilterPacketProvider.
However, I’m running into a major issue: extremely high CPU usage.
To isolate the problem, I stripped my packet handler down to the simplest possible implementation — basically returning .allow for every inbound/outbound packet without any filtering logic. Even with that minimal setup, playing one or two videos in a browser causes the CPU usage of the extension to spike to 20–50%. This seems to be caused purely by the packet volume.
I haven’t found any way to pre-filter packets before the handler is invoked, nor any documented method to significantly optimize packet handling at this stage. It’s possible I’m missing something fundamental.
Questions:
Has anyone else experienced this kind of high CPU usage with NEFilterPacketProvider?
Is there any recommended way to reduce the packet handling overhead or avoid processing every single packet?
Any known best practices or configuration tips?
Thanks in advance!
None of this strikes me as particularly surprising. The packet path is extremely ‘hot’, so adding any work to it is costly. The best thing you can do to improve performance is to avoid the .delay verdict, but your test code is already doing that.
Before I send you off to file a bug about this, I have a couple of things for you to check:
- Make sure you reproduce this on a ‘clean’ machine. I often see weird problems being reported by folks only for us to track it down to some enterprise security setup affecting their main work Mac.
- If you have any additional network debug logging enabled — see the various instructions on our Bug Reporting > Profiles and Logs page — make sure to disable that during your tests.
Usually I test NE stuff on a VM, but in this case you’ll want to run your tests on real hardware. VMs are great, but one place where they differ from real machines is performance.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"