On Mon, Jun 28, 2004 at 02:59:11PM -0700, Dinesh G Dutt wrote:
> In certain protocols (such as iSNS), the client registers a port on which it
> can receive notifications from a server at later times. The server can connect
> using different ports when providing different notifications. Typically, the
> server sets up a TCP connection to the registered port, provides the
> notification and shuts down the connection. At a later time, it may reconnect
> to the same registered port from a different source port to provide a different
> notification.
>
> This causes a problem with the way dissectors that hang off conversations are
> setup. Consider the case where a dissector is associated with a conversation
> with the option NO_PORT2. When the conversation is dissected the first time,
> find_conversation() causes the source port (port2) to be set as
> well. Subsequent connections originating from a different source port will now
> fail to be dissected.
>
> To fix this problem, I was thinking of providing an option during
> conversation_new() called NO_PORT2_FORCE.
Note that we currently don't do that for UDP.
Perhaps the issue of whether we're declaring a future connection (i.e.,
we know both endpoints in their entirety) or a service offered to a
particular host (i.e., we don't know the other side's port number)
should be decoupled from the protocol, and all the calls that currently
establish wildcarded UDP connections should add that flag.
> 1) Is this the right way to fix this problem ?
If the distinction is between a service being offered and a future
connection being described, that might be, although we might also want
to see where we use TCP conversations with a wildcarded second port and
look at why treating that as a future connection is what's called for
there.
> 2) Should a NO_ADDR2_FORCE option be provided as well ?
Only if we can think of a case where, in a protocol, you'd know the
local endpoint of future connections, and the remote port number for
those connections, but might have more than one remote machine
connecting from that port to that machine and port.
This also raises the question of whether you want to, instead, have a
"prototype" conversation, and, when we get a match, "clone" that
conversation, creating a new conversation with completely non-wildcarded
endpoints, rather than having a conversation whose second port remains
wildcarded.
