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

Obaid Farooqi obaidf at microsoft.com
Wed Jan 8 15:18:07 MST 2014


Hi Chris:
I have been working with PG on this issue.
Your input is definitely very valuable and more so in the light of your experience as being an open specification author. As being a author yourself, you would understand the requirements of the template that we follow. The current proposal to alleviate your concerns about this issue is to modify the document, where appropriate, with clarifying text about ASYNC header along the lines of our email communication and modify section 2 as I have communicated before.

Please let me know if this solution satisfies your concerns.

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: Obaid Farooqi 
Sent: Monday, December 23, 2013 1:44 PM
To: 'Christopher R. Hertel'
Cc: Tom Talpey; MSSolve Case Email; cifs-protocol at samba.org; Bryan Burgin
Subject: RE: [CUSTOMER THREAD] TDI 70836 [MS-SMB2]: Async header [REG:113111510952353]

Hi Chris:
I'll consult with PG and will be in touch as soon as I have a response.

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: Saturday, December 21, 2013 11:51 PM
To: Obaid Farooqi
Cc: Tom Talpey; MSSolve Case Email; cifs-protocol at samba.org; Bryan Burgin
Subject: Re: [CUSTOMER THREAD] TDI 70836 [MS-SMB2]: Async header [REG:113111510952353]

Obaid,

I have read through and considered your responses, copied below.  Based on your explanations and my re-reading of the sections you highlighted, I conclude that:

- Your explanations of SYNC vs. ASYNC are much better than the text in
  the document.
- Information on the workings of SYNC vs. ASYNC is scattered throughout
  [MS-SMB2] and is, therefore, hard to find and follow.
- The information that is available seems to me to be incomplete and
  contradictory.

Let's start with section 2.2.1.
The current text in that section (which was copied in my earlier message,
below) appears to exclude the use of the SYNC header when sending and SMB2_CANCEL.  The SYNC header, according 2.2.1, is used for all requests "with the exception of the SMB2 CANCEL Request".  That point needs to be clarified.

The proposal on the table is to remove the text in section 2.2.1.  That won't help.  What is needed is to correct and expand the explanation in section 2.2.1 and to provide the background that you have supplied in this e'mail thread.

Further notes:

Q4: In your answer to what you identified as question #4, you wrote:

    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.

Signing will never fail for an SMB2_CANCEL command.  According to section
3.3.5.16:

  An SMB2_CANCEL Request is the only request received by the server that
  is not signed and does not contain a sequence number that must be
  checked.

I have to assume that the above is true for both SYNC and ASYNC SMB2_CANCEL requests (though I don't see any text that specifies that it's true in both cases).

That means that the only case in which the SMB2_CANCEL command code will appear in a response is an improperly constructed SMB2_CANCEL request (the other possibility that you described).

Question:  What header format should be used when sending a STATUS_INVALID_PARAMETER ERROR Response in response to a malformed SMB2_CANCEL request?  The answer is not clear from section 3.3.4.4, which states the following:

  * If the request was handled asynchronously, the server MUST set the
    AsyncId field to the asynchronous identifier generated for this
    request, and set the SMB2_FLAGS_ASYNC_COMMAND bit in the Flags field.
  * If the request was not handled asynchronously, the server MUST set the
    CreditResponse field to the number of credits the server chooses to
    grant the request, as specified in section 3.3.1.2.  If the request
    was handled asynchronously, the server MUST set the CreditResponse
    field to 0.

I don't believe that the SMB2_CANCEL request itself can be handled asynchronously.  Tell me if I'm wrong about that, but I don't imagine that there is an Interim SMB2_CANCEL response.  That being the case, if SMB2_CANCEL request is malformed, does the server send back the error message using the SYNC format, or the same format as the malformed request?
Should the CreditResponse still be set to zero?

...and I will also mention that several sections make statements like:

  "There is no response to a cancel request, and no status is returned to
  the caller."

While I understand that an ERROR Response to a malformed request isn't exactly a response to the specific command, such statements are confusing to any newcomers to the documentation.

One more thing that's troubling me.  In your response to Q12, below, you wrote:

  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.

In section 3.3.5.17, where the server-side handling of the SMB2_ECHO request is described, there is no Windows behavior note indicating that Windows never handles SMB2_ECHO asynchronously.  For each command, there SHOULD be a behavior note indicating whether or not Windows servers will attempt to run the command asynchronously (and, if applicable, under which conditions Windows will choose to do so).

Overall...  I think section 2.2.1 needs to be corrected and expanded.  It would also help greatly if a more complete overview of SYNC vs. ASYNC handling were provided.  As the document is currently written, the information that would lead the reader to the understanding that you have provided in this e'mail thread is disjoint and incomplete.

Thanks for your efforts.

Chris -)-----

On 12/19/2013 12:55 PM, Obaid Farooqi wrote:
> 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
> 

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


More information about the cifs-protocol mailing list