System Network Extension and Sleep

I don’t have any good answers for you for scenario 1.

Regarding scenario 2:

On sleep, I'm disconnecting the tunnel. But sometimes, on wake(), all my network calls fail. Are the interfaces still down?

Probably. Your wake code is racing with all the other wake code on the system, including the code that’s bringing up the network interfaces.

My generally recommendation here is that you use a modern networking API, like Network framework, that supports waiting for connectivity. In that case I’d expect to see your NWConnection enter the .waiting(…) state and then, once the necessary infrastructure is up, connect and then enter the .ready state.

So:

• Are you using NWConnection?

• If so, it is working as I described above? If not, how is it failing?

• If if you’re not using NWConnection, can you try it? I’m not suggesting that you rewrite all the networking code (well, not yet :-) but instead just try starting a parallel NWConnection and see how it behaves.

Is it possible that the OS would call sleep() and then quickly call wake()?

Yes. In sleep/wake scenarios pretty much anything is possible (-:

Is it possible that after sleep(), the OS would call the startTunnelWithOptions() function?

I wouldn’t expect to see that. NE should only start your tunnel if it’s stopped, and it doesn’t know that your tunnel is stopped until you tell it that.

Is it possible to restart the extension from a clean state right from the wake() function?

Not really.

Well, the closest thing to this is to set disconnectOnSleep, but that brings you back to scenario 1.

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

Thanks eskimo!

if you’re not using NWConnection, can you try it?

Sure. I'm not working with NWConnection, and I'll try it soon.

A related question to the above: I'll add the code to the wake() function.

1. I assume I should wait for '.ready' and only then to start establishing the tunnel. But what if the check will stuck in '.waiting'?
2. Should I, at any point in the wake() function, set the 'reasserting' variable?

I assume I should wait for .ready and only then to start establishing the tunnel.

That depends on what you mean by “tunnel”. From iOS’s perspective, the tunnel is ‘up’ until you explicitly stop it. From your perspective, the tunnel is represented by the network connection. It can be down while the tunnel is up.

But what if the check will stuck in .waiting?

That’s the same as if you were establishing the tunnel in the first place. You can choose to wait forever or apply your own timeout.

Should I, at any point in the wake() function, set the reasserting variable?

Yes. See here.

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

If if you’re not using NWConnection, can you try it? I’m not suggesting that you rewrite all the networking code (well, not yet :-) but instead just try starting a parallel NWConnection and see how it behaves.

For that, I'll have to add 'import Network' at the Packet Tunnel Provider. Then, my code to monitor path-change won't compile:

let oldPathOpt = change?[.oldKey] as? NWPath //'NWPath' is ambiguous for type lookup in this context

I also tried this one

let oldPathOpt = change?[.oldKey] as? NetworkExtension.NWPath //Ambiguous type name 'NWPath' in module 'NetworkExtension'

So, instead of NWConnection, would it be okay to use something like let configuration = URLSessionConfiguration.ephemeral configuration.waitsForConnectivity = true let session = URLSession(configuration: configuration) ?

I know you said to ignore this, but I want to post some info just in case other folks bump into it.

For historical reasons, Network framework and Network Extension framework export different types with the same name. The list of such types includes NWPath and NWEndpoint. Historically:

• This caused ambiguous type problems if you imported both frameworks.

• The workaround was to fully qualify the name. So, instead of NWEndpoint, you would use Network.NWEndpoint or NetworkExtension.NWEndpoint.

• If that caused too much grief, you could deploy some type aliases:

### NWHelper.swift ###

import Network

typealias NWEndpoint = Network.NWEndpoint

### NEHelper.swift ###

import NetworkExtension

typealias NEEndpoint = NetworkExtension.NWEndpoint

### main.swift ###

func test(endpointNW: NWEndpoint, endpointNE: NEEndpoint) {
}

This has changed in Xcode 16. If you’re in the Swift 5 language mode, things behave as they did previously. However, in the Swift 6 language mode the Network Extension types have been made Swift private [1]. That is, the type is now NetworkExtension.__NWEndpoint. So, rather than the above you can just write:

### main.swift ###

import Network
import NetworkExtension

func test(endpointNW: NWEndpoint, endpointNE: __NWEndpoint) {
}

This is part of our general effort to move folks off the In-Provider Networking APIs.

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

[1] This is not “private” in the sense the App Review sense. Rather, the type has been renamed at the compiler level only. If you use NetworkExtension.__NWEndpoint in your Swift code, at the ABI level your app will continue to reference the public NWEndpoint endpoint class exported by the Network Extension framework.