[cifs-protocol] [CUSTOMER THREAD] TDI 70836 [MS-SMB2]: Async header [REG:113111510952353]

[Christopher R. Hertel]

[Below...]

On 12/12/2013 06:27 PM, Bryan Burgin wrote:
> [David, Chandra to bcc; re-add as necessary]
> [+Chris] [CUSTOMER ON THREAD]
> [+Casemail and case #]
> 
> Chris, to raise your concern and or to continue the dialog, please use this
> thread.
> 
> Bryan
> 
> [Private thread trimmed]

Thanks, Bryan.

Sorry for the delay in continuing the conversation.  A lot was happening in
Shanghai.  Good event, all around.  It took me some time to catch up when I
got back, however, and the jet lag got me after the return trip.

Okay... so...

What I was trying to figure out, from [MS-SMB2], was the circumstances under
which the SYNC or ASYNC header is used.  The basic rules are (currently)
given in section 2.2.1.  I quote:

P1: If the SMB2_FLAGS_ASYNC_COMMAND bit is set in Flags, the header takes
    the form SMB2 Packet Header – ASYNC (section 2.2.1.1). This header
    format is used for responses to requests processed asynchronously by
    SMB2 server. For more details, refer to sections 3.3.4.2, 3.2.5.1.5, and
    3.2.4.24.  The SMB2 CANCEL Request uses this format for canceling
    requests that are being processed asynchronously.

P2: If the SMB2_FLAGS_ASYNC_COMMAND bit is not set in Flags, the header
    takes the form SMB2 Packet Header – SYNC (section 2.2.1.2). This format
    is used for all requests with the exception of the SMB2 CANCEL Request
    to cancel a previously sent request being processed asynchronously.

Let's focus on the SMB2_CANCEL command first.

The above makes it pretty clear that:
  P1 - An SMB2_CANCEL request can be sent using the ASYNC header.
  P2 - The SYNC header is not used to send SMB2_CANCEL requests.
Therefore, all SMB2_CANCEL requests are sent using the ASYNC header.

Section 2.2.1.2 lists the SMB2_CANCEL command as one of the commands
that can be sent with a SYNC header.  For that to be true (given section
2.2.1), the SYNC header would need to be used in a reply message (since we
already know that SMB2_CANCEL *requests* are only sent using the ASYNC header).

There is no such thing as an SMB2_CANCEL response message, but there could
be an ERROR Response sent to an SMB2_CANCEL request.   Digging further...

Section 3.3.5.16 makes it clear that no ERROR Response is sent to indicate
an error in response to an (errant) SMB2_CANCEL request.  That means there
is NO response of any kind that would contain the SMB2_CANCEL command code.

Therefore:  The SMB2_CANCEL command code is *never* included in a SYNC header.

...except that Section 3.3.5.16 contradicts section 2.2.1.  Section 3.3.5.16
states:

    If SMB2_FLAGS_ASYNC_COMMAND is not set [in the Flags field of the SMB2
    header of the cancel request], then the server MUST search for a
    request in Connection.RequestList where Request.MessageId matches the
    MessageId of the incoming cancel request.

So, in theory, an SMB2_CANCEL request *MAY* be sent using a SYNC header.

Which is it?  What behavior does Windows follow?
* Can Windows clients send SYNC SMB2_CANCEL requests?  Do they?
* Will Windows servers handle a SYNC SMB2_CANCEL request?

That's just the one command.  There are additional questions to be addressed
here.  For example, Section 3.3.5.16 states:

    If a request is found, the server MUST attempt to cancel the request
    that was found, referred to here as the target request, by calling into
    the underlying object store.<320> If the target request is successfully
    canceled, the target request MUST be failed by sending an ERROR response
    packet as specified in section 2.2.2, with the status field of the SMB2
    header (specified in section 2.2.1) set to STATUS_CANCELLED. If the
    target request is not successfully canceled, processing MUST continue as
    is typical for the target request. No response is sent to the cancel
    request.

Gurgle.

This paragraph refers to the underlying object store, indicating that the
commands that may be executed asynchronously are those that are passed to
another (lower) layer of the system.

So...  Can an SMB2_ECHO be executed asynchronously?  Is it ever possible to
send an SMB2_CANCEL to cancel a pending echo operation?  If not, then
SMB2_ECHO should not be listed as a possible Command field value in section
2.2.1.1.

Could a server *choose* to support asynchronous SMB2_ECHO requests?  If so,
what do Windows servers do?  Do they allow such a thing?  Will Windows
clients handle an Interim response to an Echo request?

Thanks.

Chris -)-----


-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org