Guy Harris <guy@xxxxxxxxxx> writes:
> > 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).
>
Hmmm, I think it's actually worse than that. If you make two
separate, simultaneous connections from the same machine to 139 on a
server, NT, at least, will reuse the file ids, I think. What might
work for now is to combine the TCP ports with the file id and use that
as the 'SMB port'. I think that would handle the port 139 and 445
cases correctly.
It's kinda messy though. It means that the SMB dissector will have to
check which protocol is its parent, and only do this stuff if it's
TCP. SMB can also be done over Nbf, and Netbios over ipx, and it'd be
nice if there was some way a dissector could just say 'split the
conversations identified by my parent up into these subconversations'
and make that available to its subdissectors. Does that make sense?
Anyway, I'm going to try the TCP port plus file id for now. Would
love to hear from SMB gurus if that sounds like a reasonable approx.
Todd