[Guy Harris <guy@xxxxxxxxxx>]

> Next issue: conversation support for SMB.  The dcerpc dissector needs
> to keep track of some things per conversation.  It's doing this just
> fine for TCP and UDP.  The problem is that the conversation stuff
> doesn't support SMB 'conversations'.

The DCE conversation hash table just uses the conversation pointer as a
collection of bits; it could be declared a "void *" in the
"dcerpc_conv_key" structure, and set to the appropriate conversation_t
for DCE RPC over TCP or UDP, and the named pipe dissector could maintain
its own notion of conversations, indexed by TCP conversation *and* named
pipe name, and somehow supply that to the DCE RPC dissector.

(There are other places where the current notion of conversations could
perhaps be usefully generalized, e.g. X.25 connections are arguably
conversations, as are ATM circuits.)

Using the file/pipe number would probably work as a short-term solution,
as long as you don't run DCE RPC over both port 138 and port 139 SMB
(or, if you do, they get different file/pipe numbers).