I have a local squid on address 127.0.0.1 port 3128 When i use localhost as the address of the squid i get "connection refused" When i use 127.0.0.1 it works. I have enabled IPv6 in NetBSD but squid runs on an IPv4 address, this is what you get, when you telnet to it: magick@bundy:~>telnet localhost 3128 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. It fails because of a false assumption in Mozilla If Mozilla is compiled with IPv6 support, it will do: hp = gethostbyname2(host, AF_INET6); if (!hp) hp = gethostbyname2(host, AF_INET); for host lookup. It means: - if the destination host is IPv6 only, IPv6 addresses will be tried. - if the destination host is IPv4 only, IPv4 addresses will be tried. - if the destination host is IPv4/v6 dual stack, only IPv6 addresses will be tried (Mozilla should try both!) now, in case of localhost:3128, since localhost is listed in /etc/hosts list as being dual stack host (::1 and 127.0.0.1), it falls into the 3rd bullet. since Mozilla tries ::1 port 3128 only, it cannot contact IPv4 squid waiting at 127.0.0.1 port 3128. This behaviour will probably affect all OS'es with IPv6 support. See also the NetBSD problem report pkg/12052 http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=12052

*** Bug 66749 has been marked as a duplicate of this bug. ***

*** Bug 66824 has been marked as a duplicate of this bug. ***

The code in question occurs in nsprpub/pr/src/misc/prnetdb.c Looking at it, I am guessing that this problem _will_ show up on any OS that supports IPv6. Setting OS->all, status->New

The first issue is a generic networking one--Mozilla doesn't correctly deal with multihomed hosts. If the first address is not reachable, it does not fall back to the second or subsequent ones. The second one is specific to platforms (such as linux) which don't implement the getipnodebyname() routine. On such platforms, NSPR doesn't bother to lookup IPv4 addresses when it finds IPv6 addresses. The second issue is made irrelevant by the first.

The draft-ietf-ipngwg-rfc2553bis-03.txt tells that the future protocol independent name-to-address resolution API is called getaddrinfo(), which yields chained set of 'struct addrinfo' objects. That comes from IEEE 1003.1-200x (POSIX) draft by Austin Group (IEEE/ISO/TOG). See section 6.1 of that IETF draft. (from http://www.funet.fi/internet-drafts/draft-ietf-ipngwg-rfc2553bis-03.txt Oddly IETF web has version -02 of this draft..) That API is very good, and I use it successfully at ZMailer MTA.

*** Bug 75278 has been marked as a duplicate of this bug. ***

getaddrinfo() is irrelevant to this bug. Regardless of how NSPR looks up addresses, the netwerk code will only ever try to connect to the first address. To get this fixed, it would help if someone would set up an IPv4 only test case. Create a DNS name which resolves to two IPv4 addresses, the first of which returns "network unreachable" and the second of which connects to a working http server.

jgm can try this: http://a2.zmailer.org/ Depending on luck, the system *may* give 194.252.70.168 as first one, and 194.252.70.162 as second one. The bind-9.x apparently likes to do round-robing even in case where we really don't want it to happen... At least 0.8.1 can get failed accesses about 50% of the time -- presuming long enough series of coin flips...

I would say the culprit is: netwerk/base/src/nsSocketTransport.cpp (on 0.8.1 very least), which picks only the first (if any) nsHostEnt address at the OnFound() function, into class nsSocketTransport local variable mNetAddress. The entire module needs to be reworked to use more addresses (when available).

cc'ing darin

Relieving tever of IPv6 related QA.

I'm seeing this on Linux kernel 2.4.5 - using builid 2001062113

*** This bug has been marked as a duplicate of 86917 ***

VERIFIED/dupe: per Darin's bug 86917 comment 75.