Ethereal-users: RE: [Ethereal-users] Filtering on nested IP headers in ICMP packe ts
|-----Original Message-----
|From: nnposter [at] users.sourceforge.net
|
|Display filter elements related to IP header, such as "ip.src" and
|"ip.dst", seem to have unwanted effect when applied to ICMP Destination
|Unreachable packets. In particular, filter "ip.src==A.B.C.D"
|matches not
|only if A.B.C.D is the source IP address of the ICMP packet
|but also if it
|is the source IP address of the triggering encapsulated packet.
|
|Example:
|
| 1.1.1.1 -> 2.2.2.2 UDP DSTPORT=1234
| 2.2.2.2 -> 1.1.1.1 ICMP ITYPE=3, ICODE=3, DATA=(original packet)
|
|The ICMP packet above will match against "ip.src==1.1.1.1"
|or even "ip.src!=2.2.2.2".
Here's a nice gotcha of the display filters in Ethereal. If you read the
display filter "ip.src != 2.2.2.2" then Ethereal will understand this as
"The packet has a field named 'ip.src' whose value is different from
'2.2.2.2'". This is because every header field in a display filter
expression has an implicit "exists" test.
Consider reading the Ethereal display filter reference (it contains much
more information on how to read and write display filter expressions that do
what you want them to do).
If you want to test for packets not havilg '2.2.2.2' as source IP address,
you then have to write:
"! (ip.src == 2.2.2.2)".
|
|There is no obvious trick how to differentiate between the outside
|and inside IP headers (other than using offsets). Is this a bug or a
|desired behavior?
This is an implementation issue. Eventually I'd like to add protocol
hierarchy state to Ethereal, but this still requires study effort (consider
encapsulation, fragmentation and aggregation as options).
You can always use the knowledge *you* have on the capture to write a more
suitable display filter, for example: "icmp and ip.src == 1.2.3.4 and ip.src
== 2.2.2.2".
Regards,
Olivier
