Mailing List Archive

On Tue, 22 Mar 2005 15:47:14 +0100, LEGO <luis.ontanon@gmail.com> wrote:
> 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.

ICMP mesages carry at least 64 bits of the header for the protocol above IP.
Many implementations do provide a lot more than 64 bits, some fills
the ICMP header up to the entire MTU.

The standard only requires the first 64 bits and some implementations
only provide this. Many supply much more than 64 bits.

Olaf van der Spek wrote:
> 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.

Is there a way of saying that a filter is only to match on headers and
not payload, and vice versa?

--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who

Andrew Hood wrote:

> Is there a way of saying that a filter is only to match on headers and
> not payload, and vice versa?

Filters work on protocol trees; what, in a protocol tree, is the
distinction between a "header" and "payload"?

julien.leproust@ercom.fr wrote:

> 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)


This is the first post on the subject that helped me make sense out of
what your are all saying. Another light bulb was the fact that since any
higher level protocol sits in the payload of the layer below it, it's
normal to look in a particular layer's payload for more protocols. So in
the ICMP case, (even thought it's a special case) the offending packet's
headers being a sort of payload, I can see where a case can be made for
it being passed through the filter.

Also since protocols can be layered to almost arbitrary depth, I guess
the filter has to keep looking all the way to the top of the stack.

Thanks for the tip on frame.protocols. That really helps sort out the
layers!

Bob S.

-------------------
The Ethereal project is being continued at a new site. Please go to
http://www.wireshark.org and subscribe to wireshark-users@wireshark.org.
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-users
-------------------

A lot of ICMP implementations return more IP-Header plus 8 bytes. But
the only thing you know is that they return at least IP header + 8
bytes.

Ethereal uses what it gets...

Best regards
Michael

On Oct 3, 2006, at 10:50 AM, Pradeep.Raju@flextronicssoftware.com wrote:

> -------------------
> The Ethereal project is being continued at a new site. Please go to
> http://www.wireshark.org and subscribe to wireshark-
> users@wireshark.org.
> Don't forget to unsubscribe from this list at
> http://www.ethereal.com/mailman/listinfo/ethereal-users
> -------------------
>
> hi,
> i need to know what was the RFC or protocol specification that
> ethereal
> follows for ICMP protocol. could u please help me out.
> i just had a traffic file which decoded by ethereal shows ICMP error
> message returning a payload which is against RFC 792
> The payload returned by ICMP error message (destination host
> unreachable)
> should be IP header+ 8 bytes but ethereal decodes (IP header + more
> than 8
> bytes)
>
>
>
>
>
>
>
>
> regards
> pradeep raju
>
>
> "DISCLAIMER: This message is proprietary to Flextronics Software
> Systems (FSS) and is intended solely for the use of
> the individual to whom it is addressed. It may contain privileged
> or confidential information and should not be
> circulated or used for any purpose other than for what it is
> intended. If you have received this message in error,
> please notify the originator immediately. If you are not the
> intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the
> contents of this message. FSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted
> by this email including damage from virus."
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>

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