Mailing List Archive

That is what is supposed to happen.

Rationale:
You asked for all packets containing the UDP protocol and you got them.

An analyzer that filtered for UDP and did not show you these pacekts
to you would be broken. Ethereal is not broken in this regard.




On Sun, 20 Mar 2005 12:14:27 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
> Why are ICMP packets displayed when a display filter is used that should
> exclude them?
>
> For example, when running a traceroute, and with a display filter of
> "udp", in addition to the outbound UDP datagrams, the ICMP messages
> returned from each router are displayed as well. I know that the ICMP
> datagrams include the headers of the datagrams that are being reported
> on, but apparently their presence allows them to pass through the
> display filter. Is this behavior intentional? If so, what is the rationale?
>
> Bob Snyder
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>

The rationale is pretty straightforward there's udp in the frame so it
matches "udp".

What you might want to do is filter with "udp and not icmp".

On Sun, 20 Mar 2005 12:14:27 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
> Why are ICMP packets displayed when a display filter is used that should
> exclude them?
>
> For example, when running a traceroute, and with a display filter of
> "udp", in addition to the outbound UDP datagrams, the ICMP messages
> returned from each router are displayed as well. I know that the ICMP
> datagrams include the headers of the datagrams that are being reported
> on, but apparently their presence allows them to pass through the
> display filter. Is this behavior intentional? If so, what is the rationale?
>
> Bob Snyder
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan

It's an interesting argument. I wouldn't expect the payload of an ICMP packet to matter. UDP is usually encapsulated in an IP datagram, therefore I wouldn't expect the parser to "see" the UDP inside of an ICMP message and decode it as such.

But I guess I can't fault the other rationale, either. :)

LEGO wrote:

The rationale is pretty straightforward there's udp in the frame so it matches "udp". What you might want to do is filter with "udp and not icmp". On Sun, 20 Mar 2005 12:14:27 -0800, Bob Snyder <bob.snyder@cox.net> wrote:

Why are ICMP packets displayed when a display filter is used that should exclude them? For example, when running a traceroute, and with a display filter of "udp", in addition to the outbound UDP datagrams, the ICMP messages returned from each router are displayed as well. I know that the ICMP datagrams include the headers of the datagrams that are being reported on, but apparently their presence allows them to pass through the display filter. Is this behavior intentional? If so, what is the rationale? Bob Snyder _______________________________________________ Ethereal-users mailing list Ethereal-users@ethereal.com http://www.ethereal.com/mailman/listinfo/ethereal-users"]http://www.ethereal.com/mailman/listinfo/ethereal-users

ronnie sahlberg wrote:
> That is what is supposed to happen.
>
> Rationale:
> You asked for all packets containing the UDP protocol and you got them.
>
> An analyzer that filtered for UDP and did not show you these pacekts
> to you would be broken. Ethereal is not broken in this regard.

ICMP is not UDP. Why should Ethereal show something that's not selected?

LEGO wrote:
> The rationale is pretty straightforward there's udp in the frame so it
> matches "udp".
>
> What you might want to do is filter with "udp and not icmp".

ICMP is IP protocol #1 and UPD is #17. They are two completely
unrelated protocols.

At 04:06 PM 3/21/2005, James Knott wrote:
>ronnie sahlberg wrote:
>>That is what is supposed to happen.
>>Rationale:
>>You asked for all packets containing the UDP protocol and you got them.
>>An analyzer that filtered for UDP and did not show you these pacekts
>>to you would be broken. Ethereal is not broken in this regard.
>
>ICMP is not UDP. Why should Ethereal show something that's not selected?

Because there is a UDP message inside the ICMP message.

The best reason I can think of for it working this way is: Suppose you are
capturing a UDP conversation. If at some point a UDP message gets returned
via ICMP because of some error, you probably want to see that.

> ICMP is IP protocol #1 and UPD is #17. They are two completely
> unrelated protocols.

After its header ICMP message type 3 (ICMP Unreachable) contains the
IP header of the original IP packet (the one that could not reach) and
the first 8 bytes of its payload which can very well be UDP. That's
why you can find an UDP fragment inside an IP packet.

Expand the ICMP packet and you will see that encapsulated inside
the ICMP payload is an IP packet and ontop of the IP header is the UDP header.





