[cifs-protocol] [MS-SMB2] Compound/async request handling, 117061615905952

[Moritz Bechler]

Hi,

Thanks for the clarification. That is exactly like I thought it was
supposed to work. Then I'll just have to figure out which ones deviate
from the specified behavior and avoid them.

Moritz

> I went through each of your questions and provide answers below, in line...
> 
> ~ ~ ~
> 
> So, the actual questions are...
> 
> ~ ~ ~ 1 ~ ~ ~
> 
> 1. what is the expected behavior of a server when it decides to process a request asynchronously in the middle (or at the start) of a compound
> chain:
> 
> A) fail (with STATUS_INTERNAL_ERROR), if so, are there exemptions to this rule (besides CREATE)
> 
> B) send an interim response for the request that is processed asynchronously, not the remaining chain
> 
> C) send interim responses for all the remaining requests in the chain
> 
> Answer: per is that the remaining requests go asynch, too.  See [MS-SMB2] 3.3.5.2.7.2 "Handling Compounded Related Requests" when it says "When an operation requires asynchronous processing, all the subsequent operations MUST also be processed asynchronously. The server MUST send an interim response for all such operations as specified in section 3.3.4.2.  When all operations are complete, the responses SHOULD be compounded into a single response to return to the client. If the responses are compounded, the server MUST set SMB2_FLAGS_RELATED_OPERATIONS in the Flags field of the SMB2 header of all responses except the first one. This indicates that the response was part of a compounded chain."
> 
> ~ ~ ~ 2 ~ ~ ~
> 
> 2. are there any other limits on compounding related requests, except that SID,TID,FID need to be either provided or produced by a preceding request?
> 
> 2.1. Specifically, is it legal behavior to use a produced SID/TID?
> 
> SESSION_SETUP + X (if either signing is not required or the session key already available), X using the session
> 
> TREE_CONNECT + X, X using the tree connection
> 
> Answer: This was previously answered.  But, it is discussed at [MS-SMB2] 3.3.5.2.7.2 "Handling Compounded Related Requests" that describes how a SID, TID and FID should cascade from the result of a previous operation in the compound chain: "The server MUST handle each individual operation that is described in the chain in order. For the first operation, the identifiers for FileId, SessionId, and TreeId MUST be taken from the received operation. For every subsequent operation, the values used for FileId, SessionId, and TreeId MUST be the ones used in processing the previous operation or generated for the previous resulting response.  When the current operation requires a SessionId or TreeId, and if the previous operation failed to create SessionId or TreeId, or the previous operation does not contain a SessionId or TreeId, the server MUST fail the current operation and all subsequent operations with STATUS_INVALID_PARAMETER.  When the current operation requires a FileId, and if the previous operation neither contains nor generates a FileId, the server MUST fail the current operation and all subsequent operations with STATUS_INVALID_PARAMETER."
> 
> 
> 
> ~ ~ ~ 2.2 ~ ~ ~
> 
> 2.2. Specifically, are edge case like the IOCTL(FSCL_PIPE_WAIT)/CREATE/WRITE/... allowed as the IOCTL does not strictly relate to the same FID? Or even a chain with multiple CREATE/.../CLOSE blocks (using the FID of the last preceding CREATE)?
> 
> Answer: There is a note attached to [MS-SMB2] 3.3.4.2 "Sending an Interim Response for an Asynchronous Operation"  The first <wbn> (Windows Behavior Not) identifies which operations a Windows server will take asynch:
> 
> <194> Section 3.3.4.2: Windows-based servers send interim responses for the following operations if they cannot be completed immediately:
> §	SMB2_CREATE, if the underlying object store indicates an Oplock/Lease Break Notification or if access/sharing modes are incompatible with another existing open
> §	SMB2_CHANGE_NOTIFY
> §	Byte Range Lock
> §	Named Pipe Read on a blocking named pipe
> §	Named Pipe Write on a blocking named pipe
> §	Large file write
> §	FSCTL_PIPE_TRANSCEIVE
> §	FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE, when oplock break happens
> §	SMB2 FLUSH on a named pipe
> §	FSCTL_GET_DFS_REFERRALS
> 
> But, then, there is a note specific to FSCL_PIPE_WAIT:
> 
> <195> Section 3.3.4.2: Windows-based servers incorrectly process the FSCTL_PIPE_WAIT request on named pipes synchronously.
> 
> ~ ~ ~ 3 ~ ~ ~
> 
> 3. are there any rules which requests _may_ be processed asynchronously by a server - therefore in the current situation cannot be safely used in compound chains except when they are the last request of the chain.
> 
> Answer: As cited above, once a request goes async, then all the remaining ones must also go async.
> 
> 
> ~ ~ ~ 4 ~ ~ ~
> 
> 4. Regarding a) or 1.B, how should request timeouts be handled? As only an interim response for the CREATE request is sent which updates the CREATE's request timeout, but there are no interim responses for the remaining requests should the client adjust these automatically as well or is the desired behavior that these would timeout before the CREATE?
> 
> Answer: As we don't take option "1.b", above, but rather "1.c" -- " send interim responses for all the remaining requests in the chain -- I think this question drops out.  There are quite a few rules surrounding timeouts.  But many involve specific situations regarding if various CreateFile features are used (resiliency, leases, etc.).
> 
> B. 


-- 
AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch