Bug 104486 - Mozilla doesn't use IPv4 if IPv6 connect fails.
Mozilla doesn't use IPv4 if IPv6 connect fails.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mozilla (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-16 05:54 EDT by David Woodhouse
Modified: 2007-11-30 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version: seamonkey-1.0.x
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 18:55:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2003-09-16 05:54:20 EDT
Description of problem:
Mozilla fails to connect to external hosts with both IPv6 and IPv4 addresses,
if the system has IPv6.

Version-Release number of selected component (if applicable):
mozilla-1.4-3.0.14

Note this does _not_ happen with mozilla-1.4-12 from Cambridge.

How reproducible:
100%

Steps to Reproduce:
1. Configure a site-local (fec0::/16) address on a Taroon system.
2. Observe that 'telnet www.tcpdump.org 80' works. System knows it can't
   connect to a _global_ IPv6 address from its site-local IPv6 address.
3. Run Mozilla -- obviously configured _not_ to use a proxy.
4. Try looking at www.tcpdump.org. See it fail. 
5. Try same on Cambridge. See it work.
Comment 1 Christopher Blizzard 2003-09-29 16:53:34 EDT
Those are based on the exact same source code.  I'll bet the problem is lower
than Mozilla.  Look at the kernel/glibc.
Comment 2 David Woodhouse 2003-09-30 04:03:00 EDT
There was a glibc update on my test box since the bug was reported.... now I
can't reproduce. Harald, can you?
Comment 3 Joe Orton 2004-03-17 09:43:52 EST
This is reproducible in RHEL3.  For a box where getaddrinfo for
"www.heanet.ie" with AF_UNSPEC in the hints.ai_family returns two
addresses in this order:

inet6: family=10, flowinfo=0, addr=2001:770:18:2::79, port=0
inet4: family=2, addr=193.1.219.79, port=0

Mozilla is not trying both the addresses returned: it tries the IPv6
address, which fails since the box has no globally routable IPv6
address, then it gives up.

glibc in FC1 has the same behaviour, and Mozilla fails there likewise.
 In later glibcs, getaddrinfo is smarter and returns the addresses in
the other order for this config, so Mozilla happens to work: but the
bug is here regardless; Moz should try all the returned addresses
regardless of family and ordering.

[root@emcee root]# rpm -q mozilla glibc
mozilla-1.4-3.0.18
glibc-2.3.2-95.9
Comment 4 Joe Orton 2004-10-29 14:02:10 EDT
I saw the fix for this listed in the Firefox PR1 changelist:

https://bugzilla.mozilla.org/show_bug.cgi?id=246193

one-liner patch at:

https://bugzilla.mozilla.org/attachment.cgi?id=150825&action=view
Comment 5 Christopher Aillon 2006-09-05 18:55:03 EDT
The browser in RHEL3 (now seamonkey) should not have this issue.

Note You need to log in before you can comment on or make changes to this bug.