Re: getaddrinfo problem and weird nameserver

[Jason Gunthorpe <jgg at ualberta dot ca>]

On 30 Nov 1999, Andreas Jaeger wrote:

>  > It seems that getaddrinfo sets some sort of IPv6 flag even though my box
>  > hasn't got any IPv6 capability and this (I presume) upsets the name server
>  > I use. The problem goes away if I switch name servers or use traditional
>  > name resolution.
 
> It depends how you call getaddrinfo.  struct addrinfo has a field
> ai_family.  If you set this to AF_INET, you will only get IPv4
> information.  If you set it to 0, you get both IPv4 and IPv6.

I set it to 0 (PF_UNSPEC really) because my application can properly deal
with IPv6 hosts.

While I was trying to come up with a good example of this I discovered
that getaddrinfo seems totaly broken now, I had code that worked correctly
about 5 months ago and now it doesn't :< Consider this program:

#include <netdb.h>
#include <string.h>
#include <stdio.h>

int main(int argc, const char *argv[])
{
   struct addrinfo Hints;
   struct addrinfo *LastHostAddr = 0;
   int Res;

   memset(&Hints,0,sizeof(Hints));
   Hints.ai_family = PF_UNSPEC;
   Hints.ai_socktype = SOCK_STREAM;

   Res = getaddrinfo(argv[1],argv[2],&Hints,&LastHostAddr);

   printf("Res %i, Addr: %p\n",Res,LastHostAddr);
   return 0;
}

Very simple test, Run:

pandora{jgg}/tmp#./a.out pandora.ipv6.debian.org http
Res -5, Addr: (nil)
pandora{jgg}/tmp#ping6 pandora.ipv6.debian.org
PING pandora.ipv6.debian.org(pandora.ipv6.debian.org) 56 data bytes
64 bytes from pandora.ipv6.debian.org: icmp_seq=0 time=0.1 ms

AFAIK that is definately wrong:
  1) The name exists and is properly set in a public name server
  2) The machine has IPv6 capability so it should return the IPv6 address

Furthermore,

pandora{jgg}/tmp#./a.out ::1 http
Res 0, Addr: 0x804a440

If you substitute PF_UNSPEC for PF_INET6 in the test program then it
returns an address for pandora.ipv6.d.o. This all used to work with an
older glibc2.1. 

Now, this is not my original concern (though now it is a major one!)  My
original concern was that getaddrinfo was doing pointless IPv6 lookups. 
My reading of RFC 2553 suggests that getaddrinfo should never return an
IPv6 socket type on a system that does not support IPv6, that is I should
always be able to pass all of the resulting addresess to connect() and
expect them to work.

However, using another system without IPv6:
larcs{root}/tmp#./a.out ::1 http
Res 0, Addr: 0x804a3c8

Woops! That should have given an error, IMHO.

The glibc I am using to test is 2.1.2 final on Debian i386 (2.1.2-10)

Thanks,
Jason