nw_proto_tcp_route_init [C6:3] no mtu received

Question

Created Apr ’24

Replies 5

Boosts 2

Participants 2

We have a relatively simple app that using Network.Framework, NWConnection, NWEndpoint to setup TCP connections with nearby devices also using the app. It's actually been working great for a while now but we've recently noticed with iOS 17.4/17.4.1 that we're spontaneously getting:

nw_proto_tcp_route_init [C6:3] no mtu received

sometimes the [C6:3] will be [C7:3] or another similar code. We may also occasionally see No route to Host appear in our console logs though this isn't definite. After this point the connection is effectively lost but we don't actually receive any updates on our NWConnection stateUpdateHandler to action on. It's sort of dead in the water so to speak.

We've reproduced this issue with multiple devices on iOS 17.4.x and in multiple network settings (in office, cafe, home networks...etc). Nothing seems to make a difference. Any ideas on how to fix or workaround this?

I saw a similar issue here: https://developer.apple.com/forums/thread/669519 but the original author never followed up and it's around 3 years old. I've captured a sysdiagnose log and can submit an issue if it warrants filing a bug report.

Boost

Answer 1

jatindervrify OP

Apr ’24

I decided to submit this as a bug using feedback assistant as well, see: FB13747811 (nw_proto_tcp_route_init [C6:3] no mtu received )

0

Answer 2

DTS Engineer OP

Apple

Apr ’24

I don’t think that log message is particularly relevant. Network framework is quite chatty in the system log.

After this point the connection is effectively lost

This is what really matters.

but we don't actually receive any updates on our NWConnection stateUpdateHandler to action on.

If you install the other handlers — pathUpdateHandler, viabilityUpdateHandler, and betterPathUpdateHandler — do you see any ‘traffic’ on those.

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

0

Answer 3

jatindervrify OP

Apr ’24

Hi Quinn,

Thanks for the response. I do have all the various handlers set and unfortunately none of them are getting hit. I've been playing with some of our NWProtocolTCP options and noticed we originally had our connectionTimeout set to 10 seconds. Increasing that to 300 seconds (arbitrarily longer value) results in us no longer hitting the issue. We've had the shorter timeout for a very long time however, close to 2 years, so I'm not sure what's changed there internally. Or if I'm just blindly throwing values at our TCP options and somehow this one worked but isn't the actual cause of the issue.

Thanks! Jatinder

0

Answer 4

DTS Engineer OP

Apple

Apr ’24

I generally recommend against monkeying with timeout parameters. I’ve talked about my approach to timeouts many times here on DevForums; this post is a good example.

However, I can’t see how this short timeout would lead to the behaviour you’re seeing. I know that you can reproduce this, but how easy is it? Could you, for example, reproduce it while recording an RVI packet trace?

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

0

Answer 5

jatindervrify OP

May ’24

Hi Quinn,

Sorry for the slow response. I managed to record an RVI packet trace and found it was very very peculiar. The TCP traffic appears to just stop - it's as though a lock was occurring on the sending device and even though we were trying to send data using @preconcurrency final public func send(content: Data?, contentContext: NWConnection.ContentContext = .defaultMessage, isComplete: Bool = true, completion: NWConnection.SendCompletion) none of it goes through after the what I'm calling a "lock" occurs.

In the end I realized that we had a number of Tasks potentially in "parallel" calling this code that is wrapped in an async method in our peer to peer comm layer. By moving the method to always execute on @MainActor the issues appears resolved. This is a stop gap and I'm still investigating to see if how I've structured my concurrency code is further at fault or can be cleaned up better to interact with the NWConnection. Just wanted to update the thread and see if you has any thoughts or opinions.

Thanks!

0