macOS Sequoia No Route to Host on first request. Retries work.

My app has local network permission on macOS Sequoia and works in most cases. I've noticed that after unlocking my MacBook Pro, the very first request will regularly fail with a No Route to Host. A simple retry resolves the issue, but I would have expected the very first request to succeed.

Is this is a known issue on macOS Sequoia or by design? I'd prefer not to add a retry for this particular request as the app is a network utility.

Answered by DTS Engineer in 807898022

Right. This isn’t super surprising. There are two potential causes:

  • The obvious one is local network privacy. In some cases it will fail rather than block the calling process. I usually see this when the app doesn’t have local network access, but I can imagine it occurring in other situations.

  • The other is routing. When a Mac comes out of sleep, it can take time for it to bring up the network interfaces, and hence you may not actually have a route to your target network.

Regardless, the best way forward is to retry, which is what you’re already doing.

Oh, and the reason the API matters is because Apple’s preferred APIs, network framework and URLSession, both support the concept of waiting for connectivity, which helps to avoid problems like this. See TN3151 Choosing the right networking API for more info about your networking API choice. Sadly, this doesn’t help you because Network framework doesn’t have sufficient UDP broadcast support.

Share and Enjoy

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

Also this issue is new to macOS Sequoia. Does not repro on macOS Sonoma.

What API are you using to issue this request?

Share and Enjoy

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

The request is a UDP broadcast sent with sendto.

public func sendto(_: Int32, _: UnsafeRawPointer!, _: Int, _: Int32, _: UnsafePointer<sockaddr>!, _: socklen_t) -> Int
Accepted Answer

Right. This isn’t super surprising. There are two potential causes:

  • The obvious one is local network privacy. In some cases it will fail rather than block the calling process. I usually see this when the app doesn’t have local network access, but I can imagine it occurring in other situations.

  • The other is routing. When a Mac comes out of sleep, it can take time for it to bring up the network interfaces, and hence you may not actually have a route to your target network.

Regardless, the best way forward is to retry, which is what you’re already doing.

Oh, and the reason the API matters is because Apple’s preferred APIs, network framework and URLSession, both support the concept of waiting for connectivity, which helps to avoid problems like this. See TN3151 Choosing the right networking API for more info about your networking API choice. Sadly, this doesn’t help you because Network framework doesn’t have sufficient UDP broadcast support.

Share and Enjoy

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

macOS Sequoia No Route to Host on first request. Retries work.
 
 
Q