When using Firefox 7.0a2 (2011-08-13) I cannot visit any IPv6 site (ipv.google.com, ipv6-test.com, ...). 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 ipv6-test.com (or ipv6.google.com) 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.

Could you make a log as described in https://developer.mozilla.org/en/HTTP_Logging? And/or a packet trace from something like wireshark would be useful as well.

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. [1] http://hg.mozilla.org/mozilla-central/raw-rev/06815ff84678

This one fails.

This one works.

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 ent=ipv6.google.com 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 [ci=...ipv6.google.com:80 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? (804b001e = NS_ERROR_UNKNOWN_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;

Pref'ed and default diabled fast fallback

Comment on attachment 555789 [details] [diff] [review] patch 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 on attachment 555789 [details] [diff] [review] patch this makes me sad :( but short-term this seems like the right fix, unfortunately

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: http://blog.bonardo.net/2010/06/22/so-youre-about-to-use-checkin-needed Thanks :-)

Comment on attachment 555789 [details] [diff] [review] patch This patch is very safe and fix the serious regression about IPv6-only hosts.

updated the author and title per comment 15.

http://hg.mozilla.org/releases/mozilla-aurora/rev/a9c6435f143c http://hg.mozilla.org/releases/mozilla-beta/rev/5edc37564deb

QA tracking to verify using test in original comment. Do we want tracking-firefox9 since it was fixed on central (same as other branches)?

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. [1] http://hg.mozilla.org/mozilla-central/rev/06815ff84678

Using ipv6-test.com 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?

You might need to pass your connection through an IPv6 tunnel such as those provided by http://tunnelbroker.net/ . 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).

Tracking for Firefox Update 9 so if it re-opens we'll notice.