On Wed, Feb 19, 2003 at 03:34:32PM -0500, Devin Heitmueller wrote:
> That's pretty weird. The UserID field starts as 0 for the first few
> frames, and when the SMBSessionSetupAndX request is sent (contain zero
> as the UserID), the Win2k server replies with 2048. All subsequent
> requests have 2048 for both the request and reply.
As per my other mail, I think he meeant process ID, not user ID.
The CIFS Technical Reference 1.00 on the SNIA Web site:
http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf
says:
3.2.5. Pid Field
Pid is the caller's process id, and is generated by the client
to uniquely identify a process within the client computer.
Concurrency control is associated with Pid (and PidHigh)--
sharing modes, and locks are arbitrated using the Pid. For
example, if a file is successfully opened for exclusive access,
subsequent opens from other clients or from the same client with
a different Pid will be refused. 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. It is up to the client operating
system to ensure that only authorized client processes gain
access to Fids (and Tids). On SMB_COM_TREE_DISCONNECT (or when
the client and server session is terminated) with a given Tid,
the server will invalidate any files opened by any process on
that client.tid Field
...
3.2.7. Mid Field
The multiplex ID (Mid) is used along with the Pid 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 (up to the negotiated
number, MaxMpxCount) at one time. Servers MAY respond to
requests in any order, but a response message MUST always
contain the same Mid and Pid values as the corresponding request
message. The client MUST NOT have multiple outstanding requests
to a server with the same Mid and Pid.
which suggests that it is, at least, unwise to reply with a PID other
than the one in the request. The CIFS Technical Reference isn't a
Microsoft publication saying "THIS IS THE OFFICIAL WAY CIFS WORKS, AND
IF YOU DON'T WORK THAT WAY YOU'RE NOT CIFS" (I would not be surprised,
in fact, to find that Microsoft have a few places where they don't work
the same way - and perhaps some places where different releases of
Windows behave differently, or where Windows OT and Windows NT behave
differently, with one or the other or both not matching the spec, and
that at least some of those places cause customer problems.)
If, for example, packet 17 is a request and packet 18 is a reply to that
request, I'd suggest to the Samba-TNG folks, if the reply is coming from
Samba-TNG, that it would have been a Really Good Idea if the process ID
in packet 18 had been 18014 rather than 124, unless that's something
that they *have* to do in order not to have problems with clients.
Perhaps, with the client in question, they can *get away with* that, but
it does appear to disagree with the SNIA spec, *and* Ethereal does, as I
remember, have to match both MID *and* PID in order to avoid matching
replies with the wrong request, in at least some captures.