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: .
dupe of bug 163157 ?
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.
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
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"
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
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
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 :-(
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!
I fear I need a debug build for that? (my /tmp/http.log is empty) Is it enough to build without --disable-debug?
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
bug 193267 has been fixed. please test this using tomorrows nightly build. thx!
I've tested it and it works now. Thanks.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** 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.