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
FYI, works in Firefox Release (10.0.3)
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
Josh, can someone take a look at this?
Patrick, can you take a look?
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.
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.
What kind of data collection is needed? I can do a tcpdump of a wifi connection attempt later today, if that would be useful.
Taking to remind me to find an owner for this.
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.
I am checking with T-Mobile on timing.
(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?
I don't have a suitable build environment, but I'll certainly be happy to give any test builds a spin.
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.
I'm taking a look at this now for bug 694325.
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.
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?
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://firstname.lastname@example.org/try-android-xul/fennec-11.0a1.en-US.android-arm.apk AFTER 694325: https://email@example.com/try-android-xul/fennec-11.0a1.en-US.android-arm.apk Thanks.
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.
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://firstname.lastname@example.org/try-android-xul/fennec-14.0a1.en-US.android-arm.apk Native UI-based: https://email@example.com/try-android/fennec-14.0a1.en-US.android-arm.apk
Both of those builds work for me in both environments. Nice find!
Confirmed, works fine for me on Galaxy S2 with ICS and native IPv6 on WLAN.
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.
Bernhard, Patrick, Awesome - thanks for testing!
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.
Leaving open until this lands on mozilla-central.