Re: ipv6 connect timeout

ah I missed that CuRL have a happy eyeball timeout!

/HH

Den fre 22 aug. 2025 kl 20:20 skrev Dmitry Karpov via curl-library <
[email protected]>:

> *“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 <[email protected]> *On Behalf Of *Henrik
> Holst via curl-library
> *Sent:* Friday, August 22, 2025 10:41 AM
> *To:* Lars Sunde <[email protected]>
> *Cc:* Henrik Holst <[email protected]>; libcurl development <
> [email protected]>
> *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 <[email protected]>:
>
> 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 <[email protected]>
> *Sendt:* fredag 22. august 2025 10:25
> *Til:* libcurl development <[email protected]>
> *Kopi:* Lars Sunde <[email protected]>
> *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 <
> [email protected]>:
>
> 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
>
>
>    2. IPv6: ::1
>
>
>    3. IPv4: 127.0.0.1
>
>
>    4. Trying [::1]:8010...
>
>
>    5. Trying 127.0.0.1:8010...
>
>
>    6. 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
>
>
>    2. IPv6: ::1
>
>
>    3. IPv4: 127.0.0.1
>
>
>    4. Trying [::1]:8010...
>
>
>    5. ipv6 connect timeout after 2985ms, move on
>
>
>    6. Connection timeout after 3378 ms
>
>
>    7. 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
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html