On Wed, 24 May 2023 at 02:01, Jakob Bohm <jb-use...@wisemo.com.invalid> wrote:
> For more rapid testing, could you describe the particular failing > getaddrinfo() behavior and perhaps provide a sample command line C > program that tests it in isolation instead of forcing each tester to > run through a long ntpd run (usually hours of test time plus difficult > log interpretation versus a quick run that outputs relevant results to > stdout even with a different NTP daemon running). Actually it doesn't take hours, just seconds. You just need to see if using only "pool 2.pool.ntp.org" you see only IPv4 pool servers or both IPv4 and IPv6 servers in the "ntpq -p" billboard right after starting ntpd on a Windows system with a global IPv6 address. Nonetheless, a standalone test program is easier to set up and doesn't require messing with your existing ntpd, so I wrote one. getaddrinfo-test optionally takes a hostname and service to look up, defaulting to 2.pool.ntp.org and ntp. You can download the source and a ready-to-run 32-bit .exe from: https://people.nwtime.org/hart/getaddrinfo-test.zip Here's what the output looks like on my Windows 11 22H2 system without IPv6 connectivity: Using hostname 2.pool.ntp.org. service ntp AF_UNSPEC: 128.82.68.1 216.84.68.1 240.84.68.1 160.83.68.1 AF_INET: 56.82.68.1 48.84.68.1 80.82.68.1 104.82.68.1 AF_INET6: getaddrinfo error: The requested name is valid, but no data of the requested type was found. I'd appreciate testing on systems with both IPv4 and IPv6 internet access with as many different versions of Windows as possible. You'll reproduce what I saw if there are IPv6 addresses under AF_INET6 but not under AF_UNSPEC. Incidentally, you can help me convince Microsoft this should be investigated by upvoting the Feedback Hub issue I opened. I presume this link will work only from a Windows 10 or 11 machine: https://aka.ms/AAkyamq Cheers, Dave Hart
