Error message "connection refused" misleading when real error is "host unreachable"




16 years ago
2 years ago


(Reporter: Ralf Hauser, Unassigned)


({embed, helpwanted, testcase})

embed, helpwanted, testcase

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
At one point, unfortunately, my ADSL was down. Similarly, the problem can be
reproduced if the LAN or modem cable is inadvertently unplugged.

When trying to access for example cnn, I got a pop-up saying:
<<The connection was refused when attempting to connect to>> which
is obviously not right since they would never refuse.
I assume it is technically possible to be more precise. Therefore, I suggest the
error message to be:
<< is currently unreachable. You might want to use traceroute
(tracert under windows) to determine where the problem lies.>>

Build 2002053012

Comment 1

16 years ago
actually, the problem is that we are mapping most socket errors to connection
refused even though we could map them to something else.  such as "no route to
host."  i've been meaning to clean this up.

-> 1.2alpha (perhaps)
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla1.2alpha


16 years ago
Keywords: testcase

Comment 2

16 years ago
I'd like to add that this is a very confusing bug for dialup
(modem) users which always triggers if the connection has been
hung up in the meantime and the modem is still dialing while
Mozilla times out.

In fact, with the modem already dialing, "Connection refused"
caused both my Dad and my sister to check the cable to the
modem (the "connection").. :-}

Maybe Mozilla could use some switch "on dialup connection yes/no"
which would adjust (lengthen) the connect() timeout (if supported
by host os) and would make it handle ICMP network/host unreachables
that were sent by the user's router a little more sensible (eg
simple retry a connect() if the last data transfer was more than
$ROUTERIDLETIMEOUT seconds away and if $TIMETODIALUP seconds haven't
passed yet.)

That's for semi-permanent connections that dial automatically, _not_
for manually dialed connections, so "Work on/offline" won't work.

Just my EUR 0.02 :-)

Comment 3

16 years ago
The new "error page" (instead of dialog box) model has been implemented, but not
turned on by default.  When (if) the error pages replace dialog boxes, this bug
may  be affected.

bug 156997 - [RFE] Should use error page and not dialog for inaccessible pages 

Once error pages replace dialog boxes, the following bug would apply:
bug 156997 - Fix up error pages with plain English descriptions and a nice

After the back-end (socket mapping) is complete, the front-end can be fixed up.
(Or prepare the front-end, and wait for the back-end to be complete).. etc...


16 years ago
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Comment 4

16 years ago
downgrading to enhancement... might not get to this by moz 1.2
Severity: normal → enhancement
Keywords: embed, mozilla1.2, nsbeta1
Priority: P3 → P5

Comment 5

16 years ago
-> moz 1.3
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Comment 6

15 years ago
*** Bug 180472 has been marked as a duplicate of this bug. ***


15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.3beta

Comment 7

15 years ago
Connection refused when actually connection broken or destination unreachable is
a lie. As noted in comment 2, it causes people to waste time trying to fix
something unfixable. That makes enhancement an inappropriate severity.

Comment 8

15 years ago
actually changing
Severity: enhancement → normal
OS: Windows 2000 → All


15 years ago
Target Milestone: mozilla1.3beta → Future

Comment 9

15 years ago
Zurich this afternoon had a major DSL outage and I had just downloaded 2003021208:
Here comes the newest report:

For URLs whose numeric IP address was cached, I got the
<<The document contains no data>> alert - this is obviously wrong because there
was no way it would these hosts at all.

More appropriately, my SSH said: <<Connection timed out>>.
Another but related to the same error message I support is

Comment 10

15 years ago
ralf: the error message "the document contains no data" is only popping up
because of bug 189965, which will be fixed by 1.3 final.  the business about
distinguishing a connection refused error from a route error is still
unresolved.  that's what this bug is about ;-)
Summary: Error message "connection refused" misleading → Error message "connection refused" misleading when real error is "host unreachable"

Comment 11

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 12

15 years ago
*** Bug 204182 has been marked as a duplicate of this bug. ***


15 years ago
Blocks: 204182


15 years ago
QA Contact: tever → httpqa
Is there something happening to the bug?
I think the behavior is so confusing that there are many poeple who see this but
do not realize there is a mozilla problem.

Comment 14

14 years ago
patches welcome :)
Keywords: helpwanted
Priority: P5 → --

Comment 15

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---

Comment 16

