NEPacketTunnelProvider died unexpectedly, no crash dump

Question

mike.ly OP

Created Aug ’17

Replies 20

Boosts 0

Views 9.9k

Participants 12

Hello,

I'm trying to debug an intermittent crash in my NEPacketTunnelProvider. Basically, it will sometimes crash about a minute after establishing a connection. If it survives the first couple minutes, it will work fine for the duration of the connection.

My main problem is that there doesn't appear to be any crash dump created. My provider just stops logging, and I see the following logged in the Console:

neagent: extension connection was interrupted
neagent: Extension <my extension ID> died unexpectedly
nesessionmanager: NESMVPNSession[<uuid>]: status changed to disconnecting

The crash happens only on macOS; iOS is fine.

A few things I've tried:

Checked for a crash dump in ~/Library/Logs/DiagnosticReports and /Library/Logs/DiagnosticReports; found nothing related to my provider.
Attached the Xcode debugger. I can never get it to crash with the debugger attached (of course 😝).
Monitored memory usage in Xcode. It's typically around 6.7MB, but can drift up close to 8MB during heavy traffic. I believe this is acceptable?
Added an uncaught exception handler via NSSetUncaughtExceptionHandler. But my handler never gets called; I suspect this isn't supported for extensions?
Followed instructions for Crash Logs and VPN Logging.

Has anybody run into an issue like this? Is there some other way to gather info that I'm missing?

Thanks,

Mike

Boost

Answer 1

DTS Engineer OP

Apple

May ’20

If you need any information I'll be glad to provide it.

This is the first time I’ve seen this reported against the built-in VPN transports, although that doesn’t surprise me given the common underlying infrastructure. However, it is a new wrinkle and that definitely makes it worthwhile for you to file a new bug about it.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

jaroslavqwerty OP

May ’20

OK, I've filled a report: FB7716038.

Hope this will be fixed soon, because all the VPN clients that are using native IKEv2 implementation suffer from this issue.

0

Answer 3

auryisaghost OP

Jul ’20

I also encountered this bug while creating a transparent proxy (NEAppProxyProvider in extension, NETransparentProxyManager in host app). Although the solution provided by zx2c4 works to stop the proxy from crashing 15-20 seconds after it starts, it leads to another problem: when the proxy is disconnected gracefully (e.g. user clicks "Disconnect" in System Preferences), the proxy will hang on "Disconnecting" for about 5 seconds before finally exiting.

I don't know what exactly causes this "Disconnecting" problem, but my guess is that calling exit(0) immediately after completionHandler() in stopProxy does not give sufficient time for the proxy to communicate its successful close to the remote network service manager before the proxy exits. Therefore, the network service manager just waits a certain amount of time before assuming the proxy crashed and moving it to the "Not Connected" state.

My solution is to call exit(0) as suggested by zx2c4, but immediately before that, sleep for half a second with Darwin.usleep(500000). Of course, that adds a ~0.5 second delay on exit, but it's much better than ~5 seconds. I'm aware this is even more filthy than the already self-described "filthy hack" by zx2c4, but... it seems to work.

So the final code should look something like:

Code Block override func stopProxy(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) {
	/* ... shutdown work... */
	completionHandler()
	#if os(macOS)
	/* Workaround for apple bug 32073323. */
	Darwin.usleep(500000)
	exit(0)
	#endif
}

0

Answer 4

DTS Engineer OP

Apple

Jan ’22

This workaround is also needed for Network System Extension?

I haven’t tested it but, based on my understanding of how NE uses the underlying system support for app and system extensions, I suspect that the workaround isn’t necessary for an NE sysex. However, that’s just a guess. You should suck it and see.

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

1

Answer 5

callmepali OP

Apr ’24

Once in a while we get back to this thread and I would like to report that we are not able to reproduce this issue anymore (will update this post if things change).

We use NEPacketTunnelProvider
All our testing was done on macOS 14

Anyone else experienced improvements or are we just lucky in our testing so far?

0