Last Comment Bug 679090 - IPv6 broken in Firefox 7
: IPv6 broken in Firefox 7
push #556699 to aurora and beta [qa-]
: regression
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla9
Assigned To: Masatoshi Kimura [:emk]
: Patrick McManus [:mcmanus]
: 680466 (view as bug list)
Depends on: 621558
Blocks: IPv6
  Show dependency treegraph
Reported: 2011-08-15 12:38 PDT by Eduardo Trápani
Modified: 2012-05-04 01:15 PDT (History)
19 users (show)
mozillamarcia.knous: in‑litmus?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

HTTP log (142.21 KB, text/plain)
2011-08-16 06:36 PDT, Eduardo Trápani
no flags Details
Wireshark capture, csv format (1.20 KB, text/csv)
2011-08-16 06:40 PDT, Eduardo Trápani
no flags Details
HTTP log (mozilla-central, with code from Bug 621558) (48.40 KB, text/plain)
2011-08-16 07:47 PDT, Eduardo Trápani
no flags Details
HTTP log (mozilla-central, *without* the code from Bug 621558) (465.91 KB, text/plain)
2011-08-16 07:48 PDT, Eduardo Trápani
no flags Details
patch (5.51 KB, patch)
2011-08-25 10:58 PDT, Masatoshi Kimura [:emk]
cbiesinger: review+
mcmanus: feedback+
asa: approval‑mozilla‑aurora+
asa: approval‑mozilla‑beta+
Details | Diff | Splinter Review
patch for chekin (3.50 KB, patch)
2011-08-29 16:02 PDT, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review

Description User image Eduardo Trápani 2011-08-15 12:38:22 PDT
When using Firefox 7.0a2 (2011-08-13) I cannot visit any IPv6 site (,, ...).  I get "server not found" message.  If I sniff the traffic with wireshark I see that the names are resolved *and* the tcp connections established.  For some reason, as soon as they are established Firefox closes them.

With 6.0b5, 5.01 and 3.5.16 everything works perfectly.  

I have on the same host the four versions, 7.0a2, 6.0b5 and 5.01.  It is a Debian that also has Firefox (Iceweasel) 3.5.16 In order to run the test I do:

