Ethereal-dev: Re: [ethereal-dev] conversation wildcard entry

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Thu, 28 Sep 2000 10:44:43 -0700
On Thu, Sep 28, 2000 at 10:49:29AM -0500, Jeff Foster wrote:
> conversation_new( src_addr, NULL, PT_TCP || NO_DST_ADDR || NO_DST_PORT,
> src_port, NULL, NULL);

Presumably you mean "PT_TCP | NO_DST_ADDR | NO_DST_PORT" here - i.e,
bitwise OR, not Boolean short-circuit OR.

I might be inclined to pass the flags as a separate argument from the
port-number type, however.  You might store the flags and port type in
one field internally to the conversation code, but still pass them as
separate arguments.

Also, NULL isn't necessarily a valid port number - it can be defined as,
say, "(void *)0", rather than as 0 (if I remember correctly, the ANSI C
standard says it can be defined as either of those), which can cause
compiler warnings, at minimum, if it's to be converted to an integral
value shorter than a pointer; I'd just use 0, not NULL.

> Change hash code to consider the new flags...

Presumably you meant "NO_DST_ADDR" or "NO_DST_PORT", not "ANY_DST_ADDR"
and "ANY_DST_PORT", there - or meant "ANY_DST_ADDR" and "ANY_DST_PORT"
in "conversation.h" and "conversation_equal()".

Note that, in some cases, the lack of a destination address and/or port
may be temporary; consider, for example, TFTP, where the first packet of
a TFTP conversation is from <client address, client port> and to <server
address, TFTP port>, the reply is from <server address, some other
server port> to <client address, client port>, and all subsequent
traffic is between <client address, client port> and <server address,
other server port>.