11 years ago
I think mozilla applies the ( extensively platform-independent ) socket interface of the OS. Whether the server temporarily is down, not listening at the specified port or actually refuses a connection to the client address, "ECONNREFUSED" is thrown as error by "SockConnect" ( at least for Os/2 ).
One solution could be to specify another message like "no response from server" to the mapped mozilla error "PR_CONNECT_REFUSED_ERROR".
Relevant files : ( it's automatically generated, don't know from which sources ? ).
And, for Os/2, .

Problem is, some other modules like ldap also uses "PR_CONNECT_REFUSED_ERROR". And there the meaning really could be "connection refused". 
So a better solution might be to introduce an new error - "PR_CONNECT_NO_RESPONSE_ERROR" ( in "prerr.c" ) for instance - and map the socket error "ECONNREFUSED" to this new "PR_" error.

To supply concrete patches I need to know whether the socket error is the reason also for other platforms ( x, win, and mac at least ) and what the source of "prerr.c" is. And to avoid regressions some advice of someone knowing the "nsprbub" module would be nice ...

Comment 17

11 years ago
(In reply to comment #16)
> So a better solution might be to introduce an new error -
> "PR_CONNECT_NO_RESPONSE_ERROR" ( in "prerr.c" ) for instance - and map the
> socket error "ECONNREFUSED" to this new "PR_" error.
"no response while trying to connect to server" could be an appropriate message.

Comment 18

11 years ago
Created attachment 281686 [details] [diff] [review]
changes the text from "the connection was refused" to "no response".

"security/nss" and "directory/c-sdk/ldap" ( which also use "PR_CONNECT_REFUSED_ERROR" ) seems to work indepedently. So I can leave this alone and just change the text in the locales ( here for the seamonkey suite, tested on trunk 2007-09-18 5:00 , Build identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a8pre) Gecko/2007092019 SeaMonkey/2.0a1pre ) ...
Attachment #281686 - Flags: review+


11 years ago
Attachment #281686 - Flags: review+ → review?(darin.moz)

Comment 19

10 years ago
Stefan, if you still want this patch in the tree, you should find another reviewer. I think Darin doesn't do that any more. You can look on for "suite".

And if you ask me, you should at the same time change the respective files under mail/, too, see*refused&regexp=on&find=proper

Comment 20

10 years ago
Comment on attachment 281686 [details] [diff] [review]
changes the text from "the connection was refused" to "no response".

Sorry, I'm the wrong reviewer for this change.
Attachment #281686 - Flags: review?(darin.moz)

Comment 21

10 years ago
OK, will change patch and reviewer as proposed in #19 / #20 until the weekend ...

Comment 22

5 years ago
why not keep the original text as returned by the operating system? this mania of Firefox to replace all error messages with a paraphrase is really, really annoying. Why is this being done at all, exactly? Most object oriented languages, including C++, support putting arbitrarily long strings into exceptions, so there's really no need to map all error conditions to integers and then back to strings. Moreover, as exceptions are fully-fledged objects, they can actually contain _both_ a string and an integer code, which should ease the transition. An usable error messages are one place where bloat is justifiable.

Do we really have to keep strace and tcpdump around to make sense of Firefox' error messages?
The connect() call on Linux has nice diagnostics like ENETUNREACH and ETIMEDOUT. Windows provides WSAENETUNREACH, WSAETIMEDOUT.

Even if they are not mandated by a standard or are not present on OS/2 the presence of these values can be detected. Does Mozilla even still run on OS/2?

So the error here is that Mozilla uses nice portable socket interface with nice portable diagnostics and then trashes the diagnostics obtained and just says that connection was refused whatever the error was.

The patch only makes the error message as vague as the Mozilla error handling is. It does not fix the actual problem.

Comment 24

5 years ago
This is broken beyond belief. If Windows gives sucky error messages, then just have Firefox on Windows relay those. But, for the love of God, keep the usable messages from the OS when Firefox happens to run on a sane platform!

Use perror() or strerror() where available. Use a generic/paraphrased message where strerror() is not available, AND ONLY THERE.

The worst part is that this Windows mentality is all over the place. I just logged another bug where Thunderbird transformed a "disk full" error message into "please switch off encryption"!
Actually, windows is not to blame here.

It provides perfectly fine diagnostics on it connect() call according to the MSDN docs.

Mozilla just 'translates' the messages into unintelligibility.

Comment 26

5 years ago
(In reply to Michal 'hramrach' Suchanek from comment #23)
> Does Mozilla even still run on OS/2?

OS/2 is a holdover nomenclature from the IBM origins of the OS, plus there are still some OS/2 users around nursing their systems into the future via eCS updates. Its users are all running the ESR branch currently, as manpower is lacking to port or update tools required for building main branch.
ETIMEDOUT based on comment 21
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.