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

[Nathan Manis]

Hi Mortiz,

Thank you for contacting the Microsoft Open Specifications team.   We have received the request and created a case to assist further.   The case number is 117061615905952.   A member of the team will be in touch to follow-up and assist.

 
Thanks,
Nathan Manis

-----Original Message-----
From: Moritz Bechler [mailto:bechler at agno3.eu] 
Sent: Friday, June 16, 2017 11:10 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [MS-SMB2] Compound/async request handling

Hi,

we have hit some uncertainties/inconsistencies with compound request chains, especially regarding possible async replies.

How should a server behave when it receives a compound (related) request chain and it decides to process any but the last request asynchronously?
Testing shows the following product behaviors:

a) If a CREATE is received, not the last request of the chain, and asynchronously processed (e.g. when a lock is held) - the server responds with an interim response for the CREATE request (not for the remaining chained request) and later with the final response for the CREATE as well as the remaining requests.

b) For pretty much every other request for which the server chooses async processing and there are remaining commands in the chain, the request going async fails with STATUS_INTERNAL_ERROR.

Some, admittedly fabricated - but imho not totally nonsensical, examples where this can be observed would be

CREATE/CHANGE_NOTIFY/CLOSE
IOCTL(FSCL_PIPE_WAIT)/CREATE/WRITE


So the actual questions are,

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


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

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)?


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.


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?



regards

Moritz

--
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