Closed Bug 163157 Opened 22 years ago Closed 22 years ago

browser tries IPv6 address, gets ECONNREFUSED, doesn't fall back to IPv4

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: john.beck, Assigned: darin.moz)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: qawanted, Whiteboard: dupme --- see end of comment 4)

(This happens with Mozilla build 2002072119, Netscape 7.0beta1 and Netscape 6.2.2) My desktop is running IPv6. Pointing to my local web page, [I'm running Apache (which is not IPv6-aware)] resulted in the pop-up The connection was refused when attempting to contact opal.eng.sun.com. I got the same thing when I tried our big server jurassic.eng.sun.com, yet both of these servers under alternate names had their web pages load just fine. truss revealed: 365458/2: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 30 365458/2: fcntl(30, F_GETFL, 0x00000000) = 2 365458/2: fstat64(30, 0xFE5CF970) = 0 365458/2: getsockopt(30, SOL_SOCKET, 0x2000, 0xFE5CFA70, 0xFE5CFA68, 0) = 0 365458/2: fstat64(30, 0xFE5CF9D0) = 0 365458/2: getsockopt(30, SOL_SOCKET, 0x2000, 0xFE5CFAD0, 0xFE5CFACC, 0) = 0 365458/2: setsockopt(30, SOL_SOCKET, 0x2000, 0xFE5CFAD0, 4, 0) = 0 365458/2: fcntl(30, F_SETFL, 0x00000082) = 0 365458/2: connect(30, 0x008F9188, 32, 1) Err#146 ECONNREFUSED 365458/2: close(30) = 0 Note the PF_INET6 in the so_socket() call. IPv6-aware clients should try IPv6 first (as this does), then fall back to IPv4 if no IPv6 connection could be made. I saw identical symptoms (and truss output) with Netscape 6.2.2, 7.0.beta1 and Mozilla 2002072119. It seems that this only happens on an IPv6-enabled client.
Why should an IPv6 connection refused cause a fall back to IPv4? The fact that it got connection refused means: 1) The server has an IPv6 address in DNS 2) The client and server can talk over IPv6 Why should Mozilla assume that connection refused (i.e., TCP RST) means 'try again with IPv4'? I think the TCP standards are fairly clear that a connection should not be tried again after RST. Is there a standard for IPv6 that says otherwise?
asd> Why should an IPv6 connection refused cause a fall back to IPv4? See below. asd> The fact that it got connection refused means: asd> 1) The server has an IPv6 address in DNS Yes (at least usually). asd> 2) The client and server can talk over IPv6 No: this assumes that in addition to both the client and server hosts' IP stacks being IPv6-capable, that the client and server applications on both ends are also IPv6-aware. It is for just this scenario, when the client app is IPv6-aware but the server app is not, that one must fall back to using IPv4. In this case, both client and server host IP stacks are IPv6-capable and the client app (Mozilla) is IPv6-aware, but the server app (Apache) is not IPv6 aware, just IPv4-aware. asd> Why should Mozilla assume that connection refused (i.e., TCP RST) asd> means 'try again with IPv4'? See above. asd> I think the TCP standards are fairly clear that a connection asd> should not be tried again after RST. Is there a standard for asd> IPv6 that says otherwise? Yes, and as soon as I find the exact RFC I will quote chapter and verse for you. :-) By Monday I should be able to track down the experts in Solaris Internet Engineering who know this stuff cold. In the meanwhile, I will quote this portion of RFC 2893 (IPv6 Transition Mechanisms), section 2.3: ... A delay is incurred if the application correctly falls back to using IPv4 if it can not establish communication using IPv6 addresses. If this fallback is not done the application would fail to communicate in this case.
It turns out that the citation I provided from RFC 2893 is the best as present for this, though the Internet Draft draft-ietf-ipv6-default-addr-select-09.txt which I understand is expected to be published as an RFC soon, says: 2. Context in Which the Algorithms Operate ... In this implementation architecture, applications use APIs [8] like getaddrinfo() that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes represented as IPv4-mapped addresses). The application then passes a destination address to the network stack with connect() or sendto(). The application would then typically try the first address in the list, looping over the list of addresses until it finds a working address... ... Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.
RFC 2893 seems to consider only the possibility of making end-to-end communication between the hosts, which getting a TCP RST back confirms. Now, as to, the draft, I'm not quite sure what they're saying. They don't actually define "working address", how nice of them ;-) (BTW: I don't think its soon, because there is no last call on it.) Now, there is draft-shin-ngtrans-application-transition-01.txt which seems to be a better fit (just found it by searching for '"working address" ipv6' on Google). It seems to suggest the behavior you want: "Under this assumption, the applicaions supporting both IPv4 and IPv6 SHOULD be ported to do the iterated job, which tries to create the connection with the host iteratively through all results from DNS queries." [Note, by the way, there is bug 108108 and bug 86917, but 86917 which this might be a dup of appears to be fixed beyond causing this problem (but reopened due to crashing mozilla). Marking qawanted for this reason] Based on this, confirming.
URL: http://www.ietf.org/internet-drafts/d...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Whiteboard: dupme --- see end of comment 4
john beck: please try a more recent nightly build. mozilla does try to fallback to the next address in the DNS hostent if the first results in a connection refused.
Sure, I can try a recent nightly build. But please clarify which first: ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/ has two sparc solaris archives: 2.6, dated this morning, and 7_8_9, dated May 30. I would have thought 7_8_9 would be the one to use except for the date. And since Solaris didn't support IPv6 until Solaris 8, would the 2.6 one even work as a valid test case for this problem? So please give me a hint as to which build to try and I will. Note, however, that if I have to build from source, it will probably have to wait a few days until I have time for that.
john: i don't know anything about the solaris builds provided by mozilla.org... chris seawood might be able to advise you. or, you might want to ask folks on irc://irc.mozilla.org#mozilla for help.
I don't know about the Netscape builds but since the 2.6 build is built on a 2.6 box, I wouldn't expect it to be valid for this test case. I'm not sure if the 7_8_9 build would be valid either since it would be 7 compatible. You may have to build your own distribution using the instructions at http://www.mozilla.org/build/distribution.html . The 7_8_9 build is contributed by Donnie Crawford. I don't know when the next update for that tarball will be. We have at least one bug open on clearing old packages out of /latest/ , bug 156643.
I have now tried with: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1b) Gecko/20020813 (the title bar reports "Build ID: 2002081814"), with the same results as before (i.e., it tries IPv6 then gives up). Darin Fisher: is this a recent enough nightly build?
yes, that looks like a recent enough nightly build. can you build debug and then capture a socket transport log? setenv NSPR_LOG_MODULES nsSocketTransport:5 setenv NSPR_LOG_FILE socket.log then upload socket.log to this bug report, and perhaps it'll indicate what's going wrong. thx!
Yes, I *could* build debug, when I get around to building this myself. So far I've been using binaries that other people at Sun have already built, as I have not had time to do so myself. I don't mind doing so at all; it's just a matter of having time for it. (This is not my regular job. :-) But I could provide truss output any time you like, a sample of which is available in my original Description.
also happens on recent trunk build on freebsd-current with ipv6 enabled. now mozilla shows connection refused on every target. if i enable local apache, there is ipv6 connection message: [Mon Sep 02 02:42:20 2002] [error] [client ::1] File does not exist: /usr/local/www/data/index.html
The problem still occurs with {Build ID: 2002090614}
I think this is fixed. I can connect to IPv6 hosts which doesn't run a IPv6 HTTP-server.
Blocks: IPv6
What about connects that get EHOSTUNREACH, for example there is ipv6 support and both ipv6/4 ips for the host but no ipv6 route. In 1.3.1 such connections stop loading, but no error is displayed and the ipv4 host is not tried.
this bug may have been fixed. i don't have the means to test it out however. can someone please try mozilla 1.4 rc1 or a recent nightly build. thanks!
in fact, the patch for bug 199173 may have resolved this bug altogether. please test. thanks!
Depends on: 199173
Running with the latest nightly: 1.5a (Build ID: 2003060818) [Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030601] this bug does indeed *seem* to be fixed. But our local configuration has changed somewhat, so I am not 100% confident that I am testing the same scenario as that when I originally reported the problem.
I am unable to reproduce this with 1.4rc1 under Linux. Marking WORKSFORME.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.