#1189 after failure in bindlocal(), we should try the next address, not return a fatal error

closed-fixed
None
5
2014-08-14
2013-02-08
Kim Vandry
No

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!

1 Attachments

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2013-02-08
    • status: open --> open-confirmed
    • assigned_to: Daniel Stenberg
    • milestone: -->
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-02-08

    Thanks, it sounds reasonable. I'll get on this case soonish unless someone else beats me to it!

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-02-08

    If you give me your real name I'll give you proper credit for this. Not a requirement!

     
  • Kim Vandry

    Kim Vandry - 2013-02-08

    Kim Vandry (...and sourceforge profile updated)

     
  • Daniel Stenberg

    Daniel Stenberg - 2013-02-08

    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!

     
  • Kim Vandry

    Kim Vandry - 2013-02-08

    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.

     
  • Kim Vandry

    Kim Vandry - 2013-02-10

    Please have a look at this patch instead. The test suite passes.

     
  • Kim Vandry

    Kim Vandry - 2013-04-03

    Hi Daniel,

    Yes, it still works, and it still fixes the use case in my application. However I discovered two additional problems (which my application does not encounter) during testing, both related to IPv6 address scope (e.g. link-local addresses). So I made some additional changes:

    https://github.com/bagder/curl/pull/63

    • Filter the choice of address in Curl_if2ip to only consider addresses with the same scope ID as the connection address (mismatched scope for local and remote address does not result in a working connection).
    • bindlocal was ignoring the scope ID of addresses returned by Curl_if2ip . Now it uses them.
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-04-06
    • status: open-confirmed --> closed-fixed
    • milestone: --> not_used
     
  • Daniel Stenberg

    Daniel Stenberg - 2013-04-06

    Thanks, patch merged and pushed as commit 090b55c100be. Closing this issue.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks