Closed Bug 679090 Opened 13 years ago Closed 13 years ago

IPv6 broken in Firefox 7


(Core :: Networking: HTTP, defect)

Not set



Tracking Status
firefox5 --- unaffected
firefox6 --- unaffected
firefox7 + fixed
firefox8 + fixed
firefox9 + fixed


(Reporter: etrapani, Assigned: emk)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: push #556699 to aurora and beta [qa-])


(6 files)

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.
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.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Could you make a log as described in

And/or a packet trace from something like wireshark would be useful as well.
Attached file HTTP log
This is the HTTP log.
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.
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.

This one fails.
Component: Networking → Networking: HTTP
QA Contact: networking → networking.http
Depends on: 621558
Keywords: regression
Summary: IPv6 broken in Firefox Aurora → IPv6 broken in Firefox 7
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.
> -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?
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;
Attached patch patchSplinter Review
Pref'ed and default diabled fast fallback
Assignee: nobody → VYV03354
Attachment #555789 - Flags: review?(mcmanus)
Flags: in-litmus?
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.
Attachment #555789 - Flags: review?(mcmanus)
Attachment #555789 - Flags: review?(cbiesinger)
Attachment #555789 - Flags: feedback+
Comment on attachment 555789 [details] [diff] [review]

this makes me sad :(

but short-term this seems like the right fix, unfortunately
Attachment #555789 - Flags: review?(cbiesinger) → review+
Keywords: checkin-needed
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 :-)
Keywords: checkin-needed
OS: Linux → All
Hardware: x86 → All
Version: 7 Branch → Trunk
Closed: 13 years ago
Resolution: --- → FIXED
Comment on attachment 555789 [details] [diff] [review]

This patch is very safe and fix the serious regression about IPv6-only hosts.
Attachment #555789 - Flags: approval-mozilla-beta?
Attachment #555789 - Flags: approval-mozilla-aurora?
Attachment #555789 - Flags: approval-mozilla-beta?
Attachment #555789 - Flags: approval-mozilla-beta+
Attachment #555789 - Flags: approval-mozilla-aurora?
Attachment #555789 - Flags: approval-mozilla-aurora+
Attached patch patch for chekinSplinter Review
updated the author and title per comment 15.
Keywords: checkin-needed
Whiteboard: push #556699 to aurora and beta
QA tracking to verify using test in original comment. Do we want tracking-firefox9 since it was fixed on central (same as other branches)?
Whiteboard: push #556699 to aurora and beta → push #556699 to aurora and beta [qa+]
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.

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?
Whiteboard: push #556699 to aurora and beta [qa+] → push #556699 to aurora and beta [qa?]
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.
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.
I have a sixxs ipv6 tunnel but I never hit the problem because my tunnel adds only 20ms and I never hit the problem.
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).
Whiteboard: push #556699 to aurora and beta [qa?] → push #556699 to aurora and beta [qa-]
Tracking for Firefox Update 9 so if it re-opens we'll notice.
You need to log in before you can comment on or make changes to this bug.