from comments added to bug 205726: >------- Additional Comment #79 From Lorenzo Colitti 2003-09-12 17:20 ------- > >IPv6 now works! Great work Darin! > >There is still a minor problem, though: Moz doesn't fall back to IPv4 if it >gets an error using IPv6. I used Firebird 20030912 on Windows XP and tried to >connect to a host that has an IPv6 address but does not have an IPv6-capable >web server. Firebird tries the IPv6 address and gets a connection refused, but >instead of trying IPv4, it displays a connection refused error message. > >In the nsSocketTransport log it says "trying again with next ip address", but >the address it tries is the same IPv6 address that it failed to connect to on >the previous try. > >This is particularly serious if the proxy server you have configured has an >IPv6 address: in this case, nothing will work. > >Should I open another bug for this? In the meantime I'll attach the nspr log. > > >------- Additional Comment #80 From Lorenzo Colitti 2003-09-12 17:29 ------- > >Created an attachment (id=131369) >log showing failure of ipv6->ipv4 fallback > >Note the fact that the log says "trying again with next ip address" but it >tries the same IPv6 address again instead of trying the IPv4 address. It might >be that getaddrinfo() is at fault here; is there any way of finding out what it >is returning?
Lorenzo: hmm... i no longer have access to a WinXP box. i ran "TestDNS www.yahoo.com" on my Linux box and it spit out a list of different IP addresses, which tells me that the basic address enumeration code is working. do you happen to have a debug mozilla build handy? if so, could you try running TestDNS to see what output you get? if you don't have a debug build, let me know. i should be able to post a copy of TestDNS that you can just drop into a mozilla nightly build directory and run. thanks!
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
FreeBSD 2003-09-13-06 PDT CVS build and 2003091203/MacOSX can't connect to anywhere. These problems are same of this? If so, this is probably BLOCKER (for *BSD).
The FreeBSD and Mac OS X problem is a different problem (bug 219104).
Ok, this is what TestDNS says (many thanks to Matti for providing a binary!) D:\[...]\bin>TestDNS.exe www.uniroma3.6net.garr.it main thread sleeping for 10 seconds... 1: OnLookupComplete called [host=www.uniroma3.6net.garr.it status=0 ai=00A20920] 1: canonname=dns.uniroma3.6net.garr.it 1: => 2001:760:4::1 1: OnLookupComplete called [host=www.uniroma3.6net.garr.it status=0 ai=00A1EDB8] 1: canonname=dns.uniroma3.6net.garr.it 1: => 2001:760:4::1 main thread sleeping for 10 seconds... shutting down main thread... Note that it only finds the IPv6 address, but the host also has an IPv4 address. Believe it or not, this is because it's a CNAME record! Indeed, if I ask for dns.uniroma3.6net.garr.it, which is what www.uniroma3.6net.garr.it is a CNAME for, I get both addresses back: D:\[...]\bin>testdns dns.uniroma3.6net.garr.it main thread sleeping for 10 seconds... 1: OnLookupComplete called [host=dns.uniroma3.6net.garr.it status=0 ai=00A20920] 1: canonname=dns.uniroma3.6net.garr.it 1: => 2001:760:4::1 1: => 18.104.22.168 1: OnLookupComplete called [host=dns.uniroma3.6net.garr.it status=0 ai=00A1EDB8] 1: canonname=dns.uniroma3.6net.garr.it 1: => 2001:760:4::1 1: => 22.214.171.124 main thread sleeping for 10 seconds... shutting down main thread... Is this getaddrinfo()'s fault?
Lorenzo, could you run TestDNS on www.6bone.net and 6bone.net?
Same results: for www.6bone.net, which is a CNAME of 6bone.net, I get only the IPv6 address. For 6bone.net I get both the IPv6 and the IPv4 address: D:\[...]\bin>testdns www.6bone.net main thread sleeping for 10 seconds... 1: OnLookupComplete called [host=www.6bone.net status=0 ai=00A1ED90] 1: canonname=6bone.net 1: => 3ffe:b00:c18:1::10 1: OnLookupComplete called [host=www.6bone.net status=0 ai=00A868F8] 1: canonname=6bone.net 1: => 3ffe:b00:c18:1::10 main thread sleeping for 10 seconds... shutting down main thread... D:\[...]\bin>testdns 6bone.net main thread sleeping for 10 seconds... 1: OnLookupComplete called [host=6bone.net status=0 ai=00A1ED90] 1: canonname=6bone.net 1: => 3ffe:b00:c18:1::10 1: => 126.96.36.199 1: OnLookupComplete called [host=6bone.net status=0 ai=00A868F8] 1: canonname=6bone.net 1: => 3ffe:b00:c18:1::10 1: => 188.8.131.52 main thread sleeping for 10 seconds... shutting down main thread...
This may be caused by the different way Microsoft's getaddrinfo() handles the AI_CANONNAME flag (which we are using). Here is the relevant excerpt from Microsoft's getaddrinfo() documentation: If neither AI_CANONNAME nor AI_NUMERICHOST is used, the getaddrinfo function attempts resolution. If a literal string is passed getaddrinfo attempts to convert the string, and if a host name is passed the getaddrinfo function attempts to resolve it. When the AI_CANONNAME bit is set and the getaddrinfo function returns success, the ai_canonname member in the hints parameter points to a NULL-terminated string that contains the canonical name of the specified node. This implies that the only documented way to cause getaddrinfo to resolve a host name is to NOT use the AI_CANONNAME flag.
For what it's worth, this doesn't work in IE either. IE behaves in exactly the same way: if the name has a CNAME record, it does not do fallback. If it has only an AAAA record, fallback works. So it's probably a bug in getaddrinfo(). This posting by Fulvio Risso to microsoft.public.platformsdk.networking.ipv6 reports the same problem: http://groups.google.com/groups?threadm=d805a30b.0305150344.6d17fe60%40posting.google.com Note that according to Fulvio, the bug only occurs on XP and not on 2k. I'll ask Fulvio if he can run a test on 2k to confirm whether this is the case.
OK, Fulvio confirms that this is not a problem on Windows 2000. However, he says it also affects Windows 2003 server, which supposedly has Microsoft's "production quality" IPv6 stack. So, looking to the future, maybe we should see if there is an acceptable workaround for this. If someone (Darin?) could provide a build that doesn't set the AI_CANONNAME flag, I would be happy to test it. Currently I'm on a dialup connection, so I can't download all the cygwin/gnu/perl tools I would need to build on Windows.
Adding URL which should show the problem if you have IPv6 under Windows. Also changing OS to Windows XP since the bug doesn't occur on Windows 2000.
OS: All → Windows XP
Ok, I tried this using a very simple test program, and it doesn't work, so it's definitely a bug in the XP/2003 IPv6 stack. I reported it (again!) in this thread in Microsoft's newsgroup: http://groups.google.com/groups?threadm=e3dAr3NlDHA.988%40TK2MSFTNGP10.phx.gbl but no answer so far. Soon I'll start spamming @online.microsoft.com addresses to see if I get an answer. ;-) So, to clarify, this is a Windows XP/2003 bug, not a Mozilla bug. I'm leaving this bug open just in case we can find a usable workaround, but I doubt it.
Whiteboard: [likely invalid -- looks like a Windows XP/2003 bug]
Target Milestone: mozilla1.6alpha → ---
If this is a problem with the MS IPv6 stack, then shouldn't this bug be assigned to Evang?
Possibly; it depends on whether it is more probable that Microsoft fixes the bug or that Mozilla finds a workaround. Feel free to reassign to evangelism if you think it would make a difference, but I doubt it personally. They might fix it, but it'll never be because we asked them. Actually, probably if we ask them it'll just take longer. :)
We should submit a bug report to Microsoft. It is best to include a test program that reproduces the bug.
I have contacted Microsoft on this, and I received a promising reply. I'll post a comment if/when I receive something definite.
thanks lorenzo! -> tech evang
Assignee: darin → english-us
Status: ASSIGNED → NEW
Component: Networking → English US
Product: Browser → Tech Evangelism
QA Contact: benc → english-us
Version: Trunk → unspecified
It looks like MS will fix this. More info, including a workaround, has been posted to the newsgroup. http://groups.google.com/groups?threadm=e3dAr3NlDHA.988%40TK2MSFTNGP10.phx.gbl (look at the newsgroup directly if you don't see the new posts)
*** Bug 222952 has been marked as a duplicate of this bug. ***
MS says this has been fixed, and our testing indicates the same. Resolving.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Conforming summary to TFM item 10 at http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new
Summary: Moz doesn't fall back to IPv4 if it gets an error using IPv6 → 6net.org - Moz doesn't fall back to IPv4 if it gets an error using IPv6
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.