We have a PacketTunnel solution that uses two UDP datagram channels, one for LTE and one for Wi-Fi. When setting up these channels, we have no issues when the provider is Verizon, but when using T-Mobile, the LTE NWUdpSession goes from .preparing to .waiting to .preparing to .failed. For Wi-Fi or LTE with Verizon, we get .preparing to .prepared to .ready Is there a known issue here or is there something for me to check?

Once NEPacketTunnelProvider is up and running, and the extension is reading packets from the TUN interface, is there a way to not route upstream packets through UDP links (temporarily or per packet destination)? In other words, after we get packet(s) via packetFlow->readPackets, can we skip the tunnel and send them back to the normal stack processing?

Not sure if this is a feature or a bug, but thought I would bring it up. I was experiencing very slow speeds in my NEPacketTunnelProvider subclass. I finally found the issue. It seems like a bug, but maybe it is supposed to work this way. This function, called for each packet up/down, needs a [UInt8] array from a Data object. This is what works as expected, I get close to my expected speed test of 28Mpbs: public mutating func parseL4Proto(packet: Data, l4HeaderOffset: Int) { let byteArray = [UInt8](packet) . . . If I do this instead, it compiles and runs, but my speed test now returns around 7Mbps. public mutating func parseL4Proto(packet: Data, l4HeaderOffset: Int) { let data = (packet as NSData) let byteArray = [UInt8](data) . . . Very repeatable. Change those lines and the speed test results are way off. Everything is working now, but I am posting this for others who may encounter it. Bug? Feature?