On Mon, 21 Mar 2005 19:06:57 -0500, James Knott <james.knott@rogers.com> wrote:
> ronnie sahlberg wrote:
> > That is what is supposed to happen.
> >
> > Rationale:
> > You asked for all packets containing the UDP protocol and you got them.
> >
> > An analyzer that filtered for UDP and did not show you these pacekts
> > to you would be broken. Ethereal is not broken in this regard.
>
> ICMP is not UDP. Why should Ethereal show something that's not selected?
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>

On 07:10 PM 3/21/2005, James Knott wrote:
>ICMP is IP protocol #1 and UPD is #17. They are two completely unrelated protocols.


But when you're troubleshooting something, you *do* want to see these as well.

So strictly speaking, what you're saying is true. But I would prefer to see them.

hsb

I disagree with the notion that when filtering for UDP, if it didn't
display ICMP packets that come back, Ethereal would be broken. The
headers inside the ICMP message are effectively it's payload - it's
still an ICMP packet, not UDP (or whatever). The frame does not contain
UDP datagrams (or whatever other protocol caused the ICMP message). And
it's presumptuous of the program (dare I say the devs?) to presume that
you must surely want to see the ICMP messages when what your display
filter asks for is only the original message packets.

The argument that you can use "udp and not icmp" to only see the
original UDP seems backwards to me. You should be able to use "udp" to
see only the UDP, and "udp and icmp" when you want to see both. Surely
that is more intuitive.

That said, I think using the UDP (or whatever) dissector to decode the
header data included in the ICMP messages is brilliant :-)

Bob S.


ronnie sahlberg wrote:

>That is what is supposed to happen.
>
>Rationale:
>You asked for all packets containing the UDP protocol and you got them.
>
>An analyzer that filtered for UDP and did not show you these pacekts
>to you would be broken. Ethereal is not broken in this regard.
>
>
>
>
>On Sun, 20 Mar 2005 12:14:27 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
>
>
>>Why are ICMP packets displayed when a display filter is used that should
>>exclude them?
>>
>>For example, when running a traceroute, and with a display filter of
>>"udp", in addition to the outbound UDP datagrams, the ICMP messages
>>returned from each router are displayed as well. I know that the ICMP
>>datagrams include the headers of the datagrams that are being reported
>>on, but apparently their presence allows them to pass through the
>>display filter. Is this behavior intentional? If so, what is the rationale?
>>
>>Bob Snyder
>>
>>

On 11:25 PM 3/21/2005, Bob Snyder wrote:
>[snip]
>The argument that you can use "udp and not icmp" to only see the original UDP seems backwards to me. You should be able to use "udp" to see only the UDP, and "udp and icmp" when you want to see both. Surely that is more intuitive.
>
>That said, I think using the UDP (or whatever) dissector to decode the header data included in the ICMP messages is brilliant :-)


The next time you troubleshoot PMTU-D problem (YET AGAIN!!!) you'll thank Ethereal for putting it in there!

hsb

Your filter was "show me all packets containing the UDP protocol".

Did the filter the ICMP packet contain a header for the UDP protocol or not?


On Mon, 21 Mar 2005 20:25:22 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
> I disagree with the notion that when filtering for UDP, if it didn't
> display ICMP packets that come back, Ethereal would be broken. The
> headers inside the ICMP message are effectively it's payload - it's
> still an ICMP packet, not UDP (or whatever). The frame does not contain
> UDP datagrams (or whatever other protocol caused the ICMP message). And
> it's presumptuous of the program (dare I say the devs?) to presume that
> you must surely want to see the ICMP messages when what your display
> filter asks for is only the original message packets.
>
> The argument that you can use "udp and not icmp" to only see the
> original UDP seems backwards to me. You should be able to use "udp" to
> see only the UDP, and "udp and icmp" when you want to see both. Surely
> that is more intuitive.
>
> That said, I think using the UDP (or whatever) dissector to decode the
> header data included in the ICMP messages is brilliant :-)
>
> Bob S.
>
>
> ronnie sahlberg wrote:
>
> >That is what is supposed to happen.
> >
> >Rationale:
> >You asked for all packets containing the UDP protocol and you got them.
> >
> >An analyzer that filtered for UDP and did not show you these pacekts
> >to you would be broken. Ethereal is not broken in this regard.
> >
> >
> >
> >
> >On Sun, 20 Mar 2005 12:14:27 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
> >
> >
> >>Why are ICMP packets displayed when a display filter is used that should
> >>exclude them?
> >>
> >>For example, when running a traceroute, and with a display filter of
> >>"udp", in addition to the outbound UDP datagrams, the ICMP messages
> >>returned from each router are displayed as well. I know that the ICMP
> >>datagrams include the headers of the datagrams that are being reported
> >>on, but apparently their presence allows them to pass through the
> >>display filter. Is this behavior intentional? If so, what is the
> rationale?
> >>
> >>Bob Snyder
> >>
> >>
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>

