142.21 KB, text/plain
1.20 KB, text/csv
48.40 KB, text/plain
465.91 KB, text/plain
5.51 KB, patch
|Details | Diff | Splinter Review|
3.50 KB, patch
|Details | Diff | Splinter Review|
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.
8 years ago
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
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.
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.
I can now confirm, if I reverse the patch in Bug 621558  and rebuild, then mozilla-central (8.01a) does now show that problem. If I apply it again then the problem reappears.  http://hg.mozilla.org/mozilla-central/raw-rev/06815ff84678
Created attachment 553469 [details] HTTP log (mozilla-central, with code from Bug 621558) This one fails.
Created attachment 553471 [details] HTTP log (mozilla-central, *without* the code from Bug 621558) This one works.
Component: Networking → Networking: HTTP
QA Contact: networking → networking.http
Depends on: 621558
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 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;
status-firefox8: --- → affected
tracking-firefox8: --- → ?
Created attachment 555789 [details] [diff] [review] patch Pref'ed and default diabled fast fallback
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #555789 - Flags: review?(mcmanus)
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
Attachment #555789 - Flags: review?(cbiesinger) → review+
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 :-)
OS: Linux → All
Hardware: x86 → All
Version: 7 Branch → Trunk
Target Milestone: --- → mozilla9
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 555789 [details] [diff] [review] patch This patch is very safe and fix the serious regression about IPv6-only hosts.
Created attachment 556699 [details] [diff] [review] patch for chekin updated the author and title per comment 15.
Whiteboard: push #556699 to aurora and beta
status-firefox7: affected → fixed
status-firefox8: affected → fixed
tracking-firefox8: ? → +
QA tracking to verify using test in original comment. Do we want tracking-firefox9 since it was fixed on central (same as other branches)?
status-firefox9: --- → fixed
tracking-firefox9: --- → ?
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 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.  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?
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 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).
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.
tracking-firefox9: ? → +
You need to log in before you can comment on or make changes to this bug.