From: Bela Lubkin <email@example.com> Subject: Re: Telnet: route to host Date: 3 Aug 2005 17:25:01 -0400 Message-ID: <firstname.lastname@example.org> References: <20050803131820.A17532@egps.egps.com>
<20050803164313.B25182@egps.egps.com> Nachman Yaakov Ziskind wrote: > Bela Lubkin wrote (on Wed, Aug 03, 2005 at 03:46:25PM -0400): > > Nachman Yaakov Ziskind wrote: > > > > > > What gets me is when I connect to a non-functioning port, I get: > > > > > > $ telnet 10.1.1.4 5555 > > > Trying 10.1.1.4... > > > telnet: Unable to connect to remote host: No route to host > > > It's probably running an internal firewall which is set to generate ICMP > > host unreachable responses on attempts to access blocked ports. It's > > like the voice saying "nobody in here but us chickens", except computers > > are much more likely to take such a response literally... > > I found the telnet problem (I had to insert an IPTABLES rule). But that > wasn't my question, so I'll restate it: > > Why does the OpenServer box generate a 'no route to host' error in a > case like this? It should either wait and time out, or return > 'connection refused'. What was the generic IPTABLES rule you were overriding? I'm guessing something like: all ports not otherwise covered: reject with "ICMP destination unreachable: host unreachable" to which you added: TCP port 23 [telnet]: accept The message isn't bogus if the remote host actually sent a "host unreachable" message! >Bela<
In other words, it isn't your computer that decided there was no route; it was another system returning a message that it interpreted that way.
See Network Routing Basics also.
Got something to add? Send me email.
Some people, when confronted with a problem, think "I know, I'll use sed." Now they have two problems. (Jamie Zawinski)