193120 - IPv6: if the http-server is not IPv6 aware there will be an RST,ACK

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/00200302
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/00200302

there exist some IPv6 related bugs which could be referenced. But the following
occurs at least since 1.3b:
if the system-resolver finds an IPv6 address this is used for the connection.
But if the http-server is not IPv6 aware there will be an RST,ACK.
Then the IPv4 address is not longer tried.
There is some discussion about it in another bug, but this is a regression because
Mozilla 1.2.1 doesn't show this behaviour. All is OK with 1.2.1 but not with 1.3b.

Reproducible: Always

Steps to Reproduce:
.

Comment 1

[Jo Hermans]

dupe of bug 163157 ?

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

I think it's not really a dupe because bug 163157 is much older and as I wrote
1.2.1 didn't show this problem.

Comment 3

[benc]

Please describe the networking environment more fully, and provide the expected
behavior.

Are these systems on the same subnet?
If not, is there IPv6 routing?
Is the web server system IPv4 only, or the web server (or both?)

I don't know a lot about ipv4/ipv6 interoperability, so I'm not going to guess
what is going on.

Comment 4

[Wolfgang Rosenauer [:wolfiR]]

server and client (mozilla) are in the same subnet but I think that this doesn't
make a difference at all.
Client and server are connected via IPv6 but the webserver is not IPv6-aware.
So it can't answer at the IPv6 socket which will cause in an RST,ACK.
The webserver is only reachable via IPv4 but I can see with a network sniffer
that IPv4 connection is not tried after the RST.
Mozilla only show "The document contains no data"

Comment 5

[Wolfgang Rosenauer [:wolfiR]]

one addition: Mozilla should try to connect to the IPv4 address which is
definitely resolved in the DNS request. The resolver first ask for the AAAA
record and after that for the A record. So the resolver has both addresses.
Mozilla should try all addresses to get a connection as described in the RFC which 
is mentioned in bug 163157

Comment 6

[Darin Fisher]

this may actually be a duplicate of bug 189965.  that bug causes us to
incorrectly detect connection errors.  as a result, the code that fails over to
IPv4 probably isn't triggered.  that patch should make it into the tree shortly
(for 1.3 final at any rate), so let's wait and see if that patch helps.  or if
you have a debug build, it'd be great if you could try out the patch from that
bug and let us know if it makes any difference.  thanks!

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

I've updated my tree and the patch is in there.
But the behaviour is the same. I still get "...document contains no data" while
trying to connect IPv6 enabled hosts :-(

Comment 8

[Darin Fisher]

wolfgang: can you please collect a log file for us?  here's the steps:

bash$ export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5
bash$ export NSPR_LOG_FILE=/tmp/http.log
bash$ mozilla

then just repro the problem, exit mozilla, and upload /tmp/http.log to this bug
report.  thx!

Comment 9

[Wolfgang Rosenauer [:wolfiR]]

I fear I need a debug build for that?
(my /tmp/http.log is empty)
Is it enough to build without --disable-debug?

Comment 10

[Wolfgang Rosenauer [:wolfiR]]

Attachment: http.log

OK, I got the following debug output

Comment 11

[Darin Fisher]

ok, the log file is consistent with what i expected.  this bug is probably going
to be fixed when the patch for bug 193267 lands.

Comment 12

[Darin Fisher]

bug 193267 has been fixed.  please test this using tomorrows nightly build.  thx!

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

I've tested it and it works now.
Thanks.

Comment 14

[Ramón García Fernández]

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

Comment 15

[Ramón García Fernández]

Please reopen this bug. (See bug #199173 )