Guy Harris wrote:
On Tue, Dec 31, 2002 at 07:52:31AM -0700, John McDermott wrote:
OK. I have to agree here. I think 'tcp.port==80' should mean "tcp
packets with source or destination ports with a value of 80' (as it
does), but by the "filters shouldn't do things I don't ask for" rule,
"tcp.port != 80" should not imply tcp packets.
What you asked for was packets whose TCP port had a value other than 80.
OK. And 'undefined' is not 80.
Non-TCP packets have no TCP port, so they obviously don't have a TCP
port with a value other than 80.
Yes and no. The value is 'undefined'. Some programming languages have
an 'undefined' value. I think we need that here. For a UDP or ICMP
packet (just to name two) tcp.port is undefined. It is not defined
because there is no TCP header.
I'm sorry to disagree
with Guy, but if a packet does not have a TCP port, its tcp.port value is
not 80 (it is undefined) and therefore it should match the expression.
So for which comparison operators should an undefined value match and
for which comparison operators should an undefined value not match?
(There are more comparison operators than "==" and "!=".)
I see your point, but I don't propose that 'undefined' match anything.
In fact, I propose that it match nothing. This way <, >, etc. evaluate
to false when compared with 'undefined'. I suppose if we had !>= that
would succeed, but all I can think of succeeding is !=, because, indeed a
real value will "not equal" 'undefined'.
[One could make a case for tcp.port == undef being allowed in those cases
where 1) there is no TCP header or 2) there is an alleged TCP header but
the port value is undefined. This does seem a bit more complex to deal
with, though and may not be useful.]
--john
--john
--
John McDermott
Writer, Educator, Consultant
jjm@xxxxxxxxxx http://www.jkintl.com
V +1 505/377-6293 F +1 505/377-6313
