Starting VPN tunnel when no network available

A call to NETunnelProviderManager -startVPNTunnelWithOptions:andReturnError: when in airplane mode or all interfaces are disabled will return without an error, but the tunnel isn't started. In the console it's clear what the problem is:


default14:39:25.852701 -0700nesessionmanager-[NESMSession handleCommand:fr:393 NESMVPNSession[...]: Received a start command from appname[512]
default14:39:25.865293 -0700nesessionmanager-[NESMSession setStatus:]:755 NESMVPNSession[...]: status changed to connecting
error14:39:25.867015 -0700nesessionmanager-[NESMSession handleNetworkPre:638 NESMVPNSession[...]: No network available
default14:39:25.870846 -0700nesessionmanager-[NESMSession setStatus:]:755 NESMVPNSession[...]: status changed to disconnecting
default14:39:25.876285 -0700nesessionmanager-[NESMSession setStatus:]:753 NESMVPNSession[...]: status changed to disconnected, last stop reason No network available


Is there a way to programmatically get hold of this error so I can let the user know? Currently we're doing preflight checks to try to avoid this situation, but there's the occasional corner case where this gets through, and we don't have a way to detect it. I'm not sure how easy it is for Apple to propagate errors back from NESMSession to NEVPNManager.


thanks,

Eric

Replies

Is there a way to programmatically get hold of this error so I can let the user know?

I don’t think so. The error coming back from

-startTunnelWithOptions:andReturnError:
reflects an initial check of the request to start the VPN. Once that request gets beyond a certain point the completion handler is called with
nil
and failures are reflected by the
status
property. It would be nice if there was an associated ‘last error’ value, but there isn’t.

It seems like a perfectly valid enhancement request though; 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"

Thanks Quinn. I submitted RADAR 43889791 and suggested a couple of ideas...


- Anytime the OS decides to not start the extension propagate the error back to -startVPNTunnelWithOptions, or provide a method for us to get the last error. This could also be done with a tunnel status callback if that's most appropriate.


- Go ahead and start the extension and let us determine if we have a path to the server. We already handle periods of no connectivity after we're started, and it'd improve out users' experience if they didn't have to come back to our app after turning off airplane mode.


Eric

Hi , I am also facing this problem, please let me know is there any plan of this feature coming in latest updates ?

@vko4. See my response to your question on a different thread here.. Note that this falls inline with what Quinn is also recommending.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com