Workarround: disable icmp, that way the "second" IP header disappears.
filter for icmp elements using "frame[offset:length] ==
bytes_in_packet" instead of "icmp.xxx == XXX".
I'm on having -e to use an {N} operator to choose a given instance of
a field. E.g. ip.src{0} or ip.src{0} depends... (I'm not sure whether
it should use a 0-based or a 1-based index).
For the display filters that and more are coming... The "/" ("over" or
better "after") operator is on the works too... so that ip.src/icmp
would be the one ip.src after icmp (the "nested" one).
You just make me notice (with excellent timing) that we need also an
"under" or better "before" operator ( "*" ? ) so that "ip.src*icmp"
refers to the ip.src before icmp (that is you could filter
"ip.src/icmp.unreachable == router_ip" and use "ip.src{0?}" for -e).
to filter the encapsulated packet and the {N} operator will be there
to choose a given instance of the header (the first): either ip.src{0}
or ip.src{1}... to be discussed ).
On Fri, Aug 22, 2008 at 12:02 AM, Armen Babikyan <armenb@xxxxxxxxxx> wrote:
> Hello,
>
> I'm having a problem with using "-e" flag with tshark. While "tshark -e
> ip.src" works as expected most of the time, it behaves unexpectedly when
> dealing with ICMP Destination or Host Unreachable packets.
>
> ICMP Destination and Host Unreachable packets are unusual in that they
> contain the IP header of the packet that caused the error. Wireshark
> seems to name both IP src address fields from the error packet as well
> as the nested packet that caused the error the same: ip.src. This makes
> Wireshark's filter engine include packets if they match *either* of the
> ip.src fields, which can be a little confusing, but the problem can be
> worked around for my purposes.
>
> The real problem I'm having is that tshark -e seems to use a nested
> packet's ip.src field as the data it returns, which is unexpected; I
> really want the src address of the router that generated the ICMP Host
> Unreachable message, not the src address of the machine that sent the
> packet that caused the error.
>
> Is there a more explicit way (than the string "ip.src") to specify to
> the Wireshark packet dissection engine that I really want the top level
> ip.src value? Furthermore, is there an explicit way to specify that I
> want the nested ip.src value?
>
> These problems carry to other ip headers, not just the src address field.
>
> Any and all information is appreciated. Thanks!
>
> Armen
>
> --
> Armen Babikyan
> MIT Lincoln Laboratory
> armenb@xxxxxxxxxx . 781-981-1796
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
