This patch has a downside I'm not sure how to handle:

Test 1084 clearly shows a sample when the --interface simply points to a bad host name to bind to and it fails. Although with this fix it no longer returns 45 like before but instead ends up returning 7 which is much more mysterious and hard to understand...

I think we need a slightly more complicated fix for this so that test 1084 still can tell what the problem was, and still support your case!

---
** [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:13 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/>