739600 - No IPv6 connections in Fennec 12+

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Bernhard Schmidt]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120313141247

Steps to reproduce:

Install Firefox Beta (12.0) or Aurora (13.0a2 2012-03-27) on a stock Samsung Galaxy S2 (Android 2.3.6), which has native and working IPv6 connectivity on WLAN (verified with both the vanilla Android browser and Dolphin)

Open a dual-stack site that shows the client address (http://www.sixy.ch) or IPv6-only site (http://ping6.lrz.de)


Actual results:

The dual-stack site was accessed using IPv4, the IPv6-only site could not be accessed ("Firefox can't find the server at ping6.lrz.de"). This is regardless of the setting network.dns.disableIPv6 (set to false) or network.http.fast-fallback-to-IPv4 (defaults to true, also tried false)


Expected results:

Access via IPv6

Comment 1

[Bernhard Schmidt]

FYI, works in Firefox Release (10.0.3)

Comment 2

[Patrick "Jima" Laughton]

I can confirm Bernhard's test case for both products.  On T-Mobile's IPv6-only (+NAT64/DNS64) beta APN, this results in connection timeouts to any site -- IPv6 or IPv4 -- due to the lack of IPv4 transit on which to fall back.  Firefox 10.0.3 and the stock Android browser both support IPv6 sites (and IPv4 sites via NAT64/DNS64 connectivity) just fine.

Tested on an LG myTouch (LG-C800) running Android 2.3.4.  User agents collected via the IPv4-only APN:

Mozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0a2

Mozilla/5.0 (Android; Mobile; rv:12.0) Gecko/12.0 Firefox/12.0 Fennec/12.0

Comment 3

[JP Rosevear [:jpr]]

Josh, can someone take a look at this?

Comment 4

[Josh Aas]

Patrick, can you take a look?

Comment 5

[Patrick McManus [:mcmanus]]

I don't have any v6 connectivity right now... honza did last I checked, but that might have been a desktop tunnel which isn't going to help a lot here.

Comment 6

[Honza Bambas (:mayhemer)]

I unfortunately don't have ipv6 capable provider.  I only was able to tunnel using MS Terredo virtual adapter.  So, no simple way to check on this bug for me right now.

Comment 7

[Patrick "Jima" Laughton]

What kind of data collection is needed?  I can do a tcpdump of a wifi connection attempt later today, if that would be useful.

Comment 8

[Josh Aas]

Taking to remind me to find an owner for this.

Comment 9

[Josh Aas]

Possibly a regression from bug 684893?

Patrick, I think you're the best bet we have to put this bug on the schedule soon. You mentioned you could set up the necessary IPv6 environment, though it might take you a couple of weeks to get to it.

Comment 10

[Erin Lancaster [:elan]]

I am checking with T-Mobile on timing.

Comment 11

[JP Rosevear [:jpr]]

(In reply to Josh Aas (Mozilla Corporation) from comment #9)
> Possibly a regression from bug 684893?
> 
> Patrick, I think you're the best bet we have to put this bug on the schedule
> soon. You mentioned you could set up the necessary IPv6 environment, though
> it might take you a couple of weeks to get to it.

If we have a suspicion here its this bug, can we get a try build with the patch removed and maybe the original commenter can test?

Comment 12

[Patrick "Jima" Laughton]

I don't have a suitable build environment, but I'll certainly be happy to give any test builds a spin.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

This is broken on XUL and Native. On xul the regression range includes the birch merge however I think that may be unrelated as the birch 2011-12-06 build works. 

2011-12-06 birch nightly works
http://hg.mozilla.org/projects/birch/rev/a7fb88bd5148
2011-12-06 XUL nightly works
http://hg.mozilla.org/mozilla-central/rev/fafaf614791f
2011-12-07 XUL nightly is broken
http://hg.mozilla.org/mozilla-central/rev/658fad825c36

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fafaf614791f&tochange=658fad825c36

Looking at the non-birch checkins I see bug 694325 -  Android DNS is single threaded this is a very likely candidate for the breakage.

Comment 14

[Steve Workman [:sworkman] (INACTIVE)]

I'm taking a look at this now for bug 694325.

Comment 15

[Steve Workman [:sworkman] (INACTIVE)]

I'm having issues backing out the patches for bug 694325 and bug 684893, so please bear with me. They've been in there long enough that it seems like other patches are dependent on them.  I'll try to back out from an earlier revision today.

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

Are we sure that backing out is the right solution here? As I understand it multi-threaded DNS is a big performance win. Can we try to fix this instead?

Comment 17

[Steve Workman [:sworkman] (INACTIVE)]

Brad, you're right, it is a big performance win. At this stage it's just about confirming that it is that patch causing the problem. Should it be confirmed, then yes, my first approach will be to fix it.

Here are two XUL builds I managed to get working (try doesn't work well with older android builds from around that time. It complains that "mobile/android" is not recgonized). These are just before and just after the patch for 694325 landed. Patrick "Jima", please try them out if you can.

BEFORE 694325: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-b84bf5420f0d/try-android-xul/fennec-11.0a1.en-US.android-arm.apk

AFTER 694325: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-33f50a5963d9/try-android-xul/fennec-11.0a1.en-US.android-arm.apk

Thanks.

Comment 18

[Patrick "Jima" Laughton]

Steve,

 Thank you for those builds.  As semi-expected, b84bf5420f0d works fine, and 33f50a5963d9 exhibits the problem described by Bernhard and myself above.  My test environment includes both the T-Mobile IPv6/NAT64/DNS64 connectivity on my phone, as well as dual-stack wifi on both my phone and tablet.

Comment 19

[Steve Workman [:sworkman] (INACTIVE)]

Thanks Patrick - I did some more work in the meantime and discovered a missing #define. Could you also try the following build(s) please? Hopefully it will fix the problem.  It is a recent build of mozilla-central with the #define.

XUL-based: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-708d0b954210/try-android-xul/fennec-14.0a1.en-US.android-arm.apk

Native UI-based: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-708d0b954210/try-android/fennec-14.0a1.en-US.android-arm.apk

Comment 20

[Patrick "Jima" Laughton]

Both of those builds work for me in both environments.  Nice find!

Comment 21

[Bernhard Schmidt]

Confirmed, works fine for me on Galaxy S2 with ICS and native IPv6 on WLAN.

Comment 22

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: Adds "#define INET6" 1 to getaddrinfo.c

Adds "#define INET6 1" to getaddrinfo.c. This file was pulled from Android source in bug 694325 to provide thread safeness to getaddrinfo(), but IPv6 support was unwittingly disabled by not explicitly defining INET6 in the code. Adding the #define enables IPv6 addresses to be obtained through DNS.

Comment 23

[Steve Workman [:sworkman] (INACTIVE)]

Bernhard, Patrick,
Awesome - thanks for testing!

Comment 24

[Jason Duell]

Comment on attachment 617030 [details] [diff] [review]
Adds "#define INET6" 1 to getaddrinfo.c

Review of attachment 617030 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for digging into this, Steve.  Nice that the fix is this simple.

Comment 25

[Steve Workman [:sworkman] (INACTIVE)]

Thanks Jason.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a12cbe3bf045

Comment 26

[Matt Brubeck (:mbrubeck)]

Leaving open until this lands on mozilla-central.

Comment 27

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/a12cbe3bf045

Comment 28

[Patrick McManus [:mcmanus]]

awesome steve