Closed Bug 115982 Opened 23 years ago Closed 9 years ago

Conn: host unreachable "TTL equals 0 during transit"

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: 3.14, Unassigned)

Details

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

My apologies if this is a dupe, I had no idea how to search for it.

When you click on a link and the host is unreachable (in my case it was a
routing problem, the packages ran in circles) you get a "done" in the status
bar, but you stay on the same page. This is pretty bad, you don't see that and
what went wrong.

I cannot say which problems exactly cause this problem, but I have seen it a few
times now. Here is one traceroute example when the problem occured:

12  POS4-1-0.cr1.f3 (212.169.180.29)  33.241 ms  32.603 ms  36.432 ms
13  POS1-1-0.cr1.n3 (212.169.180.30)  33.531 ms  33.708 ms  33.044 ms
14  POS1-1-0.cr1.m3 (212.169.180.34)  32.484 ms  32.598 ms  33.339 ms
15  POS4-0-0.cr1.s3 (212.169.180.25)  33.387 ms  32.529 ms  34.693 ms
16  POS4-0-0.cr2.f3 (212.169.180.21)  33.511 ms  35.034 ms  32.814 ms
17  FastEthernet5-0.cr1.f4.nextra.de (212.169.187.1)  34.129 ms  33.360 ms 
33.175 ms
18  POS4-1-0.cr1.f3 (212.169.180.29)  47.957 ms  49.416 ms  47.891 ms
19  POS1-1-0.cr1.n3 (212.169.180.30)  49.770 ms  49.705 ms  47.857 ms
20  POS1-1-0.cr1.m3 (212.169.180.34)  50.354 ms  50.423 ms  48.773 ms
21  POS4-0-0.cr1.s3 (212.169.180.25)  48.132 ms  47.657 ms  47.677 ms
22  POS4-0-0.cr2.f3 (212.169.180.21)  48.461 ms  48.791 ms  47.452 ms
23  FastEthernet5-0.cr1.f4.nextra.de (212.169.187.1)  47.679 ms  48.949 ms 
48.581 ms
24  POS4-1-0.cr1.f3 (212.169.180.29)  64.177 ms  62.881 ms  63.814 ms
25  POS1-1-0.cr1.n3 (212.169.180.30)  63.817 ms  62.973 ms  62.805 ms
26  POS1-1-0.cr1.m3 (212.169.180.34)  62.288 ms  64.007 ms  64.539 ms
27  POS4-0-0.cr1.s3 (212.169.180.25)  63.319 ms  62.955 ms  63.755 ms
28  POS4-0-0.cr2.f3 (212.169.180.21)  63.780 ms  64.153 ms  63.535 ms
29  FastEthernet5-0.cr1.f4.nextra.de (212.169.187.1)  65.330 ms  65.590 ms 
141.461 ms
30  POS4-1-0.cr1.f3 (212.169.180.29)  78.795 ms  78.423 ms  79.145 ms

pi
->networking
Assignee: joki → neeti
Component: Event Handling → Networking
QA Contact: madhur → benc
dunno if this bug is dupe, but i was just about to submit the same bug when i
found this one.

in my case, it happened with livejournal.com - their site is entirely database
driven and the database is currently offline. can connect to their server, but
it doesn't do much.  this is a session i just did with telnet:

$ telnet www.livejournal.com 80
Trying 66.150.15.150...
Connected to livejournal.com (66.150.15.150).
Escape character is '^]'.
get /
Connection closed by foreign host.

(there's a pause of 2-3 seconds between the get command and the connection
being dropped)

IE in this situation sits there for a few seconds and then comes back with its
"the page cannot be displayed" page.  as the reporter said, mozilla says "done"
and leaves you on the previous page.  not helpful.

i'm using Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6) Gecko/20011120


doh... having returned to my previous search, i believe this bug is a duplicate of
bug 95997
ACK, this is a dupe of bug 95997.

pi

*** This bug has been marked as a duplicate of 95997 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
REOPEN:

This is actually a different error (reset vs. unreachable). I need to make this
a testcase as well, although I'm not sure how I could configure this on purpose
(maybe hacking the local routing tables?)
Status: RESOLVED → UNCONFIRMED
Keywords: testcase
Resolution: DUPLICATE → ---
Summary: http-error not displayed → host unreachable
keywords says "testcase", but where's it?
confirming bug?
Summary: host unreachable → host unreachable [status bar reads "done"]
I've been looking for an ip address that is unreachable, but I haven't found one.

testcase basically means "I think I should test it"
benc, could you not use an address from one of the reserved blocks?  Like
10.134.127.118 for example.... if you pick a random address in 10.255.255.255,
the chances of anyone actually having that IP on their local LAN are pretty slim....
my ISP doesn't send back those errors, the router just discards the packets :(
Removing testcase keyword. Trying http://10.255.255.255/ Mozilla waits for the
connect, then I get an alert that the operation timed out. This is not exactly
the thing as in comment 0, but it suggest, we cannot reproduce this problem. -> WFM

pi
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 21 years ago
Keywords: testcase
Resolution: --- → WORKSFORME
Just because you cannot reproduce the problem doesn't mean it is invalid.

This error is distinct from other error conditions that are typically reported,
and I think we should hand them back.

For example, when this does happen, it would suggest a user should call their
network administrator to let them know the router might have died.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
-> NEW
I found a site on my intranet that is unreachable, and it behaves differently.
See bug 204182, basically the status bar never updates.

From looking at your traceroute session, I think you were on a nework that had
an infinite loop (see yow your traceroute keeps going in circles?)

I did not change the summary, but what should happen for you, bssed on your
traceroute info is that a different ICMP error should be returned. Since you did
not pu the entire traceroute session, I'm not sure what the final fate of your
looping packets was.

This is pretty rare, so severity=trivial.

packets are sent, and loop in circles until the TTL is decremented to zero. Then
ICMP on the router will send back a "time exceeded: TTL equals 0 during transit"
message via ICMP.

This would be really hard to reproduce, and is pretty rare (even rarer to catch
it "on tape", so to speak).
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: host unreachable [status bar reads "done"] → Conn: host unreachable "TTL equals 0 during transit"
> From looking at your traceroute session, I think you were
> on a nework that had an infinite loop (see yow your
> traceroute keeps going in circles?)

There was a loop, but it was "out in the wild".

> I did not change the summary, but what should happen for
> you, bssed on your traceroute info is that a different
> ICMP error should be returned. Since you did not pu the
> entire traceroute session, I'm not sure what the final
> fate of your looping packets was.

I don't remember, but it was fixed shortly thereafter.

> This would be really hard to reproduce,

Only if someone offers to play with his routing tables.

pi
(whoops... I did change the summary...)
Assignee: neeti → nobody
QA Contact: benc → networking
not worth a special case
Status: NEW → RESOLVED
Closed: 21 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.