Ulf Lamping wrote:
Please remember that there are a lot of people out there which uses
Ethereal and don't know (a lot about) RegEx.
And it's also not obvious at first sight that the display filter string
*is* a RegEx.
It's still not obvious to me that they're the same thing (other than the
"matches" operator supporting regular expressions. The unusual thing
about comparison operators in display filters is that they're more like
predicate calculus statements than propositional calculus statements, so
they don't behave quite the same way when you negate the proposition -
if you treat equality statements as propositions, the negation of the
proposition "a = b" is "a != b", but if you treat them as predicates, so
that "a = b" really means "for all instances of 'a' in the protocol
tree, {value of a} = b", then its negation is "there exists an instance
of 'a' in the protocol tree for which {value of a} != b", not "for all
instances of 'a' in the protocol tree, {value of a} != b".
Hmmm, it's not about RegEx here, but how to handle the combined fields
like ip.addr, tcp.port and alike.
Currently we simply substitute "ip.addr" by "(ip.srcaddr ||
ip.destaddr)", which is ok for the == operator, but not really for the
!= operator.
Well, not exactly.
"ip.addr" is implemented by the IP dissector putting a hidden "ip.addr"
field into the protocol tree, with a given value, if an "ip.src" or
"ip.dst" value is put into the protocol tree with the value in question.
This means that there's more than one instance of "ip.addr" in the
protocol tree, which means that "for all instances of 'ip.addr', {its
value} != x" and "there exists an instance of 'ip.addr' for which {its
value} != x" aren't the same.
Note that, if you have tunneling with two IPv4 layers, you can have the
same problem with "ip.src" or "ip.dst", as you'll have more than one
instance of "ip.src" and "ip.dst". For example, if you have traffic
between 192.9.200.1 and 192.9.200.2, with traffic between 192.9.200.3
and 192.9.200.4 tunneled inside it, searching for "ip.src !=
192.9.200.1" will match a packet from 192.9.200.1 to 192.9.200.2 if it
happens to have a packet from 192.9.200.3 to 192.9.200.4 tunneled inside it.
