Closed
Bug 274013
Opened 21 years ago
Closed 13 years ago
EHOSTDOWN prevents firefox from retrying other addresses for making a connection
Categories
(NSPR :: NSPR, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
4.9.1
People
(Reporter: jinmei, Assigned: mz+bugzilla)
Details
Attachments
(1 file)
|
782 bytes,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041210 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041210 Firefox/1.0
Suppose that an web server has both IPv4 and IPv6 connectivity
(e.g., this is the case for www.kame.net). When I tried to make an
HTTP connection to the server with my firefox 1.0 running on FreeBSD
5.3R and the attempt to make a connection over IPv6 failed with an
error of EHOSTDOWN, firefox gave up trying the IPv4 address of the
server, and I failed to get access to the web page even if I had IPv4
reachability to the server.
Reproducible: Always
Steps to Reproduce:
1. get an FreeBSD box to reproduce the problem. Version 5.3 is
preferred, but I believe you can also reproduce it on 4.x.
Global IPv4 reachability should be necessary for the following
steps, but there is no need for IPv6 connectivity.
2. install firefox from the FreeBSD ports collection
3. temporarily configure an IPv6 address on the FreeBSD box as
follows:
# ifconfig IFname inet6 2001:db8::1 prefixlen 64 alias
(IFname should be replaced with a real interface name like "fxp0")
4. add the following (dummy) entries to /etc/hosts of the FreeBSD box:
2001:db8::2 www.kame.net
203.178.141.194 www.kame.net
5. invoke firefox, and try to visit http://www.kame.net/
Actual Results:
firefox will first try to connect to the IPv6 address. After trying
IPv6 neighbor discovery, the attempt of connect(2) will fail with an
error of EHOSTDOWN. Then firefox will stop trying to make a
connection.
Expected Results:
It should then try the IPv4 address (203.178.141.194), since it has
IPv4 connectivity (based on the above assumption).
The following patch to mozilla/nsprpub/pr/src/md/unix/unix_errors.c
seems to fix the problem. I don't know why EHOSTDOWN is ignored in
this context, but as shown in this report, there are at least some
cases where EHOSTDOWN should not be regarded as a fatal error. I also
believe a similar problem can happen for multiple IPv4 addresses.
One more note: if this patch makes sense, we'll probably need to
similar fixes under other mozilla/nsprpub/pr/src/md/*. For example,
we'll need to add WSAEHOSTDOWN in addition to WSAEHOSTUNREACH for
win32.
--- unix_errors.c.orig Fri Dec 3 21:29:37 2004
+++ unix_errors.c Fri Dec 3 21:30:03 2004
@@ -109,6 +109,7 @@
prError = PR_FILE_TOO_BIG_ERROR;
break;
case EHOSTUNREACH:
+ case EHOSTDOWN:
prError = PR_HOST_UNREACHABLE_ERROR;
break;
case EINPROGRESS:
Comment 1•21 years ago
|
||
Darin, it may be better to fix this in the Networking
Library (Necko). You recently fixed a similar problem
with EACCESS (when there is a firewall involved).
Rather than checking for the errors for which we should
retry other addresses, perhaps we should check for the
errors for which we should not retry other addresses?
Just a thought.
Assignee: wtchang → darin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•19 years ago
|
Assignee: darin → wtchang
Updated•19 years ago
|
QA Contact: wtchang → nspr
Seems, issue still actual
Attachment #600894 -
Flags: review?(ted.mielczarek)
Comment 3•13 years ago
|
||
Comment on attachment 600894 [details] [diff] [review]
Patch matching current source
r=wtc.
Attachment #600894 -
Flags: review+
Comment 4•13 years ago
|
||
An alernative fix would be to add a new NSPR error code PR_HOST_DOWN_ERROR
(there is an PR_NETWORK_DOWN_ERROR) and map EHOSTDOWN to PR_HOST_DOWN_ERROR.
I found the relevant code in Necko. The source file is
netwerk/base/src/nsSocketTransport2.cpp.
static nsresult
ErrorAccordingToNSPR(PRErrorCode errorCode)
{
nsresult rv = NS_ERROR_FAILURE;
switch (errorCode) {
case PR_WOULD_BLOCK_ERROR:
rv = NS_BASE_STREAM_WOULD_BLOCK;
break;
case PR_CONNECT_ABORTED_ERROR:
case PR_CONNECT_RESET_ERROR:
rv = NS_ERROR_NET_RESET;
break;
case PR_END_OF_FILE_ERROR: // XXX document this correlation
rv = NS_ERROR_NET_INTERRUPT;
break;
case PR_CONNECT_REFUSED_ERROR:
case PR_NETWORK_UNREACHABLE_ERROR: // XXX need new nsresult for this!
case PR_HOST_UNREACHABLE_ERROR: // XXX and this!
case PR_ADDRESS_NOT_AVAILABLE_ERROR:
// Treat EACCES as a soft error since (at least on Linux) connect() returns
// EACCES when an IPv6 connection is blocked by a firewall. See bug 270784.
case PR_ADDRESS_NOT_SUPPORTED_ERROR:
case PR_NO_ACCESS_RIGHTS_ERROR:
rv = NS_ERROR_CONNECTION_REFUSED;
break;
case PR_IO_TIMEOUT_ERROR:
case PR_CONNECT_TIMEOUT_ERROR:
rv = NS_ERROR_NET_TIMEOUT;
break;
default:
if (IsNSSErrorCode(errorCode))
rv = GetXPCOMFromNSSError(errorCode);
break;
}
SOCKET_LOG(("ErrorAccordingToNSPR [in=%d out=%x]\n", errorCode, rv));
return rv;
}
...
bool
nsSocketTransport::RecoverFromError()
{
NS_ASSERTION(NS_FAILED(mCondition), "there should be something wrong");
SOCKET_LOG(("nsSocketTransport::RecoverFromError [this=%x state=%x cond=%x]\n",
this, mState, mCondition));
// can only recover from errors in these states
if (mState != STATE_RESOLVING && mState != STATE_CONNECTING)
return false;
nsresult rv;
// OK to check this outside mLock
NS_ASSERTION(!mFDconnected, "socket should not be connected");
// can only recover from these errors
if (mCondition != NS_ERROR_CONNECTION_REFUSED &&
mCondition != NS_ERROR_PROXY_CONNECTION_REFUSED &&
mCondition != NS_ERROR_NET_TIMEOUT &&
mCondition != NS_ERROR_UNKNOWN_HOST &&
mCondition != NS_ERROR_UNKNOWN_PROXY_HOST)
return false;
...
}
We would need to add the new NSPR error code PR_HOST_DOWN_ERROR
to the switch statement in ErrorAccordingToNSPR.
Patch checked in on the NSPR trunk (NSPR 4.9.1).
Checking in unix_errors.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/unix_errors.c,v <-- unix_errors.c
new revision: 3.29; previous revision: 3.28
done
Status: NEW → RESOLVED
Closed: 13 years ago
Priority: -- → P2
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 4.9.1
Comment 5•13 years ago
|
||
Honza, just want to make sure you know about this in case it affects happy eyeballs.
Updated•13 years ago
|
Attachment #600894 -
Flags: review?(ted.mielczarek)
Updated•13 years ago
|
Assignee: wtc → pppx
You need to log in
before you can comment on or make changes to this bug.
Description
•