On Mon, 21 Mar 2005 20:25:22 -0800, Bob Snyder <bob.snyder@cox.net> wrote:
> I disagree with the notion that when filtering for UDP, if it didn't
> display ICMP packets that come back, Ethereal would be broken. The
> headers inside the ICMP message are effectively it's payload - it's
> still an ICMP packet, not UDP (or whatever). The frame does not contain
> UDP datagrams (or whatever other protocol caused the ICMP message). And

But why would the filter (only) apply to the frame layer and not to
another layer?
Sure, UDP on top of IP is the most common variant, but why should it
be the only variant the filter matches?

> it's presumptuous of the program (dare I say the devs?) to presume that
> you must surely want to see the ICMP messages when what your display
> filter asks for is only the original message packets.

You didn't ask for 'udp directly on top of ip', but just for udp.

On Tue, Mar 22, 2005 at 02:53:35PM +0100, Olaf van der Spek wrote:
> You didn't ask for 'udp directly on top of ip', but just for udp.

Exactly. If you only want "udp directly on top of ip" then you have to
specify this. Otherwise, you wouldn't be seeing udp inside gre tunnels
either - and this is much more non-inuitive than the case here. The
non intuitive thing in this special case is, that it's not really udp
traffic, it's just a status message being sent back that contains part
of a problematic packet for informative purposes. So in this specific
case our semantics may be non-intuitive, as it isn't a "normal" udp
packet.

ciao
Joerg
--
Joerg Mayer <jmayer@loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

Bob Snyder a écrit :
> I disagree with the notion that when filtering for UDP, if it didn't
> display ICMP packets that come back, Ethereal would be broken. The
> headers inside the ICMP message are effectively it's payload - it's
> still an ICMP packet, not UDP (or whatever). The frame does not contain
> UDP datagrams (or whatever other protocol caused the ICMP message). And
> it's presumptuous of the program (dare I say the devs?) to presume that
> you must surely want to see the ICMP messages when what your display
> filter asks for is only the original message packets.
>
> The argument that you can use "udp and not icmp" to only see the
> original UDP seems backwards to me. You should be able to use "udp" to
> see only the UDP, and "udp and icmp" when you want to see both. Surely
> that is more intuitive.

frame.protocols is your friend. Its value represents all the protocols
in the frame. For example, in a SMB packet: eth:ip:tcp:nbss:smb

For you packet, it would probably be eth:ip:icmp:ip:udp:whatever, so you
can filter on this containing the string eth:ip:udp.

I agree that it's at first surprising to get icmp when filtering udp,
but ethereal works like this, and it's far more logical (i am thinking
of tunnelling ip over ppp over udp over ip over gtp over udp over ip,
the icmp error packet would eventually look like
eth:ip:icmp:ip:udp:gtp:ip:udp:ppp:ip:udp and you do want a reliable
filtering system to debug this)

--
Julien Leproust

On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
<julien.leproust@ercom.fr> wrote:
> Bob Snyder a écrit :
[snip]
> eth:ip:icmp:ip:udp:gtp:ip:udp:ppp:ip:udp and you do want a reliable
> filtering system to debug this)

Just a reminder:

ICMP messages carry only the first 64 bits (eight octets) of the
payload of the errored ip packet. i.e. just enough for the UDP header.

On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
<julien.leproust@ercom.fr> wrote:
> Bob Snyder a écrit :
[snip]
> eth:ip:icmp:ip:udp:gtp:ip:udp:ppp:ip:udp and you do want a reliable
> filtering system to debug this)

Just a reminder:

ICMP messages carry only the first 64 bits (eight octets) of the
payload of the errored ip packet. i.e. just enough for the UDP header.

