223145 - Numeric IPv6 addresses don't work

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Jens Kammann]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

On a Windows XP (SP1) System with working IPv6 connectity (tunnel, tracert6 
working), Mozilla fails to load ip6 version of webpages: Eg. 
http://www.6bone.net loads IPv4 version, http://[3ffe:b00:c18:1::10] should 
force ipv6 version, but results in "The connections was refused". However, 
manually fetching the page from the command line "telnet 3ffe:b00:c18:1::10 
80 ; GET / HTTP/1.0" works. Please see attached HTTP Debug log from Mozilla.

Reproducible: Always

Steps to Reproduce:
1.http://[3ffe:b00:c18:1::10] of any other ipv6-only webpage
2.
3.

Actual Results:  
"The connection was refused"

Expected Results:  
load and display the page

see attachment for HTTP log

Comment 1

[Jens Kammann]

Attachment: HTTP log when accessing http://[3ffe:b00:c18:1::10]

Comment 2

[Olivier Cahagne]

I'm not sure if patch for 205726 made it into 1.5.
Can you try again with latest nightly build (ie. trunk 1.6) ?
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/

Comment 3

[Jens Kammann]

Almost the same result with the latest build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031022

Almost means, that e.g. http://www.kame.net still connects via IPv4, but
http://http://[3ffe:b00:c18:1::10] once showed the IPv6 version of the web site.
A second try of the same URL results just in an empty page with "Done" in the
status line. Unfortunately this was a one-time success: Even restarting or
rebooting did not bring up the IPv6 version of the site again.

Comment 4

[Olivier Cahagne]

can you attach a HTTP log for the failing session via "create a new attachment" ?
See instructions here:
http://www.mozilla.org/projects/netlib/http/http-debugging.html
perhaps related to bug 219088 ?

Comment 5

[Jens Kammann]

Attachment: Request for http://[2001:200:0:8002:203:47ff:fea5:3085]

This is the log for accessing http://[2001:200:0:8002:203:47ff:fea5:3085
(www.kame.net)	- results in empty page and "done"

Comment 6

[Olivier Cahagne]

Marking NEW since it has log and CC'ing Lorenzo (if you mind, please let me know
or remove yourself from CC list) so that he can look at it and perhaps connect
to this host with his machine.

Comment 7

[Lorenzo Colitti]

Jens, are you compiling Mozilla yourself or are you seeing this in mozilla.org
build? I saw this too, but I assumed it was due to IPv6 not working because I
was building with mingw.

This is what the log says:

1848[a28028]: ErrorAccordingToNSPR [in=-5986 out=80004005]
1848[a28028]:   connection failed! [reason=80004005]

-5986 is PR_ADDRESS_NOT_AVAILABLE_ERROR:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/include/prerr.h#86

which is the NSPR version of WSAEADDRNOTAVAIL:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/md/windows/win32_errors.c#194

Assuming that the call that is falling is connect(), this is what MSDN has to
say about WSAEADDRNOTAVAIL:

WSAEADDRNOTAVAIL The remote address is not a valid address (such as ADDR_ANY).
[...]
If the address member of the structure specified by the name parameter is all
zeroes, connect will return the error WSAEADDRNOTAVAIL.

Somehow I doubt that the socket address being passed in is all zeros though. :)

I'll test it on a recent nightly and let you know what I see.
I don't think it's related to bug 219088, though: that one is about name resolution.

Comment 8

[Jens Kammann]

Lorenzo, I took the nightly build from mozilla.org and I should note that I
noticed the same behavior with the "old" Ipv6 stack of XP before I upgraded to
the current one.
Although I think this is not related to bug 219088, too, this bug also hasn't
been  fixed yet: Some webpages (e.g. www.kame.net) load using IPv6, others (e.g.
tunnelbroker.as8758.net) appear in the IPv4 version.

I am working on HTTP-Proxy development for a different project and I am planning
to upgrade our lab network to IPv6 pretty soon, so that I will have access to
several platforms (solaris, linux, windows in different languages) for further
testing.

Comment 9

[Lorenzo Colitti]

Ok, I tested build 2003102504 on Windows XP SP1 with the Advanced networking
pack, and this is what I see.

