Mailing Lists
|
|
cURL Mailing List Monthly Index Single Mail
curl-tracker Archives
[curl:bugs] #1189 after failure in bindlocal(), we should try the next address, not return a fatal error
From: Kim Vandry <vandry_at_users.sf.net>
Date: Fri, 08 Feb 2013 22:32:17 +0000
Yes, I understand this.
I will write a better change. I will make sure it only continues on to the next address if the interface exists but has no valid address. If the interface doesn't exist at all then it should behave the same as before.
--- ** [bugs:#1189] after failure in bindlocal(), we should try the next address, not return a fatal error** **Status:** open-confirmed **Created:** Fri Feb 08, 2013 06:56 PM UTC by Kim Vandry **Last Updated:** Fri Feb 08, 2013 10:14 PM UTC **Owner:** Daniel Stenberg I am using curl_easy_setopt(CURLOPT_INTERFACE, "if!something") to force transfers to use a particular interface but the transfer fails with CURLE_INTERFACE_FAILED, "Failed binding local connection end" if the interface I specify has no IPv6 address. The cause is as follows: 1. The remote hostname resolves successfully and has an IPv6 address and an IPv4 address. 2. cURL attempts to connect to the IPv6 address first. 3. bindlocal (in lib/connect.c) fails because Curl_if2ip cannot find an IPv6 address on the interface. 4. This is a fatal error in singleipconnect() What I was hoping for is that it would try the next IP address in the list. If I patch singleipconnect() to treat a CURLE_INTERFACE_FAILED error from bindlocal() as a non-fatal error, everything works: it tries the IPv4 address, and that succeeds. I do not want to disable IPv6 completely (perhaps using CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4) because sometimes the interface I am binding to might have an IPv6 address. Please consider applying the suggested patch or something similar. Thank you! --- Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1189/> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/prefs/>Received on 2013-02-08 These mail archives are generated by hypermail. |
Page updated January 05, 2012.
web site info