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

[Moritz Bechler]

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