Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke
> I'm glad to see someone getting this working, but wouldn't it be
> cleaner to have the SMB layer add this to the conversation info for
> the packet? I.e., add a port_type PT_SMB, and have the FID be either
> src or dest port (both?), or something along those lines.
Unfortunately, you can't replace the TCP port number with the FID; the
same FID can be used in more than one connection from client X to SMB
server Y.
(Heck, the same FID could be used more than once in the *SAME*
connection, as long as the two uses are for different trees.
SNIA CIFS spec says, in 3.2.5 "Pid Field" (yes, "Pid", not "Fid"):
Clients inform servers of the creation of a new process by
simply introducing a new Pid value into the dialogue for new
processes. The client operating system must ensure that the
appropriate close and cleanup SMBs will be sent when the last
process referencing a file closes it. From the server's point
of view, there is no concept of Fids "belonging to" processes.
A Fid returned by the server to one process may be used by any
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
other process using the same transport connection and Tid.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
which suggests that file IDs are unique only within a given transport
connection and Tid, not globally unique.)
There is no provision in the conversation code for more than the source
and destination port numbers being used, so, in order to use the FID in
conversation matching, you'd have to stop using the TCP port numbers -
but you can have more than one TCP connection between two hosts being
used for SMB, so that won't work.
(You could, I guess, replace the server port number, but that strikes me
as being at least as greasy a hack as the current code - frankly, it
strikes me as even uglier than what we're doing now; what we're
currently doing really doesn't bother me all that much, as the
underlying DCE RPC implementations, at some layer, *are* treating
different transports differently, I suspect.)
