public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Redboot responds to ICMP echo when it shouldn't.
@ 2011-03-21 20:49 Grant Edwards
  2011-03-21 21:36 ` Gary Thomas
  0 siblings, 1 reply; 5+ messages in thread
From: Grant Edwards @ 2011-03-21 20:49 UTC (permalink / raw)
  To: ecos-discuss

While testing my rewrite of Redboot DHCP support, I've noticed that
Redboots "ping" support is also broken.  Redboot responds to ICMP echo
requests that it shouldn't.

Redboot will respond to ICMP echo requests _before_ it has received an
IP address from the BOOTP/DHCP server.  The destination IP address in
the ICMP echo packet _does_not_match_ Redboot's IP address, but it
responds anyway with a source IP address of 0.0.0.0.

Is this behavior intentional?

If so, why?

-- 
Grant Edwards               grant.b.edwards        Yow! ... I see TOILET
                                  at               SEATS ...
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Redboot responds to ICMP echo when it shouldn't.
  2011-03-21 20:49 [ECOS] Redboot responds to ICMP echo when it shouldn't Grant Edwards
@ 2011-03-21 21:36 ` Gary Thomas
  2011-03-22 11:16   ` [ECOS] " Grant Edwards
  0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-03-21 21:36 UTC (permalink / raw)
  To: Grant Edwards; +Cc: ecos-discuss

On 03/21/2011 02:21 PM, Grant Edwards wrote:
> While testing my rewrite of Redboot DHCP support, I've noticed that
> Redboots "ping" support is also broken.  Redboot responds to ICMP echo
> requests that it shouldn't.
>
> Redboot will respond to ICMP echo requests _before_ it has received an
> IP address from the BOOTP/DHCP server.  The destination IP address in
> the ICMP echo packet _does_not_match_ Redboot's IP address, but it
> responds anyway with a source IP address of 0.0.0.0.
>
> Is this behavior intentional?

Not as far as I know.

How are those packets even being received?  Are they going to a broadcast
address (IP or ESA)?  Normally incoming packets are filtered by ESA by
the network driver before they get pushed up the stack and processed.

You might find that RedBoot replies to [some, maybe all] packets which
somehow match it's ESA, but not IP address as well.

>
> If so, why?
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Re: Redboot responds to ICMP echo when it shouldn't.
  2011-03-21 21:36 ` Gary Thomas
@ 2011-03-22 11:16   ` Grant Edwards
  2011-03-22 13:05     ` Gary Thomas
  0 siblings, 1 reply; 5+ messages in thread
From: Grant Edwards @ 2011-03-22 11:16 UTC (permalink / raw)
  To: ecos-discuss

On 2011-03-21, Gary Thomas <gary@mlbassoc.com> wrote:
> On 03/21/2011 02:21 PM, Grant Edwards wrote:
>> While testing my rewrite of Redboot DHCP support, I've noticed that
>> Redboots "ping" support is also broken.  Redboot responds to ICMP echo
>> requests that it shouldn't.
>>
>> Redboot will respond to ICMP echo requests _before_ it has received an
>> IP address from the BOOTP/DHCP server.  The destination IP address in
>> the ICMP echo packet _does_not_match_ Redboot's IP address, but it
>> responds anyway with a source IP address of 0.0.0.0.
>>
>> Is this behavior intentional?
>
> Not as far as I know.
>
> How are those packets even being received?

The "pinging" host's ARP cache still has RedBoot's MAC address
associated with the IP address bing pinged.

> Are they going to a broadcast address (IP or ESA)?

Unicast Ethernet MAC, unicast IP.

> Normally incoming packets are filtered by ESA by the network driver
> before they get pushed up the stack and processed.

Right.  And then the IP layer should filter them by IP address, right?

> You might find that RedBoot replies to [some, maybe all] packets
> which somehow match it's ESA, but not IP address as well.

That appears to be the case.

I assumed that devices shouldn't respond to ICMP ping requests that
don't match their IP address.  Am I wrong?

The DHCP server (which is sending the ICMP echo request before
offering an IP address) appears to be ignoring the reply from IP
address 0.0.0.0, but I can imagine somewhat contrived situations where
it might cause problems.

