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.

Date: Tue, 22 Mar 2005 15:33:16 +0100
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