“Step 4 in the above list uses approximately 200ms to execute before moving on to trying 127.0.0.1.”
I think this is a normal Happy Eyeballs behavior when IPv4 is tried after 200ms timeout (default libcurl HEB timeout) on IPv6. But in the second case (Windows 10 inside Oracle Virtual Box), by some reason it takes ~3000ms for the Happy Eyeballs to detect the IPv6 connection timeout instead of 200ms. It is strange, and I don’t think that firewall somehow affects HEB timeout logic. I can only guess that it is either the Windows 10 was running too slow inside the VM, so the libcurl app didn’t have a chance to detect the HEB timeout normally, or the HEB timeout was changed somehow from the default 200ms value to 3s. I recommend to play with CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS option and see if it changes the HEB timeout behavior. Thanks, Dmitry Karpov From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Henrik Holst via curl-library Sent: Friday, August 22, 2025 10:41 AM To: Lars Sunde <laasu...@hotmail.com> Cc: Henrik Holst <henrik.ho...@millistream.com>; libcurl development <curl-library@lists.haxx.se> Subject: [EXTERNAL] Re: ipv6 connect timeout Hi, what I mean is that normally when you try and make a connection attempt to a port where no application is listening, the (in this case on your IPv6 address) tcp/ip stack will reply with a TCP_RESET to notify the side trying to make a connection that there is no one listening. Normal behaviour in Windows creates a 300ms latency vs every other OS due to the design of Windows which is why you see this in your Windows 11 setup, however since you see a 3000ms timeout on your Windows 10 setup I suspect that there is something filtering out this TCP_RESET message and that perhaps the local firewall that is active by default in Windows 10 is what is causing this (normal behaviour of a firewall is to simply ignore everything so that the connecting side cannot learn what is and what is not running on the host and also to slow down any port scanning activity). /HH Den fre 22 aug. 2025 kl 14:47 skrev Lars Sunde <laasu...@hotmail.com<mailto:laasu...@hotmail.com>>: Thanks for the feedback. Please forgive my ignorance but I do not fully understand what you mean by Windows 10 firewall ignore the connection attempt. Do you mean the firewall blocks the connection attempt? Is this a know bug with Windows 10 firewall? I tried enabling firewall logging but have not been able to verify that the firewall is actually stopping a connection. Lars ________________________________ Fra: Henrik Holst <henrik.ho...@millistream.com<mailto:henrik.ho...@millistream.com>> Sendt: fredag 22. august 2025 10:25 Til: libcurl development <curl-library@lists.haxx.se<mailto:curl-library@lists.haxx.se>> Kopi: Lars Sunde <laasu...@hotmail.com<mailto:laasu...@hotmail.com>> Emne: Re: ipv6 connect timeout I think that the firewall in Windows 10 simply ignores the connection attempt and does not send a TCP_RESET while your Windows 11 setup does which is why CuRL on the one can detect that there exists no listening application on that port and ip and on the other system it have to time out the connection first (which though by default should take 300s and not just 3s). /HH Den fre 22 aug. 2025 kl 09:57 skrev Lars Sunde via curl-library <curl-library@lists.haxx.se<mailto:curl-library@lists.haxx.se>>: Hello, We are running C++ software that uses libCurl 8.5 on Windows 10 and 11 that perform HTTP operations. During testing I notice a difference in some rare situations when running the software in Window 11 and in a virtual machine. The virtual machine is Oracle Virtual Box with Windows 11 host and Windows 10 guest OS). We enabled CURLOPT_VERBOSE to debug the issue when the software attempts to perform a HTTP post operation. Here is the output from Windows 11; 1. Host localhost:8010 was resolved 1. IPv6: ::1 1. IPv4: 127.0.0.1 1. Trying [::1]:8010... 1. Trying 127.0.0.1:8010... 1. Connect to localhost (127.0.0.1) port 8010 Step 4 in the above list uses approximately 200ms to execute before moving on to trying 127.0.0.1. Here is the output from Windows 10 inside Oracle Virtual Box; 1. Host localhost:8010 was resolved 1. IPv6: ::1 1. IPv4: 127.0.0.1 1. Trying [::1]:8010... 1. ipv6 connect timeout after 2985ms, move on 1. Connection timeout after 3378 ms 1. Close connection Step 4 in the above list uses approximately 2985ms to execute before moving on ... Windows 11 has the following interfaces (according to "route print" command) * Intel(R) Ethernet Connection * VirtalBox Host-only Ethernet Adpter * Software Loopback Interface Windows 10 inside VirtualBox has the following interfaces (according to "route print" command) * Intel(R) PRO/1000 MT * Software Loopback Interface Why does Windows 10 inside a virtual machine use 15 times as much time to try IPv6 before moving on? How can I possible reduce or remove this difference? I have read above CURLOPT_IPRESOVE but really need to understand the problem before considering this solution. Appreciate any input Regards, Lars -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
