getaddrinfo AF_INET6 lasts 5 seconds on macOS Sonoma

Question

Created 2w

Replies 5

Boosts 0

Participants 2

Hello; we observe slow behavior on some macOS systems which were upgraded from macOS Ventura to macOS Sonoma. , when they are connected to the company networks.

Investigation learns that the getaddrinfo call querying ipv6 is taking 5 seconds before returning. Querying information for ipv4 (ai_famlly AF_UNSPEC) returns in few mSec correct. For ipv6, I tried struct addrinfo ai_family AF_INET6 and ai_flags AI_DEFAULT , as well as AI_ALL but no help. Querying for ipv6 lasts 5 seconds. Is there a fix or workaround for this? When switching off Wi-Fi , the getaddrinfo returns in few mSec ( similar to the ipv4 check ).

The version is macOS Sonoma 14.6.1 , but also observed on other Sonoma 14.x versions and other sites/companies worldwide.

Boost

Answer 1

DTS Engineer OP

Apple

2w

I see two parts to this:

Why are these machines behaving badly?
What should you do about it in your code?

Let’s deal with the first one first. It sounds like you don’t see the problem if you install a ‘clean’ macOS 14. Is that right?

also observed on other Sonoma 14.x versions and other sites/companies worldwide.

Can you clarify this? Earlier you wrote “connected to the company networks”, which suggests that this is some sort of in-house app. However, the above makes it sound like you’re deploying this app to a wide range of enterprise networks.

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

0

Answer 2

Baudewijn Vermeire OP

2w

Correct; we did not notice this 'getaddrinfo' hanging for 5 seconds yet on macOS Sonoma on systems where the Sonoma was preinstalled. But it happens on some systems which were upgraded from a older macOS version, like Ventura

Right, we develop customer application and deploy worldwide to customers which are then used in their networks.

0

Answer 3

DTS Engineer OP

Apple

2w

Thanks for the extra info.

Are you in touch with one of these customers? If so, I think it’d be good for you to have them run some tests on your behalf. Specifically, create a small test project that builds a tool with two functions:

Resolve the relevant DNS name using getaddrinfo.
Connect to the server at that name using NWConnection (nw_connection_t in C-based languages).

This test will produce a couple of useful results:

This tool should experience the same getaddrinfo delay as your main product. If it doesn’t, that’d be weird, but also a useful clue.
If NWConnection has the same delay, you know that it’s fundamental to their DNS setup. If not, you know it’s specific to getaddrinfo. Remember that BSD Sockets is kinda of a legacy compatibility interface on our platforms (-:

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

0

Answer 4

Baudewijn Vermeire OP

2w

Thanks for the hint; how can I retrieve local ip address using nw_connection_t? I tried to use nw_endpoint_create_host, nw_parameters_set_local_endpoint, but nw_endpoint_get_address always returns null.

0

Answer 5

DTS Engineer OP

Apple

1w

how can I retrieve local ip address using nw_connection_t?

Within Network framework, connections have an associated path, that is, a route from the local endpoint to the remote endpoint. This can get complicated in the general case — like QUIC or MPTCP — but for a simple TCP connection there’s a obvious current path (nw_connection_copy_current_path). The returned path object (nw_path_t) can return both the local (nw_path_copy_effective_local_endpoint) and remote (nw_path_copy_effective_remote_endpoint) endpoints. There’s also a way to register for a callback when the path changes (nw_connection_set_path_changed_handler).

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

0