LEGO a écrit :
> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
> <julien.leproust@ercom.fr> wrote:
> Just a reminder:
>
> ICMP messages carry only the first 64 bits (eight octets) of the
> payload of the errored ip packet. i.e. just enough for the UDP header.

Ok, I didn't know. Too bad, that would have been fun :)

--
Julien Leproust

On some routers and operating systems the amount of bytes returned in the ICMP payload is configurable.

For example on Sun Solaris
Ndd 'ip_icmp_return_data_bytes' is set to a default of 64 bytes (range 8-65520 bytes)

Cheers

Giles



-----Original Message-----
From: ethereal-users-bounces@ethereal.com [mailto:ethereal-users-bounces@ethereal.com] On Behalf Of julien.leproust@ercom.fr
Sent: Tuesday, March 22, 2005 2:56 PM
To: LEGO; Ethereal user support
Subject: Re: [Ethereal-users] Re: ICMP

LEGO a écrit :
> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
> <julien.leproust@ercom.fr> wrote:
> Just a reminder:
>
> ICMP messages carry only the first 64 bits (eight octets) of the
> payload of the errored ip packet. i.e. just enough for the UDP header.

Ok, I didn't know. Too bad, that would have been fun :)

--
Julien Leproust


_______________________________________________
Ethereal-users mailing list
Ethereal-users@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-users

As far as I know ICMP packets are required to contain
at least the first 8 bytes. But they can contain more...

Best regards
Michael

On Mar 22, 2005, at 15:55 Uhr, julien.leproust@ercom.fr wrote:

> LEGO a écrit :
>> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
>> <julien.leproust@ercom.fr> wrote:
>> Just a reminder:
>> ICMP messages carry only the first 64 bits (eight octets) of the
>> payload of the errored ip packet. i.e. just enough for the UDP header.
>
> Ok, I didn't know. Too bad, that would have been fun :)
>
> --
> Julien Leproust
>
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>

I took a look to rfc792 (ICMP) and fOr every message supposed to carry
the errored packet it says:

Internet Header + 64 bits of Data Datagram

The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.

I assume it's just the fisrt 8 bytes. Otherwise it would be a waste of
badwidth that at the time when it was written (1981) would had been
unacceptable. So far I've never seen more than that.


On Tue, 22 Mar 2005 16:10:33 +0100, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
> As far as I know ICMP packets are required to contain
> at least the first 8 bytes. But they can contain more...
>
> Best regards
> Michael
>
> On Mar 22, 2005, at 15:55 Uhr, julien.leproust@ercom.fr wrote:
>
> > LEGO a écrit :
> >> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
> >> <julien.leproust@ercom.fr> wrote:
> >> Just a reminder:
> >> ICMP messages carry only the first 64 bits (eight octets) of the
> >> payload of the errored ip packet. i.e. just enough for the UDP header.
> >
> > Ok, I didn't know. Too bad, that would have been fun :)
> >
> > --
> > Julien Leproust
> >
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@ethereal.com
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
>
>


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan

I took a look to rfc792 (ICMP) and fOr every message supposed to carry
the errored packet it says:

Internet Header + 64 bits of Data Datagram

The internet header plus the first 64 bits of the original
datagram's data. This data is used by the host to match the
message to the appropriate process. If a higher level protocol
uses port numbers, they are assumed to be in the first 64 data
bits of the original datagram's data.

I assume it's just the fisrt 8 bytes. Otherwise it would be a waste of
badwidth that at the time when it was written (1981) would had been
unacceptable. So far I've never seen more than that.


On Tue, 22 Mar 2005 16:10:33 +0100, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
> As far as I know ICMP packets are required to contain
> at least the first 8 bytes. But they can contain more...
>
> Best regards
> Michael
>
> On Mar 22, 2005, at 15:55 Uhr, julien.leproust@ercom.fr wrote:
>
> > LEGO a écrit :
> >> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
> >> <julien.leproust@ercom.fr> wrote:
> >> Just a reminder:
> >> ICMP messages carry only the first 64 bits (eight octets) of the
> >> payload of the errored ip packet. i.e. just enough for the UDP header.
> >
> > Ok, I didn't know. Too bad, that would have been fun :)
> >
> > --
> > Julien Leproust
> >
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@ethereal.com
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
>
>


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan

I have seem more than the first 8 bytes in ICMP packets (protocol
unreachable)
in response to SCTP packets....

