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

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Ralf Hauser]

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 www.cnn.com>> 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:
<<www.cnn.com is currently unreachable. You might want to use traceroute
(tracert under windows) to determine where the problem lies.>>

Build 2002053012

Comment 1

[Darin Fisher]

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)

Comment 2

[Johannes Teveßen]

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

[Ryan Pertusio]

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 
(placeholder)

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

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...

Comment 4

[Darin Fisher]

downgrading to enhancement... might not get to this by moz 1.2

Comment 5

[Darin Fisher]

-> moz 1.3

Comment 6

[Michael Lefevre]

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

Comment 7

[Felix Miata]

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

[Felix Miata]

actually changing

Comment 9

[Ralf Hauser]

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
http://bugzilla.mozilla.org/show_bug.cgi?id=159324.

Comment 10

[Darin Fisher]

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 ;-)

Comment 11

[Samir Gehani]

adt: nsbeta1-

Comment 12

[Darin Fisher]

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

Comment 13

[Michal 'hramrach' Suchanek]

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

[Darin Fisher]

patches welcome :)

Comment 15

[Darin Fisher]

-> default owner

Comment 16

[Stefan Schmohl]

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 : http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/misc/prerr.c#64 ( it's automatically generated, don't know from which sources ? ).
And, for Os/2, http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/os2/os2_errors.c#790 .

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

[Stefan Schmohl]

(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

[Stefan Schmohl]

Attachment: 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 ) ...

Comment 19

[Peter Weilbacher]

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 http://www.mozilla.org/owners.html for "suite".

And if you ask me, you should at the same time change the respective files under mail/, too, see http://mxr.mozilla.org/seamonkey/search?string=connection.*refused&regexp=on&find=proper

Comment 20

[Darin Fisher]

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.

Comment 21

[Stefan Schmohl]

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

Comment 22

[Alain Knaff]

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?

Comment 23

[Michal 'hramrach' Suchanek]

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

[Alain Knaff]

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"!

Comment 25

[Michal 'hramrach' Suchanek]

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

[Felix Miata]

(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 http://www.ecomstation.com/ 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.

Comment 27

[Patrick McManus [:mcmanus]]

ETIMEDOUT based on comment 21