> > I know about this and have reported the issue to the bug tracker. > > There is a problem at least on Linux when the host only has a loopback > address configured, getaddrinfo() will not resolve anything. AFAICT this is > due to the AI_ADDRCONFIG flag being used when resolving names/addresses. > > > Any thoughts? > > AI_ADDRCONFIG can probably go while we're ignoring IPv6, but this does look > like a getaddrinfo() bug to me, since the POSIX wording is: > > "If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be > returned only if an IPv4 address is configured on the local > system, and IPv6 addresses shall be returned only if an IPv6 > address is configured on the local > system." > > Since when does 127.0.0.1 not count as "an IPv4 address"...? >
This is actually documented in socket interfaces rfc, http://tools.ietf.org/rfc/rfc3493.txt For example, when using the DNS, a query for AAAA records should occur only if the node has at least one IPv6 address configured (other than IPv6 loopback) and a query for A records should occur only if the node has at least one IPv4 address configured (other than the IPv4 loopback). We can add a check for loopback, --- a/src/ip.cpp +++ b/src/ip.cpp @@ -300,6 +300,17 @@ int zmq::resolve_ip_hostname (sockaddr_storage *addr_, socklen_t *addr_len_, addrinfo *res; int rc = getaddrinfo (hostname.c_str (), service.c_str (), &req, &res); if (rc) { + if (rc == EAI_NONAME) { + struct sockaddr_in *ip4_addr = (struct sockaddr_in *)addr_; + + rc = inet_pton (AF_INET, hostname.c_str (), &ip4_addr->sin_addr); + if (rc == 1 && ip4_addr->sin_addr.s_addr == htonl (INADDR_LOOPBACK)) { + ip4_addr->sin_family = AF_INET; + ip4_addr->sin_port = htons (atoi (service.c_str ())); + *addr_len_ = sizeof (struct sockaddr_in); + return 0; + } + } errno = EINVAL; return -1; } _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