Numeric IPv6 addresses: if I enter http://[2001:200:0:8002:203:47ff:fea5:3085]/
or any oher URL with a numeric IPv6 address and press enter, the progress bar
lights up for a fraction of a second, but nothing happens! The site does not
load and the browser continues to display the page it was displaying before
typing the URL. No error message appears. This is bad. :)

IPv6 hostnames: everything seems to work. http://www.kame.net/ gives me the IPv6
version, and  http://www.6net.org/ tells me that I am using IPv6.
http://tunnelbroker.as8758.net/ also tells me I am connecting using IPv6.

This might be caused by the fix to bug 219376. If this is indeed the case,
builds from 5 October should work and builds from 6-7 october should have this
bug. Anyone want to test this?

Comment 10

[Lorenzo Colitti]

Jens, do you confirm that numeric IPv6 addresses fail but IPv6 hostnames work?

If so, we can change the summary to "Numeric IPv6 addresses in URL cause page
load to fail silently" or something like that.

Note that in the first log file (the one for http://[3ffe:b00:c18:1::10]), the
error is -5980, which is destination unreachable. Are you sure you have
connectivity to that IPv6 address?

Comment 11

[Jens Kammann]

The trace belows shows that I have a working IPv6 connectivity to 
[3ffe:b00:c18:1::10]. I also tested the address with Opera 7.21 on the same 
PC, no problems.

BTW I found a better example to demonstate the effect:

A) http://ipv6tb.he.net/  (resolves to:)
B) http://[3ffe:81d0:ffff::3]
C) http://64.71.128.84

Expected behavior (tested with Opera 7.21):
A) IPv6 version of web page loads
B) same as A)
C) IPv4 version loads

Behavior of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20031022:

A) IPv4 version of page loads (DNS issue ? Or fallback since IPv6 version 
fails ?)
B) Empty page, Status line "done"
C) IPv4 version loads

-------------------------
Tracing route to www.6bone.net [3ffe:b00:c18:1::10]
from 2002:d536:8768::d536:8768 over a maximum of 30 hops:

  1      108 ms   108 ms   111 ms  2002:3eec:20cb::1
 (...)
  7      533 ms   531 ms   531 ms  rap.ipv6.viagenie.qc.ca
[3ffe:b00:c18:1:290:27ff:fe17:fc0f]
  8      543 ms   531 ms   529 ms  www.6bone.net [3ffe:b00:c18:1::10]

Jens

Comment 12

[Lorenzo Colitti]

C) is, of course, an IPv4 address. No surprises here: bug 219376 is fixed.

B) I see this too: numeric IPv6 addresses don't work. This probably regressed on
20031006. Can you test this on Windows builds from 20031005 and 20031007 to see
if one works and one doesn't?

A) works fine for me. Can you attach an HTTP log of what happens when you try to
connect? With build 2003102504 (trunk) on XP I get the IPv6 version.

Comment 13

[Jens Kammann]

Attachment: Log accessing http://ipv6tb.he.net - IPv4 shows instead of IPv6

Here's the requested log for case "A" (http://ipv6tb.he.net IPv4 version loads,
but IPv6 is expected).
I am unable to locate Windows Installer Versions of the older versions you
request. I see only Linux an Os2 version. If you can point me to the place
where I can find these, I'll post also the other logs.

Jens

Comment 14

[Lorenzo Colitti]

Jens, you might want to try these two builds:

http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-10-04-04-trunk/mozilla-win32.zip
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/2003-10-08-04-trunk/mozilla-win32.zip

Check that the first can connect to numeric IPv6 addresses and the second can't.

Regarding your log file, something strange is happening. It looks like mozilla
is not getting the IPv6 address at all, because the first connection it makes is
to an IPv4 address. Is it an option for you to use a packet sniffer to sniff the
DNS requests mozilla is making? In any case, this looks like a different bug.

Comment 15

[Lorenzo Colitti]

Ok, I found the cause of the "numeric IPv6 addresses not working" problem.

The problem is that when a numeric IPv6 address is specified in the URL bar, the
sin6_scope_id field of the sockaddr_in6 structure is not zeroed out. I suspect
that happens because we are not calling getaddrinfo() on the IPv6 address, but
trying to fill in the socket address structure ourselves.

Patch coming up.

Comment 16

