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.
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=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
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
The browser in RHEL3 (now seamonkey) should not have this issue.