Closed
Bug 223145
Opened 21 years ago
Closed 21 years ago
Numeric IPv6 addresses don't work
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.6beta
People
(Reporter: jens.kammann, Assigned: lorenzo)
References
()
Details
(Keywords: regression)
Attachments
(4 files)
11.50 KB,
text/plain
|
Details | |
12.66 KB,
text/plain
|
Details | |
48.23 KB,
text/plain
|
Details | |
718 bytes,
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
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/
Reporter | ||
Comment 3•21 years ago
|
||
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•21 years ago
|
||
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 ?
Reporter | ||
Comment 5•21 years ago
|
||
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•21 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 7•21 years ago
|
||
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.
Reporter | ||
Comment 8•21 years ago
|
||
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.
Assignee | ||
Comment 9•21 years ago
|
||
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?
Assignee | ||
Comment 10•21 years ago
|
||
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?
Updated•21 years ago
|
Blocks: 219376
Keywords: regression
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6beta
Reporter | ||
Comment 11•21 years ago
|
||
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
Assignee | ||
Comment 12•21 years ago
|
||
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.
No longer blocks: 219376
Reporter | ||
Comment 13•21 years ago
|
||
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
Assignee | ||
Comment 14•21 years ago
|
||
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.
Assignee | ||
Comment 15•21 years ago
|
||
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.
Assignee: darin → lorenzo
Status: ASSIGNED → NEW
Summary: ipv6 problem in Mozilla for Win XP → Numeric IPv6 addresses don't work
Assignee | ||
Comment 16•21 years ago
|
||
One-line patch to ensure that the address returned by nsHostResolver::ResolveHost does not contain garbage.
Assignee | ||
Comment 17•21 years ago
|
||
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.
Assignee | ||
Comment 18•21 years ago
|
||
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?
Attachment #134616 -
Flags: review?(darin)
Comment 19•21 years ago
|
||
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•21 years ago
|
||
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 :)
Attachment #134616 -
Flags: superreview+
Attachment #134616 -
Flags: review?(darin)
Attachment #134616 -
Flags: review+
Comment 21•21 years ago
|
||
wtc: see bug 34843. that has to do with using getnameinfo.
Comment 22•21 years ago
|
||
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•21 years ago
|
||
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.
Assignee | ||
Comment 24•21 years ago
|
||
>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.
Assignee | ||
Comment 25•21 years ago
|
||
Shall we resolve this? Reporter, can you still reproduce the problems?
Assignee | ||
Comment 26•21 years ago
|
||
Marking fixed since one of the problems reported was fixed and we were never able to reproduce the other one.
Assignee | ||
Updated•21 years ago
|
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•