[Lorenzo Colitti]

Attachment: wallpaper patch

One-line patch to ensure that the address returned by
nsHostResolver::ResolveHost does not contain garbage.

Comment 17

[Lorenzo Colitti]

Note that this patch solves the numeric IPv6 address problem, but what we should
really be doing is calling getaddrinfo on the hostname, even if it's a numeric
IPv6 address.

getaddrinfo will always be smarter that we are, and it understands stuff such as
scope identifiers that we shouldn't really be dealing with. But trying to
resolve all numeric addresses will bring bug 219376 back to life, so what can we do?

Since a platform that supports IPv6 must have getaddrinfo, and RFC 2553 says
that getaddrinfo must be able to understand numeric addresses, if
nsHostResolver::ResolveHost gets a numeric address it could check what type of
address it is and copy it if it's an IPv4 address and resolve it if it's an IPv6
address. But this would mean tinkering with address families and adding
platform-specific code in the DNS resolver, which is not very nice either.

Maybe this can be fixed by changing PR_StringToNetAddr so it uses getnameinfo()?
CC'ing wtc for thoughts.

Comment 18

[Lorenzo Colitti]

Comment on attachment 134616 [details] [diff] [review]
wallpaper patch

In the meantime, this is a 99% solution that should probably go into 1.6b
(zero-risk).

Darin, can you rubber-stamp this?

Comment 19

[Wan-Teh Chang]

Lorenzo,

PR_StringToNetAddr should have zeroed the PRNetAddr object.
Since we didn't do that before, I can't do that right now
even though it's the right thing.  (This is for backward
compatibility.)  So, your patch is correct.  Darin may be
able to figure out a way to only do the memset(,0,) call if
PR_StringToNetAddr will be called.

PR_StringToNetAddr currently uses the deprecated inet_pton
function, which I remember doesn't handle scope id's.  Your
suggestion of using getnameinfo is good.  I remember there
is already a bug filed on this.  If not, Darin, could you
write an enhancement request?

Comment 20

[Darin Fisher]

Comment on attachment 134616 [details] [diff] [review]
wallpaper patch

r+sr=darin, but please add a detailed comment explaining this hack, and
reference this bug.  thanks :)

Comment 21

[Darin Fisher]

wtc: see bug 34843.  that has to do with using getnameinfo.

Comment 22

[Darin Fisher]

so there are several other places where PR_StringToNetAddr is called.  should we
add a similar hack to those as well?

see nsProtocolProxyService.cpp and nsCookieService.cpp

btw, this patch has been checked in on the trunk.

>Maybe this can be fixed by changing PR_StringToNetAddr so it uses getnameinfo()?

maybe this is necessary for IPv6 to really work.  otherwise, we do have to fix
all the callers.  ok... now, hmm... wait a second.  if it is okay to make
PR_StringToNetAddr call getnameinfo (which will effectively touch all fields of
PRNetAddr), why isn't it okay to have PR_StringToNetAddr zero out the PRNetAddr
struct?  how is it that getnameinfo doesn't similarly break binary compatibility?

i think it is reasonable for PR_StringToNetAddr to always return a PRNetAddr
that is meaningful.  it should not require that the result buffer be zero'd out
a priori.

Comment 23

[Wan-Teh Chang]

Darin, zeroing PRNetAddr before use is not a hack.  It is the
right thing to do.  Unfortunately, I learned about it too late.

The reason I can't change PR_StringToNetAddr to zero out the
PRNetAddr struct is that the caller may have set the 'port'
field of the PRNetAddr struct.

Comment 24

[Lorenzo Colitti]

>so there are several other places where PR_StringToNetAddr is called.  should we
>add a similar hack to those as well?
>see nsProtocolProxyService.cpp and nsCookieService.cpp

I checked and it seems that we don't have to change anything else. Everywhere
PR_StringToNetAddr is called (according to LXR at least), the caller either
looks only at the return value and not the returned address, or uses the
returned address to copy it into a PRIPv6Addr, which does not contain the scope
fields.

Comment 25

[Lorenzo Colitti]

Shall we resolve this?

Reporter, can you still reproduce the problems?

Comment 26

[Lorenzo Colitti]

Marking fixed since one of the problems reported was fixed and we were never
able to reproduce the other one.