GETADDRINFO(3) System Programmer's Manual GETADDRINFO(3) NAME getaddrinfo freeaddrinfo, gai_strerror - nodename-to-address translation in protocol-independent manner SYNOPSIS #include <sys/socket.h> #include <netdb.h> int getaddrinfo(const char *nodename, const char *servname, const struct addrinfo *hints, struct addrinfo **res) void freeaddrinfo(struct addrinfo *ai) char * gai_strerror(int ecode) DESCRIPTION The getaddrinfo() function is defined for protocol-independent nodename- to-address translation. It performs functionality of gethostbyname(3) and getservbyname(3), in more sophisticated manner. The addrinfo structure is defined as a result of including the <netdb.h> header: struct addrinfo { * int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ size_t ai_addrlen; /* length of ai_addr */ char *ai_canonname; /* canonical name for nodename */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ }; The nodename and servname arguments are pointers to null-terminated strings or NULL. One or both of these two arguments must be a non-NULL pointer. In the normal client scenario, both the nodename and servname are specified. In the normal server scenario, only the servname is spec ified. A non-NULL nodename string can be either a node name or a numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number. The caller can optionally pass an addrinfo structure, pointed to by the third argument, to provide hints concerning the type of socket that the caller supports. In this hints structure all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer. A value of PF_UNSPEC for ai_family means the caller will accept any protocol family. A value of 0 for ai_socktype means the caller will accept any socket type. A value of 0 for ai_protocol means the caller will accept any protocol. For example, if the caller handles only TCP and not UDP, then the ai_socktype member of the hints structure should be set to SOCK_STREAM when getaddrinfo() is called. If the caller handles only IPv4 and not IPv6, then the ai_family member of the hints structure should be set to PF_INET when getaddrinfo() is called. If the third ar gument to getaddrinfo() is a NULL pointer, this is the same as if the caller had filled in an addrinfo structure initialized to zero with ai_family set to PF_UNSPEC. Upon successful return a pointer to a linked list of one or more addrinfo structures is returned through the final argument. The caller can pro cess each addrinfo structure in this list by following the ai_next point er, until a NULL pointer is encountered. In each returned addrinfo structure the three members ai_family, ai_socktype, and ai_protocol are the corresponding arguments for a call to the socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket ad dress structure whose length is specified by the ai_addrlen member. If the AI_PASSIVE bit is set in the ai_flags member of the hints struc ture, then the caller plans to use the returned socket address structure in a call to bind(). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, then the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol) or either connect(), sendto(),or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is a NULL pointer, then the IP address portion of the socket address structure will be set to the loopback ad dress. If the AI_CANONNAME bit is set in the ai_flags member of the hints struc ture, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null-terminated string containing the canonical name of the specified nodename. If the AI_NUMERICHOST bit is set in the ai_flags member of the hints structure, then a non-NULL nodename string must be a numeric host address string. Otherwise an error of EAI_NONAME is returned. This flag pre vents any type of name resolution service (e.g., the DNS) from being called. All of the information returned by getaddrinfo() is dynamically allocat ed: the addrinfo structures, and the socket address structures and canon ical node name strings pointed to by the addrinfo structures. To return this information to the system the function Fn freeaddrinfo is called. The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is re peated until a NULL ai_next pointer is encountered. To aid applications in printing error messages based on the EAI_xxx codes returned by getaddrinfo(), gai_strerror() is defined. The argument is one of the EAI_xxx values defined earlier and the return value points to a string describing the error. If the argument is not one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error. FILES /etc/hosts /etc/host.conf /etc/resolv.conf DIAGNOSTICS Error return status from getaddrinfo() is zero on success and non-zero on errors. Non-zero error codes are defined in <netdb.h>, and as follows: EAI_ADDRFAMILY address family for nodename not supported EAI_AGAIN temporary failure in name resolution EAI_BADFLAGS invalid value for ai_flags EAI_FAIL non-recoverable failure in name resolution EAI_FAMILY ai_family not supported EAI_MEMORY memory allocation failure EAI_NODATA no address associated with nodename EAI_NONAME nodename nor servname provided, or not known EAI_SERVICE servname not supported for ai_socktype EAI_SOCKTYPE ai_socktype not supported EAI_SYSTEM system error returned in errno If called with proper argument, gai_strerror() returns a pointer to a string describing the given error code. If the argument is not one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error. SEE ALSO getnameinfo(3), gethostbyname(3), getservbyname(3), hosts(5), services(5), hostname(7), named(8) R. Gilligan, S. Thomson, J. Bound, and W. Stevens, ``Basic Socket Inter face Extensions for IPv6,'' RFC2133, April 1997. HISTORY The implementation first appeared in WIDE Hydrangea IPv6 protocol stack kit. STANDARDS The getaddrinfo() function is defined IEEE POSIX 1003.1g draft specifica tion, and documented in ``Basic Socket Interface Extensions for IPv6'' (RFC2133). BUGS The text was shamelessly copied from RFC2133. KAME May 25, 1995 3