LD_LIBRARY_PATH=. ./firefox (or

The host has dual stack.  I built firefox from mozilla-central (74324:73c4423aafee) and the result is the same.
Comment 1 User image Eduardo Trápani 2011-08-15 13:56:58 PDT
Update: if I reload many times, eventually the IPv6 sites start to work.  The weird thing is, with the other versions there isn't a problem, ever.  Maybe Bug 621558 has something to do with it?  Because all tested hosts are either IPv6 only or they have IPv6 and private (not natted) IPv4 addresses.
Comment 2 User image Christian :Biesinger (don't email me, ping me on IRC) 2011-08-15 14:17:09 PDT
Could you make a log as described in

And/or a packet trace from something like wireshark would be useful as well.
Comment 3 User image Eduardo Trápani 2011-08-16 06:36:49 PDT
Created attachment 553451 [details]
HTTP log

This is the HTTP log.
Comment 4 User image Eduardo Trápani 2011-08-16 06:40:16 PDT
Created attachment 553454 [details]
Wireshark capture, csv format

I didn't know if I should include all the details (with the information about the network topology).  If you need more info I just say so.  Remember that the same command run from the other Firefox versions on the same machine work flawlessly so I guess we can rule out the ipv6 stack.
Comment 5 User image Eduardo Trápani 2011-08-16 07:43:14 PDT
I can now confirm, if I reverse the patch in Bug 621558 [1] and rebuild, then mozilla-central (8.01a) does now show that problem.  If I apply it again then the problem reappears.

Comment 6 User image Eduardo Trápani 2011-08-16 07:47:03 PDT
Created attachment 553469 [details]
HTTP log (mozilla-central, with code from Bug 621558)

This one fails.
Comment 7 User image Eduardo Trápani 2011-08-16 07:48:41 PDT
Created attachment 553471 [details]
HTTP log (mozilla-central, *without* the code from Bug 621558)

This one works.
Comment 8 User image Eduardo Trápani 2011-08-16 08:35:04 PDT
Ok, I now think I understand what is going on.  See Bug 621558 comment #16.  I don't know how to go on from here though.
Comment 9 User image Masatoshi Kimura [:emk] 2011-08-16 23:26:32 PDT
> -1301283984[b7a42ab0]: nsSocketOutputStream::OnSocketReady [this=adde348c cond=804b001e]
> -1301283984[b7a42ab0]: nsHalfOpenSocket::OnOutputStreamReady [this=ad7b9240 backup]
> -1301283984[b7a42ab0]: Creating nsHttpConnection @ab310500
> -1301283984[b7a42ab0]: nsHalfOpenSocket::OnOutputStreamReady Created new nshttpconnection ab310500
> -1301283984[b7a42ab0]: nsHttpConnection::Init [this=ab310500 transport=adde338c instream=adde346c outstream=adde348c]
> -1301283984[b7a42ab0]: Reset callbacks for secinfo=0 callbacks=ab310514
> -1301283984[b7a42ab0]: nsHttpConnectionMgr::DispatchTransaction [ trans=adcf9da0 caps=21 conn=ab310500]
> -1301283984[b7a42ab0]: nsHttpConnection::Activate [this=ab310500 trans=adcf9da0 caps=21]
> -1301283984[b7a42ab0]: nsHttpConnection::OnSocketWritable [this=ab310500]
> -1301283984[b7a42ab0]:   writing transaction request stream
> -1301283984[b7a42ab0]: nsSocketOutputStream::Write [this=adde348c count=519]
> -1301283984[b7a42ab0]:   ReadSegments returned [rv=0 read=0 sock-cond=804b001e]
Why nsHalfOpenSocket::OnOutputStreamReady trys to initialize a http connection
even if a backup connection has failed to resolve a host?
Comment 10 User image Patrick McManus [:mcmanus] 2011-08-22 13:02:28 PDT
*** Bug 680466 has been marked as a duplicate of this bug. ***
Comment 11 User image Patrick McManus [:mcmanus] 2011-08-22 13:04:53 PDT
Biesi - what do you think should be done here? 

As 621558 is not quite ready for prime time, I would suggest disabling it for now with a pref and just adding that pref to

+    if (isBackup)
+        tmpFlags |= nsISocketTransport::DISABLE_IPV6;
Comment 12 User image Masatoshi Kimura [:emk] 2011-08-25 10:58:32 PDT
Created attachment 555789 [details] [diff] [review]

Pref'ed and default diabled fast fallback
Comment 13 User image Patrick McManus [:mcmanus] 2011-08-25 11:16:18 PDT
Comment on attachment 555789 [details] [diff] [review]

Thanks for the patch!

This is biesi's feature, so I'm going to make sure he gets a shot at reviewing it. It makes sense to me at this juncture.
Comment 14 User image Christian :Biesinger (don't email me, ping me on IRC) 2011-08-26 11:08:08 PDT
Comment on attachment 555789 [details] [diff] [review]

this makes me sad :(

but short-term this seems like the right fix, unfortunately
Comment 15 User image Ed Morley [:emorley] 2011-08-27 03:54:13 PDT
In my queue with a few other bits that are being sent to try first and then onto inbound.

To save time for future patches, could you set your hgrc to include the author automatically & include a commit message, along the lines of:

Thanks :-)
Comment 17 User image Ed Morley [:emorley] 2011-08-28 13:33:38 PDT
Comment 18 User image Masatoshi Kimura [:emk] 2011-08-29 07:08:48 PDT
Comment on attachment 555789 [details] [diff] [review]

This patch is very safe and fix the serious regression about IPv6-only hosts.
Comment 19 User image Masatoshi Kimura [:emk] 2011-08-29 16:02:08 PDT
Created attachment 556699 [details] [diff] [review]
patch for chekin

updated the author and title per comment 15.
Comment 21 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-09 15:38:50 PDT
QA tracking to verify using test in original comment. Do we want tracking-firefox9 since it was fixed on central (same as other branches)?
Comment 22 User image Eduardo Trápani 2011-09-21 08:34:05 PDT
I don't understand why you wrap and ship broken code and add a preference instead of removing it[1] until it's fixed.

I think the patch should be removed for aurora and beta.  We could have it in trunk and test it until it is mature enough.  Tucking it behind a default-false preference will simply make it fall out everybody's radar.

The current implementation does not work.  Why keep it?  You know that 300ms can very well be the *optimal* round-trip to the DNS server when it is, network wise, some thousand kilometers away, or has a satellite hop in between or whatever.

Comment 23 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-26 20:20:09 PDT
Using it reports my internet connection as "incompatible". Does this mean the bug is not fixed or that I will be unable to verify the fix?
Comment 24 User image Emanuel Hoogeveen [:ehoogeveen] 2011-09-27 01:55:07 PDT
You might need to pass your connection through an IPv6 tunnel such as those provided by . If using their client-side setup instructions, note that if you're on a network using NAS, you need to replace your external IPv4-address (in the commands shown) with the internal IPv4-address for your computer.

Using a tunnel and an IPv6-compatible DNS provider (OpenDNS in my case), IPv6 works fine for me in the nightlies.
Comment 25 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-27 12:25:20 PDT
That seems a little bit complicated just to verify a fix. I would much rather prefer someone who is already set up to reproduce this bug verify the fix.
Comment 26 User image Matthias Versen [:Matti] 2011-09-27 13:56:00 PDT
I have a sixxs ipv6 tunnel but I never hit the problem because my tunnel adds only 20ms and I never hit the problem.
Comment 27 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-27 14:04:02 PDT
Marking qa- as QA cannot verify this fix. Someone who could reproduce this bug originally, please verify the fix in Firefox 7 and 8 (and perhaps 9 if it gets approval).
Comment 28 User image Christopher Blizzard (:blizzard) 2011-09-27 14:54:34 PDT
Tracking for Firefox Update 9 so if it re-opens we'll notice.

Note You need to log in before you can comment on or make changes to this bug.