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

RESOLVED FIXED in mozilla1.3final

Status

()

Core
Networking: HTTP
--
critical
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: wolfiR, Assigned: Darin Fisher)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.3final
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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:
.
(Reporter)

Updated

16 years ago
Flags: blocking1.3?

Comment 1

16 years ago
dupe of bug 163157 ?
(Reporter)

Comment 2

16 years ago
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

16 years ago
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.
Summary: IPv6 in Mozilla 1.3 → IPv6: if the http-server is not IPv6 aware there will be an RST,ACK
(Reporter)

Comment 4

16 years ago
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"
(Reporter)

Comment 5

16 years ago
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
(Assignee)

Comment 6

16 years ago
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!
Depends on: 189965
(Reporter)

Comment 7

16 years ago
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 :-(
(Assignee)

Comment 8

16 years ago
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!
(Reporter)

Comment 9

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

Comment 10

16 years ago
Created attachment 114636 [details]
http.log

OK, I got the following debug output
(Assignee)

Comment 11

16 years ago
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.
Status: UNCONFIRMED → ASSIGNED
Depends on: 193267
Ever confirmed: true
Target Milestone: --- → mozilla1.3final
(Assignee)

Comment 12

16 years ago
bug 193267 has been fixed.  please test this using tomorrows nightly build.  thx!
(Reporter)

Comment 13

16 years ago
I've tested it and it works now.
Thanks.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
Flags: blocking1.3?
(Reporter)

Updated

16 years ago
Blocks: 136898
*** Bug 199173 has been marked as a duplicate of this bug. ***
Please reopen this bug. (See bug #199173 ) 
You need to log in before you can comment on or make changes to this bug.