We use the task_vm_info.phys_footprint, as described by Eskimo here and found that it lines up very well with the actual 15MB ceiling imposed by iOS: struct task_vm_info info; mach_msg_type_number_t size = sizeof(info); kern_return_t kerr = task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)&info, &size); if (kerr == KERN_SUCCESS) { vm_size_t used = (unsigned long)info.phys_footprint; // size in bytes return used; }

Overriding -init with a delay for attaching to the PT process unfortunately yields a memory footprint that is virtually identical to attaching within startTunnel (just over 8MB), and the memory graph while in -init is also similar that from startTunnel. Here is a screenshot of the memory graph, since the forum isn't showing the pasted inline image.It looks like all dependencies are initialized at this point, which is what's using the memory. What we'd like to determine is whether we can excise any of these, to lower our memory footprint, such as any unexpected allocations by these dependencies, perhaps implicitly or inadvertently. This doesn't seem really viable to do with the memory graph but Instruments can easily reveal.Is there a possibly earlier point or any other suggestions we can try?

Hi Matt,We are using NETunnelProviderManager: let protocolConfiguration = NETunnelProviderProtocol() protocolConfiguration.serverAddress = "127.0.0.1" protocolConfiguration.providerBundleIdentifier = "com.xyz.mac.vpn.PacketTunnelProvider" manager.protocolConfiguration = protocolConfiguration manager.isEnabled = true manager.localizedDescription = profileName manager.saveToPreferences { (error: Error?) in if let error = error as NSError? { NSLog("Install error: \(error)") completionHandler?(error, false) } else { NSLog("VPN saved") self.loadManager { _ in completionHandler?(nil, true) } } }This creates the VPN in the Network system preferences and has a "Connect" button, which is what we're using to try to start our PT.The providerBundleIdentifier is the same one as in the log messages from nesessionmanager that I provided previously, and also is shown as being registered in the output I provided from pluginkit.

Hi Matt - Is there any other information needed to help figure out this issue, e.g. console output?

Seeing this as well, and with iOS 15 GM. However, we discovered that "no route to host" error is only occurring with sockets, e.g. not with NWTCPConnection. Unfortunately, there are reasons we need to use sockets directly (e.g. setting socket options, binding to the network interface, etc), so this is not a viable solution. Can someone at Apple provide guidance on what we can do about this?

I'm running into another case where it would be good to know if iCloud Private Relay is enabled: It breaks port 80 traffic for my PacketTunnelProvider. There are others also reporting this, e.g. https://developer.apple.com/forums/thread/687630 It would be better to have a fix specifically for that issue, but lacking that, I can at least implement a fallback if there was some way to programmatically detect if Private Relay was enabled.

I inadvertently included some private details in the message above, so I need to delete this and repost it w/o those details. Is that possible?

I inadvertently included some private details in the message above, so I need to delete this and repost it w/o those details. Is that possible?

This is a common problem affecting app using its own NE implementation (instead of using iOS's built-in VPN clients), e.g. commonly seen with VPN/PacketTunnelProviders. https://developer.apple.com/forums/thread/99042 Apple doesn't appear to be interested in fixing this, since they did nothing with the bug reported in that discussion thread. There must be some way to get Apple to do something about this. The battery impact is likely calculated based on the estimated cpu and radio usage for the traffic performed by the NE, so a simple thing for them would be to deduct the "inside" traffic being performed by apps going thru the NE from the "outside" traffic blamed on the NE when calculating battery usage.

@eskimo - I and others with PacketTunnelProvider implementation would benefit from the feedback. Presumably they affect every other vendor. How can we get access to these suggestions, e.g. do we need to file our own bug or ?

@eskimo - Filed bug report FB13425443, so hopefully we can get some guidance on how to address this for our VPN implementation.