drago01 Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.8.1.10) Gecko/20071213 Fedora/2.0.0.10-3.fc8 Firefox/2.0.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b3pre) Gecko/2008012604 Minefield/3.0b3pre

When testing firefox 3 on my system it was unable to connect to any site. I have disabled ipv6 dns by setting network.dns.disableIPv6 to true and it started to work fine. 
Firefox 2 (all versions) works fine with this setting set to false (default setting).
My ISP does not support ipv6 yet.


Reproducible: Always

Steps to Reproduce:
1. Start firefox 3 
2. Try to open a site
3. notice that it fails to find it
4. set network.dns.disableIPv6 to true
5. it works as expected
Actual Results:  
Unable to browse the web with the default settings (network.dns.disableIPv6 = false)

Expected Results:  
It should work like firefox 2 did i.e just work with ipv4 only ISPs even when network.dns.disableIPv6 is set to false.

	Steve England [:stevee]
	Comment 1 • 17 years ago

Please don't request blocking on bugs that are UNCONFIRMED - thanks.

	drago01 Reporter
	Comment 2 • 17 years ago

(In reply to comment #1)
> Please don't request blocking on bugs that are UNCONFIRMED - thanks.
> 

OK, sorry I wasn't aware of this policy. Will remember this for future reports.

	rektide
	Comment 3 • 17 years ago

a good implementation of failing over to ipv4 when ipv6 fails should also fix https://bugzilla.mozilla.org/show_bug.cgi?id=414197, "some sites cannot be reached when ipv6 enabled".con

	rektide
	Comment 4 • 17 years ago

i too am having this issue, no one had any idea why firefox wasnt working when i asked in #mozilla on irc.mozilla.org or freenode.net.  when i discovered that entering ipv4 ip addresses work, jeremy on irc.mozilla.org told me to disable ipv6 and the problem went away.

how do we confirm this and make it blocking because its freaking terrible.

	rektide
	Comment 5 • 17 years ago

this is quite probably a linux specific issue.  i cannot confirm this, but i think it occur whenver the kernel ipv6 module is loaded and the user's isp is not setup for ipv6, which will be 90% of all linux users (most distros load the ipv6)

proper linkage for "some sites cannot be reached when ipv6 enabled":
https://bugzilla.mozilla.org/show_bug.cgi?id=376226

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 17 years ago

Confirming this just to get this on the radar.

drago01@gmail.com, I assume the Firefox 2 you have that doesn't show the problem is a mozilla.org build, just like the Firefox 3 beta?  If so, would you be willing to try some trunk nightly builds to pin down when this problem appears for you? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ has dated directories; you'd want the ones ending in -trunk.  1.8 branched off in August 2005 or so, which gives us 2.5 years since then; that's about 900 days.  With a binary search, trying 10 or so builds should be able to pin things down to a single day...

Having a one-day regression range would help a lot in terms of being able to locate the change that caused this issue.

	drago01 Reporter
	Comment 7 • 17 years ago

Well I was using the fedora builds. 
I tested with the official builds (2.0, 2.0.0.1, 2.0.0.12, 3b1, 3b2, 3b3) and it seems all off them have the same issue. I tried to every one with a new ~/.mozilla/firefox directory. 
The fedora build seem to work fine even with a new deleted ~/.mozilla/firefox directory.

Added maintainer to CC.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 17 years ago

OK, so not a regression, at least not obviously.

caillon was wondering whether this could be a problem with the build machines statically linking in broken libc function.  I doubt that we do that, but ccing bsmedberg just in case.

drago01@gmail.com, you did verify that the disableIPv6 preference is "false" in th FC build, right?

	Benjamin Smedberg
	Comment 9 • 17 years ago

The mozilla builds don't statically link libc, so I doubt that's an issue.

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 10 • 17 years ago

I'm really at a loss here because Fedora's builds have never (at least that I can remember anyway) patched anything related to IPV6 or Necko...  Maybe 'NSPR_LOG_FILE=foo.log NSPR_LOG_MODULES=nsHttp:5 firefox' on the broken version would provide useful? 

	drago01 Reporter
	Comment 11 • 17 years ago

(In reply to comment #8)
> drago01@gmail.com, you did verify that the disableIPv6 preference is "false" in
> th FC build, right?

Yes its set to false. 

	drago01 Reporter
	Comment 12 • 17 years ago

Here a log created using the official beta3 build.

	Sylvain Pasche
	Comment 14 • 16 years ago

I've been seeing this on Ubuntu Hardy 8.04 64bit too. Any trunk or branch 32bit build fails to resolve hostnames. After some debugging I could isolate that the getaddrinfo() libc call is always failing to resolve anything.

I turns out I was missing the lib32nss-mdns package. The /etc/nsswitch.conf default configuration contains:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

So without the lib32nss-mdns package, the libc can't load the mdns4_minimal module and aborts the resolution.

Reporter, can you check if you have the same issue?

	drago01 Reporter
	Comment 15 • 16 years ago

(In reply to comment #14)
>[...]
> Reporter, can you check if you have the same issue?
> 

good catch! 
That was it. This also explains why the rpm build works.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 16 • 16 years ago

thanks. no firefox bug then - nothing we can do if the glibc setup is broken.

	rektide
	Comment 17 • 16 years ago

I had a similar problem with java the other day.

Why was resolve working if disableIPv6 is true?

	A Mennucc
	Comment 18 • 16 years ago

I have posted this bug into Debian as

http://bugs.debian.org/479144

	Sylvain Pasche
	Comment 19 • 16 years ago

(In reply to comment #17)
> Why was resolve working if disableIPv6 is true?

When disableIPv6 option is set, the getaddrinfo() call is using ai_family = AF_INET in the hints parameter. When disableIPv6 is not set, ai_family = AF_UNSPEC is used.

When using AF_UNSPECT, the resolving is looks like to abort immediately when seeing the [NOTFOUND=return] instruction in nsswitch.conf. Maybe that's a bug in the libc.

In attachment is a small program to demonstrate the issue that I used. You can change the hints.ai_family value to test both cases.

	u279076
	Comment 24 • 15 years ago

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99

Setting network.dns.disableIPv6 to true allows me to browse using a 32-bit version of Firefox on Ubuntu 9.04 64-bit

	Sylvain Pasche
	Comment 25 • 15 years ago

adjusting summary according to Edgar's feedback in order to make this more discoverable.

	Renato S. Yamane
	Comment 27 • 15 years ago

This is not only a Firefox issue, but Thunderbird too.
With network.dns.disableIPv6 (with "false") I can't connect to my mail account.