IPv6 broken in Firefox 7

RESOLVED FIXED in Firefox 7

Status

()

Core
Networking: HTTP
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Eduardo Trápani, Assigned: emk)

Tracking

(Blocks: 1 bug, {regression})

Trunk
mozilla9
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus ?

Firefox Tracking Flags

(firefox5 unaffected, firefox6 unaffected, firefox7+ fixed, firefox8+ fixed, firefox9+ fixed)

Details

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

Attachments

(6 attachments)

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
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 https://developer.mozilla.org/en/HTTP_Logging?

And/or a packet trace from something like wireshark would be useful as well.
(Reporter)

Comment 3

6 years ago
Created attachment 553451 [details]
HTTP log

This is the HTTP log.
(Reporter)

Comment 4

6 years ago
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.
(Reporter)

Comment 5

6 years ago
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
(Reporter)

Comment 6

6 years ago
Created attachment 553469 [details]
HTTP log (mozilla-central, with code from Bug 621558)

This one fails.
(Reporter)

Comment 7

6 years ago
Created attachment 553471 [details]
HTTP log (mozilla-central, *without* the code from Bug 621558)

This one works.

Updated

6 years ago
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
(Reporter)

Comment 8

6 years ago
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.

Updated

6 years ago
tracking-firefox7: --- → +
(Assignee)

Comment 9

6 years ago
> -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)
Duplicate of this bug: 680466
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: --- → ?
(Assignee)

Comment 12

6 years ago
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)
Flags: in-litmus?
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.
Attachment #555789 - Flags: review?(mcmanus)
Attachment #555789 - Flags: review?(cbiesinger)
Attachment #555789 - Flags: feedback+
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+
(Assignee)

Updated

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

Thanks :-)
Keywords: checkin-needed
OS: Linux → All
Hardware: x86 → All
Version: 7 Branch → Trunk
http://hg.mozilla.org/integration/mozilla-inbound/rev/61f9ec712a1c
Target Milestone: --- → mozilla9
http://hg.mozilla.org/mozilla-central/rev/61f9ec712a1c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

6 years ago
Comment on attachment 555789 [details] [diff] [review]
patch

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?

Updated

6 years ago
Attachment #555789 - Flags: approval-mozilla-beta?
Attachment #555789 - Flags: approval-mozilla-beta+
Attachment #555789 - Flags: approval-mozilla-aurora?
Attachment #555789 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 19

6 years ago
Created attachment 556699 [details] [diff] [review]
patch for chekin

updated the author and title per comment 15.
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
Whiteboard: push #556699 to aurora and beta

Comment 20

6 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/a9c6435f143c
http://hg.mozilla.org/releases/mozilla-beta/rev/5edc37564deb
status-firefox7: affected → fixed
status-firefox8: affected → fixed
tracking-firefox8: ? → +
Keywords: checkin-needed
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+]
(Reporter)

Comment 22

6 years ago
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?
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.