["Alan Harrison" <alanharrison@xxxxxxxx>]

Thanks for the reply,

Just to clarify what I was asking: I have been capturing SMB packets on my
system and noticed that if I missed the start of a file open I was not able
to identify the share, file or process which the TIP,PID etc fields related
to on the client or server.
What I was hoping to do was to associate these values  with processes,
shares, files etc from the NT client or Server point of view. So if I catch
a packet and the TID is say AB23, I can run a utility on the server or
client side which will say TID AB23 is share \\server\files (or drive p:
say).
This information will be held on the client and server somewhere so that it
can respond to the received packets. I presume this is buried deep in the
low level networking code and there is no way to access it. I've looked
through the MSDN stuff and I can't find any reference to it there.I've also
looked at the utilities on www.sysinternals.com which are pretty good on
filehandles, tcp ports etc but nothing to view the SMB TID,PID stuff.
----
alanharrison@xxxxxxxx
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxxxxx>
To: "Alan Harrison" <alanharrison@xxxxxxxx>
Sent: Thursday, May 18, 2000 5:51 AM
Subject: Re: [ethereal-users] SMB Decodes


> On Tue, May 16, 2000 at 06:43:05PM +0100, Alan Harrison wrote:
> > While this is not strictly a ethereal question I would appreciate it if
> > anyone could enlighten me. When I'm viewing the SMB decode packets there
are
> > values for TID,PID,UID and MID. I think these are handles to the share,
> > process, user (mid?).
>
> One of the old CIFS Internet Drafts, at
>
> ftp://ftp.microsoft.com/developr/drg/CIFS/draft-leach-cifs-v1-spec-01.txt
>
> says:
>
> 3.2.4      Tid Field
>
> Tid represents an instance of an authenticated connection to a
> server resource.  The server returns Tid to the client when the
> client successfully connects to a resource, and the client uses
> Tid in subsequent requests referring to the resource.
>
> In most SMB requests, Tid must contain a valid value.
> Exceptions are those used prior to getting a Tid established,
> including SMB_COM_NEGOTIATE, SMB_COM_TREE_CONNECT_ANDX,
> SMB_COM_ECHO, and SMB_COM_SESSION_SETUP_ANDX.  0xFFFF should be
> used for Tid for these situations.  The server is always
> responsible for enforcing use of a valid Tid where appropriate.
>
> On SMB_COM_TREE_DISCONNECT over a given transport connection,
> with a given Tid, the server will close any files opened with
> that Tid over that connection.
>
> 3.2.5      Pid Field
>
> The Pid field identifies to the server the "process" that opened
> a file (see SMB_COM_FLUSH) or that owns a byte range lock (see
> SMB_COM_LOCKING_ANDX).  This "process" may or may not correspond
> to the client operating system's notion of process.
>
> The client chooses the value of the Pid field; servers MUST set
> the Pid field of responses to the same value as in the
> corresponding request.  The Pid is relative to a transport
> connection -- the same Pid in requests sent over different
> connections will be considered to represent a different process.
>
> 3.2.6      Uid Field
>
> Uid is a user ID assigned by the server after a user
> authenticates to it, and that it will associate with that user
> until the client requests the association be broken.  After
> authentication to the server, the client SHOULD make sure that
> the Uid is not used for a different user that the one that
> authenticated.  (It is permitted that a single user have more
> than one Uid.) Requests that do authorization, such as open
> requests, will perform access checks using the identity
> associated with the Uid.
>
> 3.2.7      Mid Field
>
> The multiplex ID (Mid) is used to allow multiplexing the single
> client and server connection among the client's multiple
> processes, threads, and requests per thread.  Clients may have
> many outstanding requests at one time.  Servers MAY respond to
> requests in any order, but a response message MUST always
> contain the same Mid value as the corresponding request message.
> The client MUST NOT have multiple outstanding requests to a
> server with the same Mid.
>
> The Tid field is, effectively, a share handle.
>
> The Pid field *might* be a process, but, as they note:
>
> This "process" may or may not correspond to the client operating
> system's notion of process.
>
> I no longer remember whether (from when I worked on the SMB server in
> NetApp filers) it at all depended on the process on the client that
> issued the file system call that caused the request to be issued; given
> that NT, at least, can, as I remember, do write-behind in its SMB-client
> IFS (i.e., when a process does a "WriteFile()" call to write to a file
> on a file server, that won't necessarily cause an SMB write operation to
> be sent immediately to the file server - the write may be deferred, and
> may well push to the server a page that's been written to by *multiple*
> processes), I could imagine that it doesn't identify a particular
> process.
>
> The Uid field identifies the user, although it's not necessarily the
> OS's native user ID value.
>
> The Mid field is a transaction ID; a client assigns to SMB requests Mid
> values, so that when it gets back a reply, it can identify the request
> to which the reply in question is a reply by matching the Mid values of
> requests and replies.
>
> > What I would like to be able to do is to relate these
> > values to whatever a particular transaction on the client or server.
Does
> > anyone know of a utility or method by which this can be found.
>
> "Transaction" in what sense?  There isn't necessarily a correspondence
> between SMB requests and file system API calls made by programs on the
> client, as per the above, and as per the fact that the client OS can, at
> least if oplocks are being used, cache the results of an SMB read
> operation and supply the cached data in response to another read from an
> already-read version of the same file.
>
>