On Sat, Dec 28, 2002 at 09:46:11PM +0100, J.Smith wrote:
> >
> > Would there be any loss in generality of filters if there wasn't an
> implicit
> > 'and protocol' term?
> >
>
> Well as far as I know, the filter expression parsing is in exactly the same
> style as tcpdump uses.
The libpcap/tcpdump syntax doesn't directly match the Ethereal display
filter syntax, so it can't be in *exactly* the same style - but it looks
as if, in the closest approximation to that style, you are correct.
To test the TCP port number, you can either do
tcp port 10
or you can do
tcp[0:2] = 10 or tcp[2:2] = 10
There's no "=" or "==" in the first, so there's nothing to replace with
"!="; you can only do
not tcp port 10
which generates code that matches any packet that doesn't have TCP port
number 10, whether that's because it has TCP source and destination
ports both not equal to 10 or because it has no TCP source or
destination port at all.
So
not tcp port 10
is like
!(tcp.port == 10)
and there is no equivalent to
tcp.port != 10
using a "tcp port" expression.
In the case of the explicit comparisons, the negation would be
tcp[0:2] != 10 and tcp[2:2] != 10
but *that* generates code that matches only packets that have TCP source
and destination ports both not equal to 10 - patches that have no TCP
source or destination ports aren't matched by that filter.
> Maybe it would help if there would be a section in the online help or/and
> the manual that explicitly stated this behaviour, and warns users that such
> an expression might not be what the user intended ?
Yes, that might be a good idea - just have the documentation explain
that an explicit comparison operator on a field fails, rather than
succeeding, if the field is absent from the packet.