219088 - 6net.org - Moz doesn't fall back to IPv4 if it gets an error using IPv6

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Darin Fisher]

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?

Comment 1

[Darin Fisher]

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!

Comment 2

[HARUNAGA Hirotoshi]

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).

Comment 3

[HARUNAGA Hirotoshi]

Attachment: http.log on www.mozilla.org with FreeBSD

Comment 4

[Wan-Teh Chang]

The FreeBSD and Mac OS X problem is a different problem
(bug 219104).

Comment 5

[Lorenzo Colitti]

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: => 193.204.161.165
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: => 193.204.161.165
main thread sleeping for 10 seconds...
shutting down main thread...

Is this getaddrinfo()'s fault?

Comment 6

[Wan-Teh Chang]

Lorenzo, could you run TestDNS on www.6bone.net and 6bone.net?

Comment 7

[Lorenzo Colitti]

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: => 206.123.31.124
1: OnLookupComplete called [host=6bone.net status=0 ai=00A868F8]
1: canonname=6bone.net
1: => 3ffe:b00:c18:1::10
1: => 206.123.31.124
main thread sleeping for 10 seconds...
shutting down main thread...

Comment 8

[Wan-Teh Chang]

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.

Comment 9

[Lorenzo Colitti]

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.

Comment 10

[Lorenzo Colitti]

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.

Comment 11

[Lorenzo Colitti]

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.

Comment 12

[Lorenzo Colitti]

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.

Comment 13

[Darin Fisher]

untargeting bug...

Comment 14

[David G King]

If this is a problem with the MS IPv6 stack, then shouldn't this bug be assigned
to Evang?

Comment 15

[Lorenzo Colitti]

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. :)

Comment 16

[Wan-Teh Chang]

We should submit a bug report to Microsoft.  It is best to
include a test program that reproduces the bug.

Comment 17

[Lorenzo Colitti]

I have contacted Microsoft on this, and I received a promising reply. I'll post
a comment if/when I receive something definite.

Comment 18

[Darin Fisher]

thanks lorenzo!

-> tech evang

Comment 19

[Lorenzo Colitti]

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)

Comment 20

[Lorenzo Colitti]

*** Bug 222952 has been marked as a duplicate of this bug. ***

Comment 21

[Lorenzo Colitti]

MS says this has been fixed, and our testing indicates the same. Resolving.

Comment 22

[Felix Miata]

Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new