Closed Bug 679090 Opened 11 years ago Closed 11 years ago
IPv6 broken in Firefox 7
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.
11 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.
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  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
This one fails.
This one works.
Component: Networking → Networking: HTTP
QA Contact: networking → networking.http
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
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
Closed: 11 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.
updated the author and title per comment 15.
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)?
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-]
You need to log in before you can comment on or make changes to this bug.