Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-users: Re: [Ethereal-users] Re: ICMP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Bob Snyder <bob.snyder@xxxxxxx>
Date: Tue, 22 Mar 2005 20:15:43 -0800
julien.leproust@xxxxxxxx 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.