Last Comment Bug 739600 - No IPv6 connections in Fennec 12+
: No IPv6 connections in Fennec 12+
: regression
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: ARM Android
-- normal with 1 vote (vote)
: mozilla14
Assigned To: Steve Workman [:sworkman] (INACTIVE)
: Patrick McManus [:mcmanus]
Depends on:
  Show dependency treegraph
Reported: 2012-03-27 07:51 PDT by Bernhard Schmidt
Modified: 2012-04-21 07:40 PDT (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Adds "#define INET6" 1 to getaddrinfo.c (580 bytes, patch)
2012-04-20 10:17 PDT, Steve Workman [:sworkman] (INACTIVE)
jduell.mcbugs: review+
Details | Diff | Splinter Review

Description User image Bernhard Schmidt 2012-03-27 07:51:21 PDT
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 ( or IPv6-only site (

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"). This is regardless of the setting network.dns.disableIPv6 (set to false) or (defaults to true, also tried false)

Expected results:

Access via IPv6
Comment 1 User image Bernhard Schmidt 2012-03-27 07:54:17 PDT
FYI, works in Firefox Release (10.0.3)
Comment 2 User image Patrick "Jima" Laughton 2012-03-28 07:25:19 PDT
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 User image JP Rosevear [:jpr] 2012-04-04 19:48:54 PDT
Josh, can someone take a look at this?
Comment 4 User image Josh Aas 2012-04-05 07:42:08 PDT
Patrick, can you take a look?
Comment 5 User image Patrick McManus [:mcmanus] 2012-04-05 07:52:13 PDT
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 User image Honza Bambas (:mayhemer) 2012-04-05 12:12:48 PDT
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 User image Patrick "Jima" Laughton 2012-04-05 13:12:11 PDT
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 User image Josh Aas 2012-04-11 13:37:17 PDT
Taking to remind me to find an owner for this.
Comment 9 User image Josh Aas 2012-04-13 12:44:09 PDT
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 User image Erin Lancaster [:elan] 2012-04-16 12:50:20 PDT
I am checking with T-Mobile on timing.
Comment 11 User image JP Rosevear [:jpr] 2012-04-17 17:43:47 PDT
(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 User image Patrick "Jima" Laughton 2012-04-17 20:12:41 PDT
I don't have a suitable build environment, but I'll certainly be happy to give any test builds a spin.
Comment 13 User image Kevin Brosnan [:kbrosnan] 2012-04-17 23:41:24 PDT
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
2011-12-06 XUL nightly works
2011-12-07 XUL nightly is broken

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 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-18 10:00:32 PDT
I'm taking a look at this now for bug 694325.
Comment 15 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-19 09:18:03 PDT
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 User image Brad Lassey [:blassey] (use needinfo?) 2012-04-19 12:53:35 PDT
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 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-19 13:26:22 PDT
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:

AFTER 694325:

Comment 18 User image Patrick "Jima" Laughton 2012-04-19 18:53:37 PDT

 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 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-19 22:07:08 PDT
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.


Native UI-based:
Comment 20 User image Patrick "Jima" Laughton 2012-04-19 23:10:43 PDT
Both of those builds work for me in both environments.  Nice find!
Comment 21 User image Bernhard Schmidt 2012-04-20 00:03:36 PDT
Confirmed, works fine for me on Galaxy S2 with ICS and native IPv6 on WLAN.
Comment 22 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-20 10:17:29 PDT
Created attachment 617030 [details] [diff] [review]
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 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-20 10:18:53 PDT
Bernhard, Patrick,
Awesome - thanks for testing!
Comment 24 User image Jason Duell [:jduell] (needinfo me) 2012-04-20 13:19:14 PDT
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 User image Steve Workman [:sworkman] (INACTIVE) 2012-04-20 13:32:26 PDT
Thanks Jason.
Comment 26 User image Matt Brubeck (:mbrubeck) 2012-04-20 13:37:48 PDT
Leaving open until this lands on mozilla-central.
Comment 27 User image Phil Ringnalda (:philor) 2012-04-20 20:02:26 PDT
Comment 28 User image Patrick McManus [:mcmanus] 2012-04-21 07:40:51 PDT
awesome steve

Note You need to log in before you can comment on or make changes to this bug.