-- 
Grant Edwards               grant.b.edwards        Yow! Let's all show human
                                  at               CONCERN for REVERAND MOON's
                              gmail.com            legal difficulties!!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Re: Redboot responds to ICMP echo when it shouldn't.
  2011-03-22 11:16   ` [ECOS] " Grant Edwards
@ 2011-03-22 13:05     ` Gary Thomas
  2011-03-22 13:35       ` Grant Edwards
  0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-03-22 13:05 UTC (permalink / raw)
  To: Grant Edwards; +Cc: ecos-discuss

On 03/21/2011 02:36 PM, Grant Edwards wrote:
> On 2011-03-21, Gary Thomas<gary@mlbassoc.com>  wrote:
>> On 03/21/2011 02:21 PM, Grant Edwards wrote:
>>> While testing my rewrite of Redboot DHCP support, I've noticed that
>>> Redboots "ping" support is also broken.  Redboot responds to ICMP echo
>>> requests that it shouldn't.
>>>
>>> Redboot will respond to ICMP echo requests _before_ it has received an
>>> IP address from the BOOTP/DHCP server.  The destination IP address in
>>> the ICMP echo packet _does_not_match_ Redboot's IP address, but it
>>> responds anyway with a source IP address of 0.0.0.0.
>>>
>>> Is this behavior intentional?
>>
>> Not as far as I know.
>>
>> How are those packets even being received?
>
> The "pinging" host's ARP cache still has RedBoot's MAC address
> associated with the IP address bing pinged.
>
>> Are they going to a broadcast address (IP or ESA)?
>
> Unicast Ethernet MAC, unicast IP.

This is happening because of a stale ARP cache on your host.

>
>> Normally incoming packets are filtered by ESA by the network driver
>> before they get pushed up the stack and processed.
>
> Right.  And then the IP layer should filter them by IP address, right?
>
>> You might find that RedBoot replies to [some, maybe all] packets
>> which somehow match it's ESA, but not IP address as well.
>
> That appears to be the case.
>
> I assumed that devices shouldn't respond to ICMP ping requests that
> don't match their IP address.  Am I wrong?

No, I think you are correct.  The IP code may match if the local IP address
is set to IPANY (i.e. 0.0.0.0).

>
> The DHCP server (which is sending the ICMP echo request before
> offering an IP address) appears to be ignoring the reply from IP
> address 0.0.0.0, but I can imagine somewhat contrived situations where
> it might cause problems.

This seems to be a pretty rare condition, caused by a stale ARP cache.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Re: Redboot responds to ICMP echo when it shouldn't.
  2011-03-22 13:05     ` Gary Thomas
@ 2011-03-22 13:35       ` Grant Edwards
  0 siblings, 0 replies; 5+ messages in thread
From: Grant Edwards @ 2011-03-22 13:35 UTC (permalink / raw)
  To: ecos-discuss

On 2011-03-21, Gary Thomas <gary@mlbassoc.com> wrote:

>>> How are those packets even being received?
>>
>> The "pinging" host's ARP cache still has RedBoot's MAC address
>> associated with the IP address bing pinged.
>>
>>> Are they going to a broadcast address (IP or ESA)?
>>
>> Unicast Ethernet MAC, unicast IP.
>
> This is happening because of a stale ARP cache on your host.

Right.

>>> Normally incoming packets are filtered by ESA by the network driver
>>> before they get pushed up the stack and processed.
>>
>> Right.  And then the IP layer should filter them by IP address, right?
>>
>>> You might find that RedBoot replies to [some, maybe all] packets
>>> which somehow match it's ESA, but not IP address as well.
>>
>> That appears to be the case.
>>
>> I assumed that devices shouldn't respond to ICMP ping requests that
>> don't match their IP address.  Am I wrong?
>
> No, I think you are correct.  The IP code may match if the local IP
> address is set to IPANY (i.e. 0.0.0.0).

But doesn't Redboot use 0.0.0.0 as a sentinel value meaning "I don't
have an IP address" rather than "my address is IP_ANY"?

>> The DHCP server (which is sending the ICMP echo request before
>> offering an IP address) appears to be ignoring the reply from IP
>> address 0.0.0.0, but I can imagine somewhat contrived situations
>> where it might cause problems.
>
> This seems to be a pretty rare condition, caused by a stale ARP
> cache.

Agreed.

-- 
Grant Edwards               grant.b.edwards        Yow! I feel like a wet
                                  at               parking meter on Darvon!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-03-21 20:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-21 20:49 [ECOS] Redboot responds to ICMP echo when it shouldn't Grant Edwards
2011-03-21 21:36 ` Gary Thomas
2011-03-22 11:16   ` [ECOS] " Grant Edwards
2011-03-22 13:05     ` Gary Thomas
2011-03-22 13:35       ` Grant Edwards

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).