300302 - network.dns.disableIPv6 should be set to true by default (at least on OS/2)

Status: RESOLVED FIXED

(Core :: Networking, enhancement)

Description

[Lewis Rosenthal]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b2) Gecko/20050626 MultiZilla/1.8.0.1n
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b2) Gecko/20050626 MultiZilla/1.8.0.1n

While I was able to do simple DNS lookups from the command line, using nslookup
and dig connected to the default Vodafone (that's who supplies the hotspot here
at the Mercure Newa Dresden, and it runs on a Cisco backbone which is apparently
IPv6 capable) server and received fairly quick results, attempting to browse
pages - even within the captive portal - proved problematic. POP3 and SMTP were
all but impossible.

In desperation, I changed my resolv2 to point to a couple root servers on the
net, and restarted Mozilla. Immediately, I was able to browse, and download and
send outgoing mail. I then changed network.dns.disableIPv6 to true in prefs.js,
restarted the browser, and finally an interface (re)configure from XWLAN
(released and renewed the DHCP params), and I was right on-line again - using
the default Vodafone DNS address.

Additional googling (once online again) turned up numerous tuning tips on the
net (mostly related to Linux platforms) advising this very tweak. A search of
bugzilla for "network.dns.disableIPv6" turned up no less than 200 hits (I
concede that not all of these were specifically related to this setting, but a
good many dealt with slow DNS responses and timeouts).

I suggest defaulting this setting to true, at least until the kinks have been
ironed out of the logic, or, if this is indeed related to OS/2's lack of IPv6
functionality, then leaving this as the default on OS/2 until such time as we
have a v6-capable IP stack on OS/2.

Reproducible: Always

Steps to Reproduce:
1. Connect to a DHCP server which assigns the primary DNS address of an IPv6
host or set the address manually in resolv2.
2. Attempt to open a web page which has not been cached.
3. Edit prefs.js to set network.dns.disableIPv6 to true.
4. Close and restart Mozilla.
5. Repeat step 2.
Actual Results:  
After step 2, blank page, "looking up host [...]" in status bar, or simply
timeout attempting to contact host messages appear in window until
network.dns.disableIPv6 is set to true in prefs.js. Afterwards, hosts resolv and
pages open as they should. 

Expected Results:  
Hosts should resolve and pages should open without undue delay (i.e., DNS
lookups in Mozilla should take no longer than lookups via dig or nslookup).
Pages should load as rapidly as possible upon resolving an address.

This also affects POP3 and SMTP, and I would expect IMAP as well as other
browser-type protocols (FTP, etc.).

Comment 1

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

those test results seem to indicate that the DNS server you used didn't handle
AAAA queries well, not that OS/2 has a general problem with it...

Comment 2

[Lewis Rosenthal]

(In reply to comment #1)

True, however, upon rebooting to W2K Advanced Server SP4, I had full
functionality - with no prefs.js modification - under Moz, FF, and Tbird (all
versions contemporary with what I'm running under OS/2). This leads me to
believe that while this may indeed be a server-side problem, Windows (at least)
does not seem to be affected.

Comment 3

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

that version of windows may not have IPv6 support (I am not sure if it comes
with the OS or if it needs extra installation)

Comment 4

[Lewis Rosenthal]

(In reply to comment #3)

The installation I have of W2K Adv Server on my ThinkPad does not have IPv6
enabled. So, essentially, the stack in that is no more capable than the one
under OS/2 (okay, so it's Windows and it's terribly unstable in comparison to
OS/2's IP stack, but for these purposes, they're both IPv4-capable ONLY).

All I'm saying is that for OS/2, this pref should be defaulted to true, as it
took me two days of troubleshooting - at 30 Euros per day for Wi-Fi access in
the hotel - to figure out why I couldn't get anywhere under OS/2 while I could
under Windows. Perhaps when the logic is working better (i.e., more tolerant of
broken servers), we can default this to false again.

Lewis

Comment 5

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

oh, OS/2 does not support ipv6?

Comment 6

[Lewis Rosenthal]

(In reply to comment #5)
> oh, OS/2 does not support ipv6?

Nope. The current IP stack is based on an older AIX stack which did not support
IPv6. AFAIK, there is no plan to support IPv6 on OS/2, either (but we can hope...). 

Lewis

Comment 7

[Mike Kaply [:mkaply]]

Attachment: Disable ipv6 for OS/2

Comment 8

[Lewis Rosenthal]

What a guy! Thanks, Mike. ;-)

I suppose we should wait to change the status of this until we actually build
(test) with the code you've patched? (Sorry for the newbie question...I've never
gotten this far with one of my submissions.)

Lewis

Comment 9

[Mike Kaply [:mkaply]]

Not really any testing required - we know it will work :)

Comment 10

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

Comment on attachment 189003 [details] [diff] [review]
Disable ipv6 for OS/2

looks like this patch contains some unrelated changes to font prefs...

Comment 11

[Mike Kaply [:mkaply]]

interesting. My editor horked that up...

Comment 12

[Peter Weilbacher]

Attachment: Disable ipv6 for OS/2 (clean patch)

As a reminder to Mike here is the a new, clean patch without the font changes.
I think this should also go into the 1.7 and aviary branches? Not sure who
reviews such a thing.

Comment 13

[Lewis Rosenthal]

Dumb question (please pardon the simplicity of this) which may be rhetorical:
Upon updating Mozilla, prefs.js does not get updated with the changed
information, correct? IOW, if a user has Mozilla 1.7.3 installed and later
upgrades to 1.7.12, and assuming this change has been checked in, the user's
prefs.js do not change. Therefor, a manual change is still required unless one
creates an entirely new profile (in which case, the new profile defaults will be
as provided in the distro).

I came across this problem once again, when my brother was using a Wayport hotspot.

Lewis

Comment 14

[James Ross]

Luckly, it isn't entirely like that. When Mozilla saves prefs.js, it omits any
preferences that have their (current) default value [1]. Thus, if the defaults
change, the use will get the new defaults just fine, so long as they haven't
changed it themselves to something else.

[1] There are a few issues with the "omit default values" idea, documented in
other bugs, but I'll spare this bug from them. :)

Comment 15

[Lewis Rosenthal]

(In reply to comment #14)
> Luckly, it isn't entirely like that. When Mozilla saves prefs.js, it omits any
> preferences that have their (current) default value [1]. Thus, if the defaults
> change, the use will get the new defaults just fine, so long as they haven't
> changed it themselves to something else.

Ah, thank you, James. This indeed makes sense (particularly in this case, where
the only change to the default would be to correct the condition in the first
place). Good information. Of course, we may need to deal with the reverse
situation at some point in the future, is we ever get an IPv6-aware stock on OS/2.

Lewis

Comment 16

[Boris Zbarsky [:bzbarsky]]

So should that patch be checked in?  Esp. for 1.8?

Comment 17

[Mike Kaply [:mkaply]]

Comment on attachment 192174 [details] [diff] [review]
Disable ipv6 for OS/2 (clean patch)

r=mkaply

Requesting 1.8 approval - OS/2 only

Comment 18

[Mike Kaply [:mkaply]]

Fix checked in.

Note this was not in ff rc1.