Ack, sorry... I forgot to update the version of the code in my email to match what was saved on disk before I sent it. Here you go... On Jan 10, 2008, at 22:35, Jeremy Huddleston wrote:
Hi Greg,
Here's a stripped down app which reveals the problem. Compile and run './getaddrtest localhost' to see (up to endianness for the ipv4 addr):
entry 0: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 1: Family: AF_INET6 sin6_port: 0 sin6_flowinfo: 0 sin6_scope_id: 0 Address: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1. entry 2: Family: AF_INET Address: 127.1.1.1
Note that the scope_id is the same... And I think that about covers all the items in sockaddr_in6 that we could match:
struct in6_addr { union { __uint8_t __u6_addr8[16]; __uint16_t __u6_addr16[8]; __uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ };
#define s6_addr __u6_addr.__u6_addr8
struct sockaddr_in6 { __uint8_t sin6_len; /* length of this struct(sa_family_t)*/ sa_family_t sin6_family; /* AF_INET6 (sa_family_t) */ in_port_t sin6_port; /* Transport layer port # (in_port_t)*/ __uint32_t sin6_flowinfo; /* IP6 flow information */ struct in6_addr sin6_addr; /* IP6 address */ __uint32_t sin6_scope_id; /* scope zone index */ };
<getaddrtest.c>
On Jan 10, 2008, at 21:37, Greg Parker wrote:
On Jan 10, 2008, at 8:55 PM, Jeremy Huddleston wrote:
So actually, I traced it back to duplicate entries appearing as a result of get_address_info()... and that seems to be coming from OSX's getaddrinfo() returning the duplicate entry:
Is this a bug in getaddrinfo()? Should it not be returning duplicates? I don't see in the documentation anywhere that it guarantees uniqueness... so I'm going to try whipping together a patch to get_address_info() which prevents the duplicates from being passed on to the caller of get_address_info()... hopefully that will solve our problem.
(gdb) n 296 if (getaddrinfo(host,NULL,&hints,&firstai) !=0) return NULL; (gdb) n 297 for (ai = firstai; ai != NULL; ai = ai->ai_next) { (gdb) print *firstai $1 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x3003e0, ai_next = 0x300400 } (gdb) print *firstai->ai_next $2 = { ai_flags = 0, ai_family = 30, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 28, ai_canonname = 0x0, ai_addr = 0x300420, ai_next = 0x300440 }
These are both AF_INET6, IPPROTO_TCP, SOCK_STREAM.
(gdb) print *firstai->ai_addr $4 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> } (gdb) print *firstai->ai_next->ai_addr $5 = { sa_len = 28 '\034', sa_family = 30 '\036', sa_data = '\0' <repeats 13 times> }
What are the full contents of both of these? They're struct sockaddr_in6, 28 bytes long. They may not be duplicates because this only shows the first 16 bytes.
My guess is that you're seeing IPv6 loopback on two different interfaces (i.e. ::1%en0 for ethernet and ::1%en1 for wifi), or perhaps an unscoped ::1 and a interface-specific ::1. In these cases, sin6_addr will be all zeros with 0x01 at the end, and sin6_scope_id (the last 4 of the 28 bytes) will differ.
-- Greg Parker gparker@apple.com Runtime Wrangler
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev