Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 104486

Summary:	Mozilla doesn't use IPv4 if IPv6 connect fails.
Product:	Red Hat Enterprise Linux 3	Reporter:	David Woodhouse <dwmw2>
Component:	mozilla	Assignee:	Christopher Aillon <caillon>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	harald, jorton, lwhatley
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	seamonkey-1.0.x	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-09-05 22:55:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Woodhouse 2003-09-16 09:54:20 UTC

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 20:53:34 UTC

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 08:03:00 UTC

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 14:43:52 UTC

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 18:02:10 UTC

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 22:55:03 UTC

The browser in RHEL3 (now seamonkey) should not have this issue.