This is, admittedly, an edge case that most people will probably not encounter. But worth awareness...
Aside - Bruce, the NetWebClient in NetDemo has an IPV6 checkbox but it doesn't do anything. For my testing I replaced it with radio buttons for Net:IPvAuto, Net:IPv4, Net:IPv6
I would suggest you modify the NetDemo app that way... it's useful for testing.
/Aside
I have various apps running on a Windows 2019 server in an Active Directory domain that is set up with only IPv4 DNS.
The two apps involved in this problem are both ones I'm in the process of converting from NT12 to NT14. One is an API server, the other has an API client.
After rebuilding, I set the server to serve IPv4.
I did not change the client.
Its default behavior (Net:IPvAuto) did not work for me.
I guess that whatever is happening takes place inside the NetTalk DLL, so I'm not sure how you're doing the auto.
Your docs say: "By default, and if Family is set to Net:IPvAuto or Net:IPv4 then an IPv4 DNS Lookup will happen on this name first".
But what shot me in the foot (I did not shoot MYSELF in the foot!!) is apparently how Windows handles a lookup when it "knows" that the server in question is itself.
As you can see from the first pic, doing an NSLOOKUP (which uses the DNS server) resolves to an IPv4 address (which is all that our DNS handles).
But doing a PING of the same FULLY-QUALIFIED DNS ADDRESS returns a loopback IPv6 address.
I don't know if that is the cause... but the net client compiled without specifying IP family refuses to connect to my API server. If you were actually doing a DNS lookup I would have thought that "auto" would have figured out to use IPv4. If you're doing a PING internally, it would have found the IPv6.
If I force the client to use IPv4, all is well in the world. So at least in my edge case, "auto" is not bullet-proof.
More grey hairs... sigh...
Cheers,
Jane
Topic: IP V6 bit me (Read 2625 times)