115982 - Conn: host unreachable "TTL equals 0 during transit"

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Boris 'pi' Piwinger]

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

Comment 1

[Bradley Baetz (:bbaetz)]

->networking

Comment 2

[Michael Lefevre]

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

Comment 3

[Michael Lefevre]

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

Comment 4

[Boris 'pi' Piwinger]

ACK, this is a dupe of bug 95997.

pi

*** This bug has been marked as a duplicate of 95997 ***

Comment 5

[benc]

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

Comment 6

[Daniel Wang]

keywords says "testcase", but where's it?
confirming bug?

Comment 7

[benc]

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"

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[benc]

my ISP doesn't send back those errors, the router just discards the packets :(

Comment 10

[Boris 'pi' Piwinger]

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

Comment 11

[benc]

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.

Comment 12

[benc]

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

Comment 13

[Boris 'pi' Piwinger]

> 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

Comment 14

[benc]

(whoops... I did change the summary...)

Comment 15

[Patrick McManus [:mcmanus]]

not worth a special case