This is all well and good. Here is the problem: Samba-TNG is the
client, and the server is a Win2k Professional system. I can't blame
Samba-TNG if it's the Win2k system that is sending back a Process ID in
the response that doesn't match the request.
-Devin
On Wed, 2003-02-19 at 17:22, Guy Harris wrote:
> 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.
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
