User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 When attempting to browse www.live.com, Mozilla stays in the previous page. No error message. The status line shows that it is connecting, then it gets empty. In preferences, HTTP/1.1 and Keep-Alive are selected. Pipelining is not enabled. Reproducible: Always Steps to Reproduce:

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

WFM, Linux CVS; pipelining enabled. Reporter: Are you using a proxy or some sort? If you change networking pref to HTTP 1.0 - does that change anything?

The problem also happens using latest nightly build, 2003032505. I am strace'ing Mozilla, and it seems that it is using IPV6. Could this be the reason?

The following trace with strace of one of the threads shows that the kernel returns an error "Network unreachable". Therefore, the problem is to some extent out of the scope of Mozilla. However, Mozilla should display a dialog box with an error message. In addition, an option in preferences allowing me to disable the use of IPV6 should be offered. (Mozilla produces several threads. I think that this is the correct thread because it is the only one that has a call to connect() ). Note that Mozilla learns the error message through getsockopt(), that returns an error code 113 that is "Network unreachable" under Linux. poll([{fd=7, events=POLLIN, revents=POLLIN}], 1, -1) = 1 read(7, "8", 1024) = 1 socket(PF_INET6, SOCK_STREAM, 0) = 31 fcntl64(0x1f, 0x3, 0, 0x3) = 2 fcntl64(0x1f, 0x4, 0x802, 0x4) = 0 connect(31, {sin_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:470:1f00:1070:1::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=3221218008}, 24) = -1 EINPROGRESS (Operation now in progress) poll([{fd=7, events=POLLIN, revents=POLLIN}, {fd=31, events=POLLPRI|POLLOUT}], 2, -1) = 1 read(7, "8", 1024) = 1 poll([{fd=7, events=POLLIN}, {fd=31, events=POLLPRI|POLLOUT, revents=POLLERR|POLLHUP}], 2, -1) = 1 getsockopt(31, SOL_SOCKET, SO_ERROR, [113], [4]) = 0 write(6, "\372", 1) = 1 write(8, "8", 1) = 1 close(31)

dup of bug 193120?

ramon: do you have an IPv6 enabled box? we store all IP addresses using IPv4 mapped IPv6 addressed (i.e., we just stick IPv4 addresses in a IPv6 container... it doesn't really mean that we are using IPv6). however, if your DNS server is returning IPv6 addresses, then we will try to use them.

My box is IPv6 enabled. Yes, www.live.com returns an IPv6 address in addition to an IPv4 address and Mozilla uses it. Note that in the strace log, the socket call creates an IPv6 socket, and connect uses an IPv6 address. The host command shows that www.live.com has an IPv6 address, and thus Mozilla uses it. That completes the diagnostic. Here Mozilla shows to flaws. The first is an obvious bug: when using IPv6, Mozilla does not display a dialog box saying "Cannot connect: network is unreachable". The second is that, as IPv6 is not completely implemented on the Internet, Mozilla should provide the option of disabling it. Ramon

Yes, we have problems with both aspects of sites that have ipv6+ipv4 addresses.

*** This bug has been marked as a duplicate of 193120 ***

duplicate seems wrong to me. comment #8 describes enhancements. reopening this bug.

I think that bug #193120 has reappeared, and this is the essence of this bug. Forget my comment #8. As stated in that bug, the behaviour of Mozilla should be to try all the addresses (IPV6 and IPV4) returned by a DNS query. Report an error if all of them fail.

I can confirm this. But not with ALL IPv6 enabled targets? I can't see a difference in targets. All have IPv6 addresses and no IPv6 enabled http-servers. But one of this hosts works. When I use a network scanner I can see that for the one reachable host all seems to be OK. The resolver get the IPv6 address first and after that the IPv4 address. Then mozilla is trying the IPv6 address, get an error and tries the IPv4 address, which is successful. But the other hosts are not reachable and I can see NO attempt of mozilla to connect to the hosts. This IPv6 bugs are very annoying because it seems that newer Linux distributions will resolve IPv6 addresses per default.

I've tested again and can confirm for sure that Mozilla never tries to connect to the IPv6 enabled servers (not all but almost). After DNS lookup Mozilla does nothing more.

OK, I'm using 1.4b now and it is almost unusable on my IPv6 enabled system. The following happens (just a reminder): (happens e.g. for http://www.an-netz.de/) - I want to load a web-page and the target has an IPv6 address and NO IPv6 capable webserver. wolfi@Mobile:~> host -t aaaa www.an-netz.de www.an-netz.de is an alias for saruman.an-netz.de. saruman.an-netz.de has AAAA address 2001:638:a03::2 - Mozilla just displays "done" in status bar but don't do anything else - the network-protocol (done by ethereal) shows ONLY the following traffic: standard query AAAA www.an-netz.de standard query response CNAME saruman.an-netz.de AAAA 2001:638:a03::2 standard query A www.an-netz.de standard query response CNAME saruman.an-netz.de A 194.95.197.2 There is NO MORE activity on the network, what means that Mozilla doesn't even try to connect to the server. Please note that more and more IPv6 enabled hosts reach the internet. SuSE Linux 8.2 defaults to resolving IPv6 addresses. I vote for increasing the severity of this bug.

Wolfgang: can you please capture a HTTP log using the steps described here: http://mozilla.org/projects/netlib/http/http-debugging.html thanks!

the requested log

please note in addition bug #197172 which is for MailNews but I think it's the very same problem?

hmm... it looks like PR_ConnectContinue is failing w/ PR_GetError returning PR_UNKNOWN_ERROR. the OS specific error code is unfortunately not being logged. wolfgang: are you able to connect to any other IPv6 server? do you have the ability to compile mozilla from source? i would like to provide you with some patches to try if possible. thanks!

there is one "IPv6-resolved" webserver in our network at work which is reachable (comment #13). I build mozilla usually from source. You just have to tell me what debugging configure options are needed. Please send me your patches to my email-address.

this is the only IPv6 host which is usable with current mozilla to have a complete debug set.

wolfgang: could you please apply this patch (rebuild only in mozilla/netwerk/)? then just repro the failure case so we can see what OS level error code is being generated. thx!

new logfile with additional oserr output

hmm... that OS level error code is EHOSTUNREACH, and the comment for that says "No route to host", so i wonder why NSPR is not mapping the error code to PR_NETWORK_UNREACHABLE_ERROR. if it did, then we would end up trying the second DNS lookup result. wtc: does this look like a NSPR bug to you, or should necko check PR_GetOSError when NSPR returns PR_UNKNOWN_ERROR and try to deal?

NSPR should map EHOSTUNREACH to PR_HOST_UNREACHABLE_ERROR. Why doesn't necko try the second DNS lookup result regardless of the NSPR error?

wtc: yeah, necko should probably do that. for now, however, i'm just going to add a case for PR_HOST_UNREACHABLE_ERROR since i want to minimize changes to the code.

this patch adds a case for PR_HOST_UNREACHABLE_ERROR. if we get that error we will look to see if there is another IP address we can try and we will try it.

this patch will only work once bug 205582 is fixed (wtc has a patch and is seeking drivers approval to land that patch for 1.4 final).

Comment on attachment 123222 [details] [diff] [review] v1 patch sr=alecf

Comment on attachment 123222 [details] [diff] [review] v1 patch requesting drivers approval for 1.4 beta (you already approved the NSPR change required by this patch).

Comment on attachment 123222 [details] [diff] [review] v1 patch a=sspitzer

fixed-on-trunk

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