11.50 KB, text/plain
12.66 KB, text/plain
48.23 KB, text/plain
718 bytes, patch
|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
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/
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.
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 ?
Created attachment 133982 [details] 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"
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
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.
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.
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?
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?
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://188.8.131.52 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
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
Created attachment 134426 [details] 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
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.
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
Created attachment 134616 [details] [diff] [review] wallpaper patch One-line patch to ensure that the address returned by nsHostResolver::ResolveHost does not contain garbage.
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 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?
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 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 :)
wtc: see bug 34843. that has to do with using getnameinfo.
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.
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.
>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.
Shall we resolve this? Reporter, can you still reproduce the problems?
Marking fixed since one of the problems reported was fixed and we were never able to reproduce the other one.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.