192696 - FreeBSD can't connect to a certain IPv6 site (sock-cond=80004005, nsHttpConnection::CloseTransaction)

Status: RESOLVED DUPLICATE of bug 186745

(Core :: Networking: HTTP, defect)

Description

[HARUNAGA Hirotoshi]

FreeBSD build cannot connect to a certain site,
ex. http://www.jp.freebsd.org/

http.log:
http://bugzilla.mozilla.gr.jp/attachment.cgi?id=1489&action=view

This shows:
135852032[8162300]: nsHttpConnection::OnSocketWritable [this=89a6f80]
135852032[8162300]:   writing transaction request stream
135852032[8162300]:   ReadSegments returned [rv=0 count=444 read=0
sock-cond=80004005]
135852032[8162300]: nsHttpConnection::CloseTransaction[this=89a6f80
trans=8a71600 reason=80004005]

Confirming with 2003020323/FreeBSD 4.7-RELEASE and my personal build
using 09-Feb-2003 source.

2003011500/FreeBSD works, 2003011915/FreeBSD and later don't work.
(These build ID is JST: Japan Standard Time, +0900)
If I use IP address, I can connect to http://203.139.121.132/.
MacOS X build and Linux build don't have this problem.
This is FreeBSD only...

Comment 1

[Matthias Versen [:Matti]]

-> Http

Comment 2

[Darin Fisher]

harunaga: have you tried a more recent build, say 2003-02-11?

Comment 3

[HARUNAGA Hirotoshi]

I built from CVS at Feb 12 06:31:44 PST.
But same behavior.
Nothing happens for http://www.jp.freebsd.org/.

Comment 4

[Darin Fisher]

harunaga: presuming you built debug, can you enable these env variables before
running mozilla:

  setenv NSPR_LOG_MODULES nsHttp:5,nsSocketTransport:5
  setenv NSPR_LOG_FILE /tmp/log

repro this bug and upload /tmp/log to this bug report.  thx!

Comment 5

[HARUNAGA Hirotoshi]

Attachment: http.log on debug build

Comment 6

[HARUNAGA Hirotoshi]

Attachment: log at http://www.cfengine.org of Bug 193169

It's similar. 
I think Bug 193169 is a dup of this.

Comment 7

[Darin Fisher]

looks like this might be a possible duplicate of bug 189965.  that bug was fixed
yesterday.

harunaga: can you "cvs update" in netwerk/ and rebuild in netwerk/ to see if the
problem has been solved?  thx!!

Comment 8

[HARUNAGA Hirotoshi]

comment 5 and comment 6 are on CVS debug build at 02-14 09:00 PST.

Comment 9

[Jari Kirma]

This bug seems to happen with sites that have AAAA (IPv6 address entry) in DNS,
but the host can't access the IPv6 site (due to the routing problems or such).
Otherwise IPv6 access works (tried against IPv6 localhost site).
It's unknown if dropping IPv6 support from the FreeBSD kernel could work around
this.

Another site that cause this behavior: www.kame.net

Comment 10

[Darin Fisher]

ok, the patch for bug 189965 was actually insufficient.  it only fixed the
problem for windows platforms.  bug 193267 contains a patch that fixes the error
reporting on linux as well.  as a result, the code which tries different DNS
entries should be tickled.  can someone please test the patch in bug 193267 to
verify that it fixes this bug as well?  thx!

Comment 11

[HARUNAGA Hirotoshi]

Attachment: http.log

I applied the patch attachment 114758 [details] [diff] [review] of bug 193267 to CVS 2003021807.
But nothing happens for me on http://www.jp.freebsd.org/,
http://www.cfengine.org/ and http://www.kame.net/...

Comment 12

[Darin Fisher]

hmm... NSPR seems to be generating PR_UNKNOWN_ERROR.  i'm not sure what's going
on there.

Comment 13

[Darin Fisher]

i suspect it is PR_Connect that is failing here, but if this worked before Jan
16, then i'm very confused.

Comment 14

[Darin Fisher]

removing dependency.  it turns out that the old socket code mapped _any_ error
from PR_Connect (beside PR_IN_PROGRESS_ERROR or PR_WOULD_BLOCK_ERROR) to
NS_ERROR_CONNECTION_REFUSED.  as a result, we'd try the next IP address.  my
guess is that the reporter's DNS is configured to give back IPv6 addresses, but
the reporters machine probably doesn't have a route to the IPv6 address for
www.jp.freebsd.org or perhaps the reporters machine isn't configured to work
with IPv6.  in the past the PR_UNKNOWN_ERROR would have been mapped
NS_ERROR_CONNECTION_REFUSED, and we would have just tried the next IP address
(the IPv4 one) and things would have just worked.  i should probably do
something similar now.

Comment 15

[Wan-Teh Chang]

Mr. Harunaga: could you try the patch (attachment 112566 [details] [diff] [review])
in bug 186745?

That NSPR patch tells PR_GetIPNodeByName to not return
any IPv6 addresses if the machine is not configured with
an IPv6 network interface.  Based on what Darin Fisher
said in comment 14, trying to connect to an IPv6 address
from a machine with no IPv6 network interface may be the
fundamental cause of the problem.

After you apply the patch to your source tree, you do not
need to rebuild Mozilla; you only need to rebuild NSPR as
follows:

# change directory to the top of your build tree
% cd nsprpub
% make clean
% make

Let me know if the patch solves the problem.

Comment 16

[HARUNAGA Hirotoshi]

This is solved by attachment 112566 [details] [diff] [review].
No problem on 3 sites above.
Thank you.

Comment 17

[Darin Fisher]

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

Comment 18

[HARUNAGA Hirotoshi]

attachment 112566 [details] [diff] [review] solves my problem.
but it seems to me Mozilla should try next IP address (like as before?)...

Comment 19

[Wan-Teh Chang]

I think Mr. Harunaga has a good point.  Although my
patch in bug 186745 eliminated the very source of
this problem, there seem to be some problems at higher
layers that is exposed by the underlying problem.