Comment # 3
on bug 10379
from Guy Harris
(In reply to Jerome from comment #0)
> The .src and .dst flags such as in ip.src and ip.dst are ignored in the
> display filter.
They're not flags, they're part of the field name - there isn't a field named
"ip" that takes flags ".src", ".dst", and ".addr", there are fields named
"ip.src", "ip.dst", and "ip.addr".
"ip.src" is the IP source address, "ip.dst" is the IP destination address, and
an IPv4 packet header's dissection contains *two* hidden "ip.addr" fields, one
with the value of the IP source address (i.e., the same value as the
dissection's "ip.src" field) and one with the value of the IP destination
address (i.e., the same value as the dissection's "ip.dst" field).
So a filter "ip.src == 1.2.3.4" should match any packet with an IPv4 header
with a source address of 1.2.3.4, a filter "ip.dst == 1.2.3.4" should match any
packet with an IPv4 header with a destination address of 1.2.3.4, and a filter
"ip.addr == 1.2.3.4" should match any packet with an IPv4 header with a source
or destination address of 1.2.3.4.
> Both appear to be treated the same as ip.addr.
Note that, just as a packet can have more than one "ip.addr" field, it could
have more than one "ip.src" or "ip.dst" field, if the packet contains more than
one IPv4 header.
That can happen, for example, if there's some form of tunneling being done.
It can *also* happen for ICMP packets, as some ICMP error packets can contain
part of the original IP packet that caused the error, and Wireshark dissects
the original IP packet as well as the IP and ICMP header for the ICMP packet.
This means that if, for example, a UDP packet is sent from 1.2.3.4, port 600,
to 4.3.2.1, port 601, and there's nothing on the machine at 4.3.2.1 listening
to UDP port 601, and an ICMP Port Unreachable error packet is returned, the
Port Unreachable packet will have "ip.src" fields with a value of 4.3.2.1 (as
the host at 4.3.2.1 sent the ICMP packet) *AND* with a value of 1.2.3.4 (as the
packet with the problem, a copy of which is included in the ICMP packet, was
sent from 1.2.3.4).
Make sure this isn't happening with an ICMP error packet, for example.
You are receiving this mail because:
- You are watching all bug changes.