nw_path_enumerate_gateways gives me no love

This doesn't enumerate even though I do have a gateway.
Did anybody have any luck with this function? Its neighbor
Code Block
nw_path_enumerate_interfaces()
works fine, connection is also fine.
Code Block
auto path = nw_connection_copy_current_path(connection);
nw_path_enumerate_gateways(path, ^bool(nw_endpoint_t gateway) {
os_log_info(oslog, "Gateway!");
return true;
}

Answered by DTS Engineer in 661952022
I’d completely forgotten about the gateways property. Nice catch!

Anyway, I tried this out and I saw some very strange behaviour. For example, when I open a TCP connection I see the gateways property populated when the connection is in the .preparing state and then depopulated when it gets into the .ready state. This last bit is definitely a bug, one that I filed for myself (r. 74269834).

Anyway, I do see the gateways property populated during the .preparing state, which might be enough for your needs. Do you also see that? If not, how are you testing it? I’m testing on an iPhone running iOS 14.4 on Wi-Fi with a TCP connection to example.com.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Accepted Answer
I’d completely forgotten about the gateways property. Nice catch!

Anyway, I tried this out and I saw some very strange behaviour. For example, when I open a TCP connection I see the gateways property populated when the connection is in the .preparing state and then depopulated when it gets into the .ready state. This last bit is definitely a bug, one that I filed for myself (r. 74269834).

Anyway, I do see the gateways property populated during the .preparing state, which might be enough for your needs. Do you also see that? If not, how are you testing it? I’m testing on an iPhone running iOS 14.4 on Wi-Fi with a TCP connection to example.com.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Nice!
Same thing on Big Sur - "preparing" has it, "ready" and after no more.
It also works in path_changed_handler block - kind of makes sense, I can stash it away there.
In my case this is a UDP connection, so this can be done without actually sending any packets.
Thank you, Quinn!
Still spotty though, in case of a route pointing at VPN interface doesn't ever return anything. I'd expect it to work like
Code Block
route -n get <IP>

So gateway output points at your next hop.
nw_path_enumerate_gateways gives me no love
 
 
Q