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 (18.104.22.168) 33.241 ms 32.603 ms 36.432 ms 13 POS1-1-0.cr1.n3 (22.214.171.124) 33.531 ms 33.708 ms 33.044 ms 14 POS1-1-0.cr1.m3 (126.96.36.199) 32.484 ms 32.598 ms 33.339 ms 15 POS4-0-0.cr1.s3 (188.8.131.52) 33.387 ms 32.529 ms 34.693 ms 16 POS4-0-0.cr2.f3 (184.108.40.206) 33.511 ms 35.034 ms 32.814 ms 17 FastEthernet5-0.cr1.f4.nextra.de (220.127.116.11) 34.129 ms 33.360 ms 33.175 ms 18 POS4-1-0.cr1.f3 (18.104.22.168) 47.957 ms 49.416 ms 47.891 ms 19 POS1-1-0.cr1.n3 (22.214.171.124) 49.770 ms 49.705 ms 47.857 ms 20 POS1-1-0.cr1.m3 (126.96.36.199) 50.354 ms 50.423 ms 48.773 ms 21 POS4-0-0.cr1.s3 (188.8.131.52) 48.132 ms 47.657 ms 47.677 ms 22 POS4-0-0.cr2.f3 (184.108.40.206) 48.461 ms 48.791 ms 47.452 ms 23 FastEthernet5-0.cr1.f4.nextra.de (220.127.116.11) 47.679 ms 48.949 ms 48.581 ms 24 POS4-1-0.cr1.f3 (18.104.22.168) 64.177 ms 62.881 ms 63.814 ms 25 POS1-1-0.cr1.n3 (22.214.171.124) 63.817 ms 62.973 ms 62.805 ms 26 POS1-1-0.cr1.m3 (126.96.36.199) 62.288 ms 64.007 ms 64.539 ms 27 POS4-0-0.cr1.s3 (188.8.131.52) 63.319 ms 62.955 ms 63.755 ms 28 POS4-0-0.cr2.f3 (184.108.40.206) 63.780 ms 64.153 ms 63.535 ms 29 FastEthernet5-0.cr1.f4.nextra.de (220.127.116.11) 65.330 ms 65.590 ms 141.461 ms 30 POS4-1-0.cr1.f3 (18.104.22.168) 78.795 ms 78.423 ms 79.145 ms pi
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 22.214.171.124... Connected to livejournal.com (126.96.36.199). 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
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?)
keywords says "testcase", but where's it? confirming bug?
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
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.
-> 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).
> 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...)
not worth a special case