Red Hat Bugzilla – Bug 104486
Mozilla doesn't use IPv4 if IPv6 connect fails.
Last modified: 2007-11-30 17:06:58 EST
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):
Note this does _not_ happen with mozilla-1.4-12 from Cambridge.
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.
Those are based on the exact same source code. I'll bet the problem is lower
than Mozilla. Look at the kernel/glibc.
There was a glibc update on my test box since the bug was reported.... now I
can't reproduce. Harald, can you?
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=188.8.131.52, 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
I saw the fix for this listed in the Firefox PR1 changelist:
one-liner patch at:
The browser in RHEL3 (now seamonkey) should not have this issue.