operating system's name and version number : Windows XP SP2 - (IPv6 installed using netsh interface ipv6 install)
what version of curl you're using: 7.15
what URL you were working with: http://\[2001:1890:110b:15ce:250:56ff:254.187.40.177] This is an IPv4 mapped address corresponding to the v6 address:
http://\[2001:1890:110b:15ce:250:56ff:febb:28b1]
Details:
Using the curl library, we are facing some issues in downloading details from an IPv4 mapped IPv6 address.
Logged In: YES
user_id=1110
Originator: NO
Please try a much more recent curl version as 7.15 is quite outdated. 7.18.1 is the most recent one that we believe works correctly in this aspect.
The, exactly in what way does it fail when you run what command? Can you please show us the source code for a small stand-alone program that repeats the problem?
Logged In: YES
user_id=236775
Originator: NO
Are you encountering by any chance KNOWN_BUG #30? http://curl.haxx.se/docs/knownbugs.html
Logged In: YES
user_id=1110
Originator: NO
Please respond or this will be closed with no further action.
Logged In: YES
user_id=2088915
Originator: YES
The method Curl_getaddrinfo fails:
Curl_addrinfo *Curl_getaddrinfo(struct connectdata *conn,
char *hostname,
int port,
int *waitp)
{
struct addrinfo hints, *res;
int error;
char sbuf[NI_MAXSERV];
char *sbufptr = NULL;
char addrbuf[128];
curl_socket_t s;
int pf;
struct SessionHandle *data = conn->data;
int ai_flags;
*waitp=0; /* don't wait, we have the response now */
/* see if we have an IPv6 stack */
s = socket(PF_INET6, SOCK_DGRAM, 0);
if (s < 0) {
/* Some non-IPv6 stacks have been found to make very slow name resolves
* when PF_UNSPEC is used, so thus we switch to a mere PF_INET lookup if
* the stack seems to be a non-ipv6 one. */
pf = PF_INET;
}
else {
/* This seems to be an IPv6-capable stack, use PF_UNSPEC for the widest
* possible checks. And close the socket again.
*/
sclose(s);
/*
* Check if a more limited name resolve has been requested.
*/
switch(data->set.ip_version) {
case CURL_IPRESOLVE_V4:
pf = PF_INET;
break;
case CURL_IPRESOLVE_V6:
pf = PF_INET6;
break;
default:
pf = PF_UNSPEC;
break;
}
}
if((1 == Curl_inet_pton(AF_INET, hostname, addrbuf)) ||
(1 == Curl_inet_pton(AF_INET6, hostname, addrbuf))) {
/* the given address is numerical only, prevent a reverse lookup */
ai_flags = AI_NUMERICHOST;
}
else
ai_flags = AI_CANONNAME;
memset(&hints, 0, sizeof(hints));
hints.ai_family = pf;
hints.ai_socktype = conn->socktype;
hints.ai_flags = ai_flags;
if(port) {
snprintf(sbuf, sizeof(sbuf), "%d", port);
sbufptr=sbuf;
}
error = getaddrinfo(hostname, sbufptr, &hints, &res);
if (error) {
infof(data, "getaddrinfo(3) failed for %s:%d\n", hostname, port);
return NULL;
}
return res;
}
Logged In: YES
user_id=236775
Originator: NO
Is your libcurl using your system's inet_pton() function or curl's own Curl_inet_pton()? curl's should handle this address format fine.
Logged In: YES
user_id=236775
Originator: NO
Accessing the local server with the command: "curl -v -g 'http://[::ffff:127.0.0.1]/'" works fine for me on Linux with curl 7.18.1.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).