414197 - "Server not found" (DNS/name resolution/lookup failure) when using 32bit Firefox on Ubuntu 64bit - lib32nss-mdns package missing

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[drago01]

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.

Comment 1

[Steve England [:stevee]]

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

Comment 2

[drago01]

(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.

Comment 3

[rektide]

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

Comment 4

[rektide]

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.

Comment 5

[rektide]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

Confirming this just to get this on the radar.

[e-mail], 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.

Comment 7

[drago01]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

[e-mail], you did verify that the disableIPv6 preference is "false" in th FC build, right?

Comment 9

[Benjamin Smedberg]

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

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

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? 

Comment 11

[drago01]

(In reply to comment #8)
> [e-mail], you did verify that the disableIPv6 preference is "false" in
> th FC build, right?

Yes its set to false. 

Comment 12

[drago01]

Attachment: requested log

Here a log created using the official beta3 build.

Comment 14

[Sylvain Pasche]

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?

Comment 15

[drago01]

(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.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 17

[rektide]

I had a similar problem with java the other day.

Why was resolve working if disableIPv6 is true?

Comment 18

[A Mennucc]

I have posted this bug into Debian as

http://bugs.debian.org/479144

Comment 19

[Sylvain Pasche]

Attachment: Sample getaddrinfo() program

(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.

Comment 24

[u279076]

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

Comment 25

[Sylvain Pasche]

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

Comment 27

[Renato S. Yamane]

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