Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation assumes all resolved addresses to be ipv4 by binding the udp socket to
0.0.0.0
.Rust the
ToSocketAddrs
trait returns an iterator over resolved socket addresses(ip, port)
. This iterator can contain IPv4 as well as IPv6 addresses (depending on the system).For example,
2.pool.ntp.org
resolves to a bunch of IPv4 and IPv6 addresses. Since the call toUdpSocket::send_to(...)
just sends the packet to the first socket address of this iterator, it attempts to send it to an IPv6 Address in this case, which fails since the UdpSocket was bound to an IPv4 address, this creates an address family conflict:This PR just does the "take the first address" itself and checks whether that address is IPv4 or IPv6 to change the bind address accordingly. This gets the above working while also adding support for IPv6 in general (e.g. using the address
[2a01:4f8:201:7454::35]:123
).(A nice side effect is, that this separates the dns resolution from the actual transmission, making it more reliable to add an offset based on the packet roundtrip.)
Workaround
For now the workaround is to use a similar approach before
request(...)
and select the first ipv4 address by filtering. It also does the dns resolution at that point, enabling the manual calculation of a roundtrip for a rough offset adjustment (which I'm currently doing).