alastair, i think getaddrinfo was added to support ipv6. i've attached the docs for this fun. please investigate and see if there's an obvious solution, e.g. different params. if not, perhaps we should declare getaddrinfo[] broken on RH 6.0 [perhaps it's fixed in later versions]. the way to do this is to put something like #undef BROKEN_GETADDRINFO into config.h, and then have configure test for Red Hat 6.0 and turn the define on. [even better, you could make a proper configure test! have configure run a little program that calls getaddrinfo[], then waits 30 seconds or until it dies. if it's still around 30 seconds later, kill the program and define BROKEN_GETADDRINFO. maybe the timeout should be longer, for modem users?] martin, you're the configure expert; want to write this support? "Alastair J. Houghton" wrote: > > I just got the most recent CVS sources, and they *still* > don't work on my system. gdb reveals that in process-unix.c, > the (recent) change to the canonicalize_host_name function > to use getaddrinfo() appears to be the culprit. > > getaddrinfo() just seems to hang on my system - at least > with the set of parameters that are passed to it by XEmacs. > And *I* don't have any docs for it either (i.e. no man > pages & it isn't in the libc info [I'm using vanilla RedHat > 6.0, with very little extra installed]). > > Anyone else have this problem? (It could be my fault - I've > got a caching named set up, with my ISP's DNS set up as a > forwarder, and a zone for the small LAN we've got at home... > however, it works if I #undef HAVE_GETADDRINFO in s/linux.h, > and all the other software I have seems to work OK). > > Kind regards, > > Alastair. > > ____________________________________________________________ > Alastair Houghton ajhoughton(a)lineone.net -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> please investigate and see if there's an obvious solution, e.g. different Ben> params. if not, perhaps we should declare getaddrinfo[] broken on RH 6.0 Ben> [perhaps it's fixed in later versions]. the way to do this is to put something Ben> like Ben> #undef BROKEN_GETADDRINFO Ben> into config.h, and then have configure test for Red Hat 6.0 and turn the define Ben> on. [even better, you could make a proper configure test! have configure run a Ben> little program that calls getaddrinfo[], then waits 30 seconds or until it Ben> dies. if it's still around 30 seconds later, kill the program and define Ben> BROKEN_GETADDRINFO. maybe the timeout should be longer, for modem users?] Ben> martin, you're the configure expert; want to write this support? Not until we get a handle on what the problem could be. It's very hard to believe that Red Hat 6.0 is simply broken, because *I* was using it (and many other people besides). Debugging may find a problem on Alastair's system, and that could be the incentive for inadequate error checking in the XEmacs source code. The obvious thing to try is to temporarily stop using things like a local `named', and see when things start working again.

Martin

>>>>> "Ben" == Ben Wing <ben(a)666.com&gt; writes: Ben> agreed -- although getaddrinfo[] is hardly necessary [no one Ben> really has ipv6 networks yet!], and it looks very bad when we Ben> just hang indefinitely at startup. perhaps we should just set a Ben> 30-second timer when we call this function, and forcibly Ben> longjmp[] if we get stuck, outputting a warning message to Ben> stderr. Given that getaddrinfo is not used in 21.1, and is used in 21.2, which is still beta, the timing is not so bad, assuming that the world will be forced to convert to ipv6 in the next year or two. Perhaps URA Hiroshi or YOSHIFUJI Hideaki can comment on getaddrinfo() and which implementations are known to be broken? And how to test for them? (I'm thinking of a glibc version test).

>>>> "H" == Hideaki YOSHIFUJI <yoshfuji(a)v6.linux.or.jp&gt; writes:

>>>>> "H" == Hideaki YOSHIFUJI <yoshfuji(a)v6.linux.or.jp&gt; writes: H> What do you mean by "which implementation"? H> (gethostbyname() vs getaddrinfo() ???) I mean, which implementation of getaddrinfo? Early implementations will be buggy. For example, the implementations of getaddrinfo() in AIX 4 and in Red Hat 6.0 are claimed to be buggy. So what is a free software project to do, when it is not primarily a networking application, but uses the network incidentally? Most users of XEmacs do not use the network functionality much. So how to get the most reliable XEmacs? We have an autoconf test for getaddrinfo(). Perhaps we: - Use the old interface gethostbyname by default, and provide a --with-getaddrinfo configure switch for the adventurous. We change to make --with-getaddrinfo the default some time in the future, when "most" users have a system that implements getaddrinfo() well.

- Use Hideaki YOSHIFUJI's suggestion below. H> One solution against the problem that it would take long time to H> resolve names is to define a new runtime-configuration variable H> which selects protocol family being given to getaddrinfo() H> through 'hints': H> : H> memset(&hints, 0, sizeof(hints)); H> hints.ai_familt = af; /* <= set this value by configuration variable: H> PF_UNSPEC: IPv6->IPv4 (default) H> PF_INET : IPv4 H> PF_INET6 : IPV6 H> xemacs' default should be PF_UNSPEC, but H> it may be configurable by autoconf. H> Even in this case, xemacs MUST allow H> users to set this value through H> runtime-variable by thamselves: H> Red Hat can set configuration variable H> PF_INET by default, but users MUST be H> able to change that to PF_UNSPEC. */ But this depends on our knowledge of what REAL WORLD implementation do today. Hideaki, are you saying that setting hints.ai_family to PF_INET will "work" for almost all implementations that actually have a getaddrinfo function. For example, is this likely to avoid problems on AIX 4? Martin

In article <397BB7F2.FF2F459(a)666.com&gt; (at Sun, 23 Jul 2000 20:28:50 -0700), Ben Wing <ben(a)666.com&gt; says: > > - Use the old interface gethostbyname by default, and provide a > > --with-getaddrinfo configure switch for the adventurous. We change > > to make --with-getaddrinfo the default some time in the future, when > > "most" users have a system that implements getaddrinfo() well. > > i think this is the best idea. it hardly matters if we don't fetch our > canonical hostname -- and i can guarantee you that zillions of people do, and > will, have this misconfigured for a very long time, esp. when they're playing > tricks like ip masquerading. Again, I'd like to emphasise AF_INET and AI_ADDRCONFIG flag hints for getaddrinfo() will fix your (*)problem (that is, it could take a long time to resolve nodenames), so prepare a new configuration (or runtime) variable that switches protocol family (PF_UNSPEC vs PF_INET vs PF_INET6) hints for getaddrinfo(), and specify AI_ADDRCONFIG when it is possible to use it. Please forget gethostbyname() whenever you can use non-buggy getaddrinfo(). -------------+---------------+--------------------------------------------- getaddrinfo | AI_ADDRCONFIG | recommended method -------------+---------------+--------------------------------------------- good | ok | getaddrinfo() with PF_UNSPEC & AI_ADDRCONFIG good | ng | getaddrinfo() with PF_INET buggy / no | don't care | gethostbyname() -------------+---------------+--------------------------------------------- Note: your (*)problem is not buggy behavior of getaddrinfo() in above table. Any comments? -- Hideaki YOSHIFUJI <yoshfuji(a)ecei.tohoku.ac.jp&gt; Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25