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

[Obaid Farooqi]

Hi Chris:
We have finished our investigation on your questions. Please see the answers to your questions in Q&A format as follows:

Q 1:
> What I was trying to figure out, from [MS-SMB2], was the circumstances 
> under which the SYNC or ASYNC header is used.

A: 
Ok. Good goal.

Q 2:
>  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.

A:
This is not correct. The ASYNC form is only used to cancel requests to which the server has responded with an asynchronous interim response.

In MS-SMB2 section 3.2.4.24   Application Requests Canceling an Operation, the following statement appears:

+++  If the command has returned an indication of an asynchronous response, the client sets SMB2_FLAGS_ASYNC_COMMAND to TRUE in the Flags field and sets AsyncId to the asynchronous identifier for the request.

The asynchronous identifier is supplied by the server in its interim response, so if that is not known, the SMB2_CANCEL is sent in SYNC form, carrying only the request's original messageid.

Q 3:
> 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).

A:
It is correct that SMB2_CANCEL can be sent as SYNC, as pointed out in the previous statement.

Q 4: 
> 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.

A:
Actually, that is incorrect, but only for a very unlikely condition. The SMB2_CANCEL command can generate a server response if the SMB2 request itself is invalid or cannot be processed by the server. For example, if the request were improperly constructed (3.3.5.2.6), or if signing failed (3.3.5.2.4), etc. In such cases, standard server error response processing will happen regardless of the actual request in the payload. Of course, these would be from broken clients, but the responses are valid protocol.

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

A:
Regrettably incorrect, as above.

Q 6:
> 
> ...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.

A:
Indeed.
 
Q 7:
> Which is it?  What behavior does Windows follow?

Either/both, depending on whether an asynchronous interim response has been seen prior to the cancellation being sent.

Q 8:
> * Can Windows clients send SYNC SMB2_CANCEL requests?  Do they?

A:
Yes.

Q 9:
> * Will Windows servers handle a SYNC SMB2_CANCEL request?

A:
Yes. In fact, Windows servers will handle any command received in either SYNC or ASYNC format.

Q 10:
> 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.

A:
Indeed, it's perhaps confusing, but it is an accurate discussion of the protocol.

Q 11:
> 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.

A:
It's only one possibility. Technically speaking, the statement could be modified to more abstractly define the required server behavior rather than appearing to restrict its applicability to local object store operations.

Q 12:
> So...  Can an SMB2_ECHO be executed asynchronously?

A:
There are two ways to read your question. If you mean whether the server processes an SMB2_ECHO that arrived with an asynchronous header, yes definitely. If on the other hand you are asking whether the server might respond to an SMB2_ECHO with an interim response, followed by a final response, well it might be silly but it too is indeed possible. Windows servers do not do this.

Q 13:
>  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.

A:
Yes, it's possible. Any command can be requested by the client to be canceled.

Q 14: 
> Could a server *choose* to support asynchronous SMB2_ECHO requests?  
> If so, what do Windows servers do?

A:
I think I answered this above, but if I misunderstand please clarify the question. Windows servers always process SMB2_ECHO synchronously, that is, they do not make an interim response.

Q 15:
>  Do they allow such a thing?

A:
Yes, as above.

Q 16:
>  Will Windows
> clients handle an Interim response to an Echo request?

A:
Yes. Windows clients will handle interim and final responses to any request, as documented in MS-SMB2 section 3.2.5.1.5.




Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com

-----Original Message-----
From: Christopher R. Hertel [mailto:crh at samba.org] 
Sent: Tuesday, December 17, 2013 1:39 AM
To: Bryan Burgin
Cc: Tom Talpey; Obaid Farooqi; MSSolve Case Email; cifs-protocol at samba.org
Subject: Re: [CUSTOMER THREAD] TDI 70836 [MS-SMB2]: Async header [REG:113111510952353]

[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