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
