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?
Here is a relevant section from the console:
default 12:18:46.628081-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 initial path ((null))] event: path:start @0.000s
default 12:18:46.628137-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 12:18:46.628679-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 waiting path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: path:unsatisfied @0.000s, uuid: 80574970-6F25-4388-8936-6809DEF1A02C
default 12:18:46.628741-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state waiting
default 12:18:46.628978-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 in_progress resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:start_dns @0.001s
default 12:18:46.629035-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 12:18:46.629092-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state preparing
default 12:18:46.629247-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Waiting.
default 12:18:46.629465-0600 mDNSResponder [R39862] DNSServiceCreateConnection START PID[1594](IWiNS-Tunnel)
default 12:18:46.629714-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Waiting.
default 12:18:46.629961-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 12:18:46.630305-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 in_progress resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:receive_dns @0.002s
default 12:18:46.630402-0600 mDNSResponder [R39862] DNSServiceCreateConnection STOP PID[1594](IWiNS-Tunnel)
default 12:18:46.630884-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 initial path ((null))] event: path:start @0.002s
default 12:18:46.631225-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 waiting path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: path:unsatisfied @0.003s, uuid: 359E2D37-59A9-4025-93E2-7B2D52986999
default 12:18:46.631548-0600 IWiNS-Tunnel [C618.1 IPv4#5aa006fc:8091 failed path (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: null:null @0.003s
default 12:18:46.631696-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 failed resolver (unsatisfied (No network route), interface: pdp_ip0, dns, expensive)] event: resolver:children_failed @0.003s
default 12:18:46.631773-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C618] reporting state failed error Network is down
default 12:18:46.632093-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 12:18:46.632160-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Failed.
default 12:18:46.632241-0600 IWiNS-Tunnel iwins->tunnel: *** Failed Link: LTE ***
default 12:18:46.632327-0600 IWiNS-Tunnel iwins->tunnel: Stopping KVO observers
default 12:18:46.632405-0600 IWiNS-Tunnel [C618 E0D68D17-6E75-4CDC-84F1-74CC16AD1AF0 IPv4#5aa006fc:8091 udp, local: 192.0.0.1:59831] cancel
default 12:18:46.632482-0600 IWiNS-Tunnel [C618 IPv4#5aa006fc:8091 udp, local: 192.0.0.1:59831] cancelled
This is how the console looks when it works (Verizon)
default 14:56:05.737875-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 14:56:05.738353-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C4] reporting state preparing
default 14:56:05.739279-0600 IWiNS-Tunnel nw_flow_connected [C4 IPv4#6942181e:8091 in_progress channel-flow (satisfied (Path is satisfied), interface: pdp_ip0, scoped, ipv4, ipv6, dns, expensive)] Output protocol connected
default 14:56:05.739496-0600 IWiNS-Tunnel nw_connection_report_state_with_handler_on_nw_queue [C4] reporting state ready
default 14:56:05.739645-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Preparing.
default 14:56:05.739684-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (State) - LTE. New State: Ready.
default 14:56:05.739764-0600 IWiNS-Tunnel iwins->tunnel: UDPSession Observer callback (IsViable) - LTE. IsViable: true.
(Update) From what I am reading, the issue is likely because T-Mobile requires ipv6 only support. When I setup the tunnel, I do provide both v4 and v6 endpoints, but when setting up the individual links, I can only specify a single local IP address (v4 or v6). Can someone explain how to setup a NWUdpSession that supports both v4 and v6, or it that is even the right thing to do?
Tunnel:
tunSettings.ipv4Settings = NEIPv4Settings(addresses: [ip4Address], subnetMasks: ["255.255.255.0"])
tunSettings.ipv4Settings?.includedRoutes = [NEIPv4Route.default()]
tunSettings.ipv6Settings = NEIPv6Settings(addresses: [ip6Address], networkPrefixLengths: [124 as NSNumber])
tunSettings.ipv6Settings?.includedRoutes = [NEIPv6Route.default()]
Links:
let src = NWHostEndpoint(hostname: link.ipv4!, port: String(link.port))
link.udpSession = self.createUDPSession(to: dest, from: src)
Matt? Quinn? Any thoughts on this?
When I setup the NWUdpSession for LTE, for the source address, I get the IP address of 192.0.0.1. Always. On any phone I try this with. Whereas, with Verizon, we get a random IP for LTE, like 100.105.38.96.
On Android, we don't bind to a local IP address, we bind to a transport type, e.g. Wi-Fi or LTE. I am wondering if there is a similar option in iOS.
Matt? Quinn? Any thoughts on this?
The deafening silence usually means that we don’t have any quick answers for you )-: I recommend that you open a DTS tech support incident so that Matt can carve out some time to look at this in depth [1].
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] He says, committing Matt to do work without consulting him! (-:
Matt? Quinn? Any thoughts on this?
I must have missed this go by originally. Quinn is right, you can open a TSI and I will look into this situation in more detail.
Regarding:
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?
You are correct. When the device reboots or the device switches over to a all IPv6 cellular carrier like you are describing, the potential for the XLAT interface to come alive is available, and that is what you are seeing with 192.0.0.1, essentially XLAT464 has been enabled to provide IPv4 availability for cellular as well.
This means that connections running through your tunnel should be able to user either IPv4 or IPv6, which is good. In some cases your tunnel may only come up with IPv6 availability and you may need to perform address translation etc... but that is larger another topic altogether.
Regarding your NWUDPSession issues, this is a bit odd and I suspect that you may have something wrong here if your TCP connections through the tunnel exhibit the same behavior. I find that TCP is a better barometer of the state of the tunnel because of the book-keeping built into how TCP works as opposed to UDP.
How are you parsing your data being read from the virtual interface and determining that it should be send as datagrams connections through NWUDPSession?
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com