It appears that T-Mobile is using "Dual Stack Lite", as described in RFC 6333, which explains why the IP address for LTE is always 192.0.0.1. Is there any information available on whether this is supported in NEPacketTunnelProvider?

Hi Matt, I will open a DTS incident. We send all packets, UDP or TCP as datagrams, so in a UDP wrapper. We also send UDP packets that are our internal control/status messages. Also, as far as parsing packets, this failure occurs before attempting to parse/forward any packets - we never get to the .ready state or .isViable. The only thing I can think of is the 192.0.0.1 address

Hi Quinn - I am trying to implement 'disconnectOnSleep' = false so that I can control the quiesce / resume of the tunnel. But sleep and wake are not being called. I have removed the VPN profile and restarted, which should have taken the new setting: // In the container code proto.serverAddress = "104.196.39.114" proto.disconnectOnSleep = false // In the tunnel code public override func wake() { log.info("Waking Up....") sleeping = false } public override func sleep(completionHandler: @escaping () -> Void) { log.info("Preparing to sleep...") sleeping = true completionHandler() }

Ah, just found your post about disconnecting/restarting and not having xcode connected, now I am getting them...

Hi Quinn: Let's say that when wake() is called, I am temporarily unable to resume the tunnel, for whatever reason. If I call cancelTunnel(), can I then later try to call startTunnel from within my provider? Or is cancelTunnel() the end of the line and the user has to restart from the container app? What is the proper way (if there is one) to quiesce the tunnel in such a way that the tunnel is no longer capturing traffic in either direction, in other words the device can route traffic normally outside the tunnel until I re-setup my links, set the downstream read handlers, and start the upstream traffic pump?