223811 - getaddrinfo returns 3 addrinfo structs for each IP address [was: very long timeout for retrying IPv6 to IPv4 addresses]

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031009
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031009

my network is IPv6 enabled and all internal webservers are reachable via IPv6.
But almost none of them has a IPv6-enabled webserver which leads to RST,ACK from
the host.
The first connect during a session shows a timeout of 6 seconds between IPv6
connection and the next IPv4 connection trial. (I got this via packet sniffer)
This is far too long for this case.

Reproducible: Always

Steps to Reproduce:
1.close/open mozilla and load a URL from a IPv6 reachable not IPv6-enabled
web-server


Actual Results:  
you get a long timeout before the page is loaded

Expected Results:  
the timeout should be much faster

Comment 1

[Jo Hermans]

Reporter, the DNS-code was completely rewritten in Mozilla 1.6 (see bug 205726).
Can you please test one of the latest nightlies (or Mozilla 1.6a, which will be
released soon) ?

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

I've just tried it with a current trunk-build.
This was built with debugging so the times are varying but the timeout still
seems to be that long.

Comment 3

[Wolfgang Rosenauer [:wolfiR]]

Attachment: HTTP log

this log was written during one first connect to such a host

Comment 4

[Wolfgang Rosenauer [:wolfiR]]

I see the following:

every IP address is tested 3 times? (hmm, I didn't saw this with 1.5 and ethereal)
Maybe that's new?

The host has two IPv6 addresses so there will be 6 tries with connection refused.
Please note that it's very common that a host can have many IPv6 addresses.
It will get worse if there are some more IPv6 addresses for this host in DNS.

Comment 5

[Darin Fisher]

see bug 219088.  this may be a duplicate of that report.  essentially, mozilla
needs to check all IP addresses in the order in which they are received, but it
should cache the failover results along with the cache entry for the IP
addresses.  this will drastically cut down on the amount of failed connects. 
however, it will only help so long as the cache entries remain in existance.

Comment 6

[Lorenzo Colitti]

Hmm, is mozilla really calling connect() three times for every IP address in the
list? Since connection refused errors indicate that a subsequent connection to
the same address and port in the near future will almost certainly fail, I think
it should be trying every address just once. Is this intentional?

Maybe this can be fixed without caching by just making sure that each address is
tried only once. Caching would be even better, but this would be a good start.
Darin, would this be easy to fix?

Regarding bug 219088, I don't think this is related. Bug 219088 is really a bug
in the Microsoft IPv6 stack, not in Mozilla.

Leaving unconfirmed for now since I don't have an IPv6 connection handy to
reproduce it. Wolfgang, remind me to try it in a couple of days when I have IPv6
back (I might forget).

Comment 7

[Lorenzo Colitti]

In fact, this can't depend on bug 219088, since it happens on Linux and bug
219088 is a bug in the Microsoft IPv6 stack (and is not related to DNS caching
but only to getting IPv4 addresses as well as IPv6 addresses in DNS lookups).
Removing dependency.

Comment 8

[Darin Fisher]

hmm... ok, this is very unusual indeed:

> grep 'trying address' /tmp/mozilla-http-log
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a638
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a638
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a638
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a639
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a639
16386[81ce990]:   trying address: 2001:780:101:0:209:6bff:fef1:a639
16386[81ce990]:   trying address: 10.0.0.20

it would seem that we are getting duplicate host records in the DNS result. 
i've seen this before with getaddrinfo when the hints parameter does not specify
a unique sock type.  in fact, from reading the NSPR code, it looks like my fix
for this didn't make it into the code!

this patch or something like it is required in order to instruct getaddrinfo to
not return duplicate results (well, each result has a different value for
ai_socktype).  cc'ing wtc for his thoughts on this.

here's the NSPR patch that should work:

Index: prnetdb.c
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/pr/src/misc/prnetdb.c,v
retrieving revision 3.21.2.18
diff -p -u -1 -0 -r3.21.2.18 prnetdb.c
--- prnetdb.c   23 Sep 2003 17:46:21 -0000      3.21.2.18
+++ prnetdb.c   27 Oct 2003 20:36:43 -0000
@@ -2077,20 +2077,21 @@ PR_IMPLEMENT(PRAddrInfo *) PR_GetAddrInf
  
         /*
          * we assume a RFC 2553 compliant getaddrinfo.  this may at some
          * point need to be customized as platforms begin to adopt the
          * RFC 3493.
          */
  
         memset(&hints, 0, sizeof(hints));
         hints.ai_flags = AI_CANONNAME;
         hints.ai_family = AF_UNSPEC;
+        hints.ai_socktype = SOCK_STREAM;
  
         rv = GETADDRINFO(hostname, NULL, &hints, &res);
         if (rv == 0)
             return (PRAddrInfo *) res;
  
         PR_SetError(PR_DIRECTORY_LOOKUP_ERROR, rv);
     }
     return NULL;
 #endif
 }

over to NSPR ;)

Comment 9

[Darin Fisher]

Attachment: v1 patch

Comment 10

[Wolfgang Rosenauer [:wolfiR]]

this patch seems to fix it. I cannot see any longer 3 connection trials but only
one.
My original report does mention a very long timeout. But this is a network
related problem on my site. The second IPv6 address which is in DNS is not 
configured on the target host, so there is no RST from the host for this address.

Comment 11

[Wan-Teh Chang]

Comment on attachment 134297 [details] [diff] [review]
v1 patch

r=wtc.

Comment 12

[Darin Fisher]

fixed on nspr trunk and NSPRPUB_PRE_4_2_CLIENT_BRANCH

(fix will appear in 1.6 beta)