Wireshark-bugs: [Wireshark-bugs] [Bug 11860] Display filter operator != not working as exepected
Comment # 2
on bug 11860
from Guy Harris
(In reply to hvgeekwtrvl from comment #0)
> When filtering captured packets created the following _expression_: ip.addr !=
> 192.168.1.52
>
> Expected results: All packets with a source or destination IPv4 address of
> 192.168.1.52 will NOT be displayed.
You should adjust your expectations here. :-)
A filter _expression_ "{field} {operator} {value}", such as "ip.addr !=
192.168.1.52", matches packets where the _expression_
There exists, in the packet, an instance of the field named {field} for
which the _expression_ {V} {operator} {value} is true for the value {V} of that
field
is true.
I.e, "ip.addr != 192.168.1.52" does not mean something as simple as "the
ip.addr field is not equal to 192.168.1.52", it means "there is *at least one*
instance of the ip.addr field that is not equal to 192.168.1.52".
This means that, for example, a packet from 192.168.1.52 to 192.168.1.73
*matches*, as the *destination* address is not equal to 192.168.1.52 - it's
equal to 192.168.1.73.
> Actual Results: All packets that contained the IPv4 address WERE displayed
> as if the _expression_ were ip.addr == 192.168.1.52
That's because all the packets in your capture that are to an address other
than 192.168.1.52 are from 192.168.1.52 and all the packets that are from an
address other than 192.168.1.52 are to 192.168.1.52.
> Workaround: using the following display filter works as expected: !(ip.addr
> == 192.168.1.52)
The negation of "there exists at least one {X} for which {Y} is true" is "for
all {X}, {Y} is not true". That means that "!(ip.addr == 192.168.1.52)", which
is the negation of "there exists, in the packet, an instance of ip.addr for
which its value is equal to 192.168.1.52". That negation means "there is, in
the packet, no instance of ip.addr for which is value is equal to
192.168.1.52", and therefore "!(ip.addr == 192.168.1.52)" matches packets that
are neither to nor from 192.168.1.52.
Yes, it may be a bit surprising, but that's the way predicate logic:
https://en.wikipedia.org/wiki/Predicate_logic
can go. Remember, there can be *more than one instance* of a field in a
packet, so the relational operators don't necessarily mean what you might think
they mean.
(Perhaps what's needed here is support for libpcap-style filter expressions, so
that you could say "host 192.168.1.52" to match packets that are to or from
192.168.1.52, and "not host 192.168.1.52" to match packets that are neither to
nor from 192.168.1.52".)
You are receiving this mail because:
- You are watching all bug changes.
