Prev: FIOS?
Next: remote access to desktops
From: Rick Jones on 15 Jan 2010 15:21
Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> wrote:
> Nothing. As Moe wrote, there is no route so the ICMP echo reply cannot
> be sent, end of the story. Maybe the kernel sends a "network
> unreachable" error to itself, but this is rather pointless IMHO.

Hopefully it will at least increment a statistic somewhere. But
indeed, there is not anything else for it to do really.

rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: D. Stussy on 15 Jan 2010 16:42
"Moe Trin" <ibuprofin(a)painkiller.example.tld.invalid> wrote in message
news:slrnhkuu2o.2l2.ibuprofin(a)compton.phx.az.us...
> On Thu, 14 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article <1lp850idw5sg.15tb7yx3ssl8u$.dlg(a)40tude.net>, Nikola Novak wrote:
>
> >What happens if a router receives and ICMP Echo request, but the
> >source address in the IP packet it is contained in doesn't match any
> >entries in its routing table, and the default gateway isn't set?
>
> It forwards the packet to the destination host. If that destination
> is itself and the ping function is not disabled, it can't reply - so
> drop the packet. Originally, it would not try to send an ICMP
> error (requirement - no ICMP error to ICMP), but that's now been
> re-written as "no ICMP error to an ICMP _error_ packet" and a ping
> isn't an error. None the less, who would it try to send the error
> to? You can't get there from here.

Obviously wrong. It can't send an echo reply to the ping originator
because there's no route to the host. The packet is dropped as ICMP
reply-type packets don't generate ICMP error packets.


From: Moe Trin on 15 Jan 2010 21:00
On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in
article <hiqinp$62a$4(a)usenet01.boi.hp.com>, Rick Jones wrote:

>Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> wrote:

>> Maybe the kernel sends a "network unreachable" error to itself,
>> but this is rather pointless IMHO.

>Hopefully it will at least increment a statistic somewhere. But
>indeed, there is not anything else for it to do really.

I could be wrong (I'm not a C programmer), but I think this results
in a "Martian Packet" error message in /var/log/messages.

Old guy
From: Moe Trin on 15 Jan 2010 21:01
On Fri, 15 Jan 2010, in the Usenet newsgroup comp.os.linux.networking, in
article <hiqppi$sgb$1(a)snarked.org>, D. Stussy wrote:

>"Moe Trin" <ibuprofin(a)painkiller.example.tld.invalid> wrote

>> Originally, it would not try to send an ICMP error (requirement
>> - no ICMP error to ICMP), but that's now been re-written as "no
>> ICMP error to an ICMP _error_ packet" and a ping isn't an error.

>The packet is dropped as ICMP reply-type packets don't generate
>ICMP error packets.

http://www.rfc-editor.org/errata_search.php?rfc=792

As written, the fourth paragraph of the "Introduction" reads

The ICMP messages typically report errors in the processing of
datagrams. To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages. Also ICMP
messages are only sent about errors in handling fragment zero of
fragemented datagrams. (Fragment zero has the fragment offeset equal
zero).

Errata ID: 576 corrects those two typ0s in the next-to-last line, and
Errata ID: 1231 changes the second sentence as referred above

Section Introduction says:
no ICMP messages are sent about ICMP messages

It should say:
no ICMP messages are sent about ICMP error messages

Notes:

For instance, echo replies are sent about echo messages. The context of
the original sentence indicates that the author only referred to error
messages but the sentence itself is not clear and I've seen the
editorial error reproduced in some places.

But in this case the point remains that no route to host precludes
sending an ICMP error. It was that original requirement than caused
Van Jacobson chose to use UDP for the LBL version of traceroute rather
than ICMP echo (-I option on current versions of LBL traceroute, and
only mode on microsoft's TRACERT.EXE).

Old guy
From: lrhorer on 16 Jan 2010 20:03
Nikola Novak wrote:

> Hello,
>
> What happens if a router receives and ICMP Echo request, but the
> source address in the IP packet it is contained in doesn't match any
> entries in its routing table, and the default gateway isn't set?
>
> Thanks,
> Nikola

Is there a specific reason you are asking, or are you just curious?
The reason I ask is because this is not a terribly uncommon failure.
Any time one sets up one or more hosts on a network segment with an
incorrect subnet mask, this is precisely what can happen. If one host
has a wider netmask than another host, so that host A is in host B's
subnet, but host B is not in host A's subnet, then the situation you
describe can indeed happen. There might be some implementations of arp
where this would not happen, but generally speaking host A should be
able to send the arp packet back to host B when it queries for host A's
MAC address, but then when the ICMP packet comes in, host A won't know
what to do with it unless it has a default route set.

It also happens all the time on core routers, whenever a host sends a
ping out to a non-existent IP address or if a non-routable address
packet leaks out in to the internet. Sooner or later, the packet will
hit a router without a default gateway, and the packet dies.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: FIOS?
Next: remote access to desktops