Guy Harris said:
> Perhaps we need, for example, some "pseudo-fields" that correspond to
> source and destination addresses as displayed in the columns in the packet
> list, so that you could do "src == foo" (which would match packets with a
> source address corresponding to the host name "foo", where that could be
> *any* type of host name, i.e. one corresponding to a MAC address or an
> IPv4 address or an IPv6 address or...), "dst == 127.0.0.1" (which would
> match only IPv4 packets; we'd need a syntax for addresses that lets us
> infer the address type or types from the address string), and "addr ==
> fe80::1" (which would match anything with a source *or* destination IPv6
> address of fe80::1).
Or perhaps the syntax should be
src foo
dst 127.0.0.1
host fe80::1
with qualifiers such as "ether"/"fddi"/"wlan"/"ip"/"ip6" to match
particular types of addresses.
We could then also support matching on the port columns (not displayed by
default, but they could be added), e.g.
port 53
tcp port 80
and the like.
The resemblance of this syntax to libpcap syntax is *NOT* a coincidence.
If we promote that as the syntax for doing address and port matching - a
common sort of matching, especially address matching - users would be used
to it and would not be surprised by the filter syntax not working on
captures. (There will be lots of display filters that don't work as
capture filters, but it wouldn't be for syntactic reasons - it'd be
because capture filters are less capable than display filters.)
This syntax also has the advantage that there's no "==" operator, so
people wouldn't think that "a != b" is the negation of "a == b" - they'd
do "not host foo" as the negation of "host foo".
