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

RESOLVED FIXED

Status

defect
--
major
RESOLVED FIXED
16 years ago
4 years ago

People

(Reporter: darin.moz, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [likely invalid -- looks like a Windows XP/2003 bug], URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

16 years ago
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?
(Reporter)

Comment 1

16 years ago
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!
(Reporter)

Updated

16 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: regression
Target Milestone: --- → mozilla1.6alpha

Comment 2

16 years ago
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 4

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

Comment 5

16 years ago
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

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

Comment 7

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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.

Updated

16 years ago
Attachment #131391 - Attachment is obsolete: true

Comment 11

16 years ago
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
(Reporter)

Updated

16 years ago
Blocks: 223811

Comment 12

16 years ago
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.

Updated

16 years ago
No longer blocks: 223811
(Reporter)

Comment 13

16 years ago
untargeting bug...
Whiteboard: [likely invalid -- looks like a Windows XP/2003 bug]
Target Milestone: mozilla1.6alpha → ---

Comment 14

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

Comment 15

16 years ago
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

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

Comment 17

16 years ago
I have contacted Microsoft on this, and I received a promising reply. I'll post
a comment if/when I receive something definite.
(Reporter)

Comment 18

16 years ago
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

Comment 19

16 years ago
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

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

Comment 21

15 years ago
MS says this has been fixed, and our testing indicates the same. Resolving.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 22

15 years ago
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.