Best regards
Michael

On Mar 22, 2005, at 16:20 Uhr, LEGO wrote:

> I took a look to rfc792 (ICMP) and fOr every message supposed to carry
> the errored packet it says:
>
> Internet Header + 64 bits of Data Datagram
>
> The internet header plus the first 64 bits of the original
> datagram's data. This data is used by the host to match the
> message to the appropriate process. If a higher level protocol
> uses port numbers, they are assumed to be in the first 64 data
> bits of the original datagram's data.
>
> I assume it's just the fisrt 8 bytes. Otherwise it would be a waste of
> badwidth that at the time when it was written (1981) would had been
> unacceptable. So far I've never seen more than that.
>
>
> On Tue, 22 Mar 2005 16:10:33 +0100, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>> As far as I know ICMP packets are required to contain
>> at least the first 8 bytes. But they can contain more...
>>
>> Best regards
>> Michael
>>
>> On Mar 22, 2005, at 15:55 Uhr, julien.leproust@ercom.fr wrote:
>>
>>> LEGO a écrit :
>>>> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
>>>> <julien.leproust@ercom.fr> wrote:
>>>> Just a reminder:
>>>> ICMP messages carry only the first 64 bits (eight octets) of the
>>>> payload of the errored ip packet. i.e. just enough for the UDP
>>>> header.
>>>
>>> Ok, I didn't know. Too bad, that would have been fun :)
>>>
>>> --
>>> Julien Leproust
>>>
>>>
>>> _______________________________________________
>>> Ethereal-users mailing list
>>> Ethereal-users@ethereal.com
>>> http://www.ethereal.com/mailman/listinfo/ethereal-users
>>>
>>
>>
>
>
> --
> This information is top security. When you have read it, destroy
> yourself.
> -- Marshall McLuhan
>

You are right, I've just took a look to a capture containig sctp over
icmp and I've seen that you are right, the whole sctp pdu was in
there.


On Tue, 22 Mar 2005 17:57:58 +0100, Michael Tuexen
<Michael.Tuexen@lurchi.franken.de> wrote:
> I have seem more than the first 8 bytes in ICMP packets (protocol
> unreachable)
> in response to SCTP packets....
>
> Best regards
> Michael
>
> On Mar 22, 2005, at 16:20 Uhr, LEGO wrote:
>
> > I took a look to rfc792 (ICMP) and fOr every message supposed to carry
> > the errored packet it says:
> >
> > Internet Header + 64 bits of Data Datagram
> >
> > The internet header plus the first 64 bits of the original
> > datagram's data. This data is used by the host to match the
> > message to the appropriate process. If a higher level protocol
> > uses port numbers, they are assumed to be in the first 64 data
> > bits of the original datagram's data.
> >
> > I assume it's just the fisrt 8 bytes. Otherwise it would be a waste of
> > badwidth that at the time when it was written (1981) would had been
> > unacceptable. So far I've never seen more than that.
> >
> >
> > On Tue, 22 Mar 2005 16:10:33 +0100, Michael Tuexen
> > <Michael.Tuexen@lurchi.franken.de> wrote:
> >> As far as I know ICMP packets are required to contain
> >> at least the first 8 bytes. But they can contain more...
> >>
> >> Best regards
> >> Michael
> >>
> >> On Mar 22, 2005, at 15:55 Uhr, julien.leproust@ercom.fr wrote:
> >>
> >>> LEGO a écrit :
> >>>> On Tue, 22 Mar 2005 15:33:16 +0100, julien.leproust@ercom.fr
> >>>> <julien.leproust@ercom.fr> wrote:
> >>>> Just a reminder:
> >>>> ICMP messages carry only the first 64 bits (eight octets) of the
> >>>> payload of the errored ip packet. i.e. just enough for the UDP
> >>>> header.
> >>>
> >>> Ok, I didn't know. Too bad, that would have been fun :)
> >>>
> >>> --
> >>> Julien Leproust
> >>>
> >>>
> >>> _______________________________________________
> >>> Ethereal-users mailing list
> >>> Ethereal-users@ethereal.com
> >>> http://www.ethereal.com/mailman/listinfo/ethereal-users
> >>>
> >>
> >>
> >
> >
> > --
> > This information is top security. When you have read it, destroy
> > yourself.
> > -- Marshall McLuhan
> >
>
>


--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan