Ref. failing tests "101 103 108 119 and more" (http://curl.haxx.se/auto)
for AIX w/ipv6.

It turns out there's a problem in AIX's getaddrinfo(), the returned addrinfo*
doesn't set ai_socktype (whatever kind of hints you add), which is later
used as a parameter to the socket() call. (Passing 0 to socket() will fail.)

There are several getaddrinfo() problems logged in IBM's bug database, but
not this particular one (I tested getaddrinfo on a range of platforms and
all the others always sets ai_socktype).
However, I found a reference to such a problem in a fix done by Ken Raeburn
for the kerberos5 system:

"Work around another AIX bug:
 [_AIX]: Define NUMERIC_SERVICE_BROKEN.
 [NUMERIC_SERVICE_BROKEN]: Include ctype.h and stdlib.h.
 (getaddrinfo) [NUMERIC_SERVICE_BROKEN]: If the service name is a numeric
 string, save its value and the socket type, pass a null pointer to the real
 getaddrinfo, and patch the returned results."

Ref:
<http://mailman.mit.edu/pipermail/cvs-krb5/2002-November/001063.html>

That's probably the same error as we're seeing, and my guess is that the
code he refers to (I haven't actually seen it) does something along the
lines of the appended tentative fix.

With this patch AIX5 passes all the tests that used to fail when ipv6 was
enabled (basically those that would call ftp_use_port()).

-Tor
Appended: Patch to let tests 101 103 108 119 144 145 pass on AIX5
0
Index: lib/ftp.c
===================================================================
RCS file: /repository/curl/lib/ftp.c,v
retrieving revision 1.224
diff -u -p -r1.224 ftp.c
--- lib/ftp.c 5 Feb 2004 09:26:01 -0000 1.224
+++ lib/ftp.c 6 Feb 2004 14:35:52 -0000
@@ -1167,6 +1167,12 @@ CURLcode ftp_use_port(struct connectdata
   
   portsock = -1;
   for (ai = res; ai; ai = ai->ai_next) {
+ /*
+ * Workaround for AIX5 getaddrinfo() problem (it doesn't set ai_socktype):
+ */
+ if (ai->ai_socktype == 0)
+ ai->ai_socktype = hints.ai_socktype;
+
     portsock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
     if (portsock < 0)
       continue;
Received on 2004-02-06