PacketTunnelProvider Extension terminated due to memory limit

Hello, We have filtering logic that is being loaded into PacketTunnelProvider network extension for processing web traffic. The issue we are facing is the 50MB cap is being hit after browsing a few websites and the OS terminates the PacketTunnelProvider. What would be the best way to tackle this problem? A few ideas come to mind and would appreciate any support on them:

  • using IPC (Inter Process Communication) to move the filtering logic back to the main app (if this is possible)
  • we could move the filtering in Filter Control Provider however the limitation on there is that we cannot perform HTTP response modification which is imperative for the workings of the filtering.

We have same solution working fine on Android and app is using about 270MB in worst case (however in Android there is no limit to network extension as the VPN provider runs inside the app)

The project target market is in excess of 50,000 devices

We would appreciate any support on the matter.

Answered by DTS Engineer in 803534022

I presume we’re talking about iOS here.

using IPC (Inter Process Communication) to move the filtering logic back to the main app (if this is possible)

That’s not possible. Your provider’s container app is almost certainly not running, and there’s no way to force it to run. And even if it were running, the tight sandbox applied to the filter data provider means it can’t do IPC to the container app.

we could move the filtering in Filter Control Provider

I’m not sure how that helps. The filter control provider has a similar memory limit.

The only good path forward here is to reduce your memory use. How you do that depends on the structure of your product. However, I have a few general hints:

  • Instruments is a great way to look at your memory usage. Instruments are NE providers don’t always play well together. I generally deal with that by extracting the core logic of provider out into unit tests, which are much easier to work with. See Debugging a Network Extension Provider for more on that.

  • Remember that your filter data provider is largely read-only. It relies on rules being supplied to it by either your container app or your filter content provider. It’s can’t modify those rules, so you can structure the rules to optimise the memory use in the filter data provider. For example, you might be the rules in a database that supports memory efficient realisation of your model objects. Or you might put the rules in a serialised format that you the filter data provider can work with directly, and then have it memory map it.

Share and Enjoy

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

I presume we’re talking about iOS here.

using IPC (Inter Process Communication) to move the filtering logic back to the main app (if this is possible)

That’s not possible. Your provider’s container app is almost certainly not running, and there’s no way to force it to run. And even if it were running, the tight sandbox applied to the filter data provider means it can’t do IPC to the container app.

we could move the filtering in Filter Control Provider

I’m not sure how that helps. The filter control provider has a similar memory limit.

The only good path forward here is to reduce your memory use. How you do that depends on the structure of your product. However, I have a few general hints:

  • Instruments is a great way to look at your memory usage. Instruments are NE providers don’t always play well together. I generally deal with that by extracting the core logic of provider out into unit tests, which are much easier to work with. See Debugging a Network Extension Provider for more on that.

  • Remember that your filter data provider is largely read-only. It relies on rules being supplied to it by either your container app or your filter content provider. It’s can’t modify those rules, so you can structure the rules to optimise the memory use in the filter data provider. For example, you might be the rules in a database that supports memory efficient realisation of your model objects. Or you might put the rules in a serialised format that you the filter data provider can work with directly, and then have it memory map it.

Share and Enjoy

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

I just re-read your question and realised that I missed something critical: You’re currently building a packet tunnel provider. That doesn’t really change my answer — most notably, the blocker for IPC is that not the IPC, but rather than your container app is not running — but it does like to this…

I want to call your attention to TN3120 Expected use cases for Network Extension packet tunnel providers. DTS doesn’t support folks implementing a content filter using a packet tunnel provider. In our experience it does not end well.

Share and Enjoy

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

PacketTunnelProvider Extension terminated due to memory limit
 
 
Q