Closed Bug 199173 Opened 21 years ago Closed 21 years ago

IPv6:Page fails to load. No message.

Categories

(Core :: Networking: HTTP, defect, P4)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.4final

People

(Reporter: ramon, Assigned: darin.moz)

References

()

Details

Attachments

(5 files, 1 obsolete file)

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.
QA Contact: httpqa → ipv6
Summary: Page fails to load. No message. → IPv6:Page fails to load. No message.

*** This bug has been marked as a duplicate of 193120 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
duplicate seems wrong to me.  comment #8 describes enhancements.  reopening this
bug.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
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.
Flags: blocking1.4?
Wolfgang: can you please capture a HTTP log using the steps described here:

  http://mozilla.org/projects/netlib/http/http-debugging.html

thanks!
Attached file netlib log build 2003051214 (obsolete) —
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!
Attached file new log with oserr
new logfile with additional oserr output
Attachment #123103 - Attachment is obsolete: true
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.
Priority: -- → P4
Target Milestone: Future → mozilla1.4final
Attached patch v1 patchSplinter Review
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.
Attachment #123222 - Flags: superreview?(alecf)
Attachment #123222 - Flags: review?(dougt)
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).
Status: NEW → ASSIGNED
Depends on: 205582
Attachment #123222 - Flags: review?(dougt) → review+
Comment on attachment 123222 [details] [diff] [review]
v1 patch

sr=alecf
Attachment #123222 - Flags: superreview?(alecf) → superreview+
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).
Attachment #123222 - Flags: approval1.4?
Comment on attachment 123222 [details] [diff] [review]
v1 patch

a=sspitzer
Attachment #123222 - Flags: approval1.4? → approval1.4+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Flags: blocking1.4?
Blocks: 163157
Blocks: 184889
*** Bug 198194 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: