66872 - Mozilla can't resolve IPv4 hosts when they are IPv4/IPv6 dual stack

Status: VERIFIED DUPLICATE of bug 86917

(Core :: Networking, defect)

Description

[Mario Kemper]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[John G. Myers]

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.

Comment 5

[Matti Aarnio]

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.

Comment 6

[Matti Aarnio]

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

Comment 7

[John G. Myers]

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.

Comment 8

[Matti Aarnio]

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...

Comment 9

[Matti Aarnio]

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).

Comment 10

[neeti]

cc'ing darin

Comment 11

[benc]

Relieving tever of IPv6 related QA.

Comment 12

[Jared Mauch]

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

Comment 13

[benc]

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

Comment 14

[benc]

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