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

Christopher R. Hertel crh at samba.org
Fri Jan 10 15:28:02 MST 2014


Obaid,

I will review this and get back to you some time next week.

Thanks!

Chris -)-----

On 01/10/2014 04:22 PM, Obaid Farooqi wrote:
> Hi Chris:
> We have finished our investigation on your inquiry about ASYNC header in MS-SMB2 document. A future release of MS-SMB2 document will include the following modifications:
>
> Section 2.2.1
> ----------------
> Existing text:
>> 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.
>
> 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.
>>
> Modified text:
>> 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 on use of this flag for responses, refer to sections 3.3.4.2 and 3.2.5.1.5. This header format MAY be used for any request, and the SMB2 CANCEL Request uses this format for canceling requests that are being processed asynchronously, refer to section 3.2.4.24.
> 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 can be used for all requests and responses.
>>
> Section 3.2.1.7
> --------------------
> The following definition will be added:
>> Request.AsyncId: An identifier generated by the server and sent to the client in an interim asynchronous response.
>>
> Section 3.2.4.1.3
> ---------------------
> Existing text:
>> For an SMB2 CANCEL Request, the client SHOULD<86> set the MessageId field to the identifier that was used for the request that is to be canceled. Because there is no response to the SMB2 CANCEL Request, it MUST NOT be inserted into Connection.OutstandingRequests, and the Request Expiration Timer MUST NOT be set.
>>
> Modified text:
>> For an SMB2 CANCEL Request, the client SHOULD<86> set the MessageId field to the identifier that was used for the request that is to be canceled. The SMB2 CANCEL Request MUST NOT be inserted into Connection.OutstandingRequests, and the Request Expiration Timer MUST NOT be set.
>>
> Section 3.2.4.24
> -------------------
> Existing text:
>> • 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 SessionId field SHOULD<140> be set to 0.
>
>
> The SMB2 CANCEL Request MUST be initialized to the default values, as specified in 2.2.30.
>
> The request MUST be sent to the server.
>
> There is no response to a cancel request, and no status is returned to the caller.
>>
> Modified text:
>> 	• If Request.AsyncId is not empty, indicating that the command has previously 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 Request.AsyncId.
> 	• The SessionId field SHOULD<141> be set to 0.
>
> The SMB2 CANCEL Request MUST be initialized to the default values, as specified in 2.2.30.
> The request MUST be sent to the server.
> No status is returned to the caller.
>>
> Section 3.2.5.1.5
> ---------------------
> Existing text:
>> If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the response and the Status field in the SMB2 header is STATUS_PENDING, the client MUST mark the request in Connection.OutstandingRequests as being handled asynchronously and store the new AsyncId of the request. Processing of this response is now complete.
>
> If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header and Status is not STATUS_PENDING, this is a response to an asynchronous request and processing MUST continue as specified below.
>>
> Modified text:
>> If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the response and the Status field in the SMB2 header is STATUS_PENDING, the client MUST mark the request in Connection.OutstandingRequests as being handled asynchronously by storing the AsyncId of the response in Request.AsyncId. Processing of this response is now complete.
>
> If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header and Status is not STATUS_PENDING, this is a final response to a request which was processed by the server asynchronously, and processing MUST continue as specified below.
>>
> Section 3.3.4.1.3
> --------------------
> Existing text:
>> The server SHOULD<186> fail requests in a compound chain that are converted to asynchronous operations.
>>
> Modified text:
>> The server SHOULD<187> fail requests in a compound chain that would require asynchronous processing
>>
> Section 3.3.4.3
> ------------------
> Existing text:
>> • 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.
>
>>
> Modified text:
>> • If Request.AsyncId is nonzero, the server MUST set the AsyncId field to it, MUST set the SMB2_FLAGS_ASYNC_COMMAND bit in the Flags field, and MUST set the CreditResponse field to 0.
>
> • Otherwise, 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.
>>
> Section 3.3.4.4
> ------------------
> Existing text:
>> •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.
>>
> Modified text:
>> • If Request.AsyncId is nonzero, the server MUST set the AsyncId field to it, MUST set the SMB2_FLAGS_ASYNC_COMMAND bit in the Flags field, and MUST set the CreditResponse field to 0.
>
> • Otherwise, 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.
>>
> Section 3.3.5.2.7
> --------------------
> Existing text:
>> If the NextCommand field in the SMB2 header of the request is not equal to 0, the server MUST process the received request as a compounded series of requests. The server SHOULD<206> fail requests in a compound chain that try to go async. There are two different styles of compounded requests, which are described in the following sections.
>>
> Modified text:
>> If the NextCommand field in the SMB2 header of the request is not equal to 0, the server MUST process the received request as a compounded series of requests. The server SHOULD<207> fail requests in a compound chain which require asynchronous processing.
> There are two different styles of compounded requests, which are described in the following subsections.
>>
> 3.3.5.17
> ----------
> Exiting text:
>> 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.
>>
> Modified text:
>> If a request is found, the server MUST attempt to cancel the request that was found, referred to here as the target request.<323> 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 of the target request MUST continue, and no response is sent to the cancel request.
>>
> Section 6
> -----------
> Existing text:
>> <156> Section 3.2.6.1: Windows clients extend the Request Expiration Timer for asynchronous requests as follows:
>>
> Modified text:
>> <156> Section 3.2.6.1: Windows clients extend the Request Expiration Timer for requests being processed asynchronously as follows:
>>
> Existing text:
>> <320> Section 3.3.5.16:  Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter.
>>
> Modified text:
>> <323> Section 3.3.5.16: When being handled by an object store, Windows performs cancellation of in-progress requests via the interface in [MS-FSA] section 2.1.5.19, Server Requests Canceling an Operation, passing Request.CancelRequestId as an input parameter. Windows does not attempt to cancel other requests.
>>
>
>
> 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: Wednesday, January 8, 2014 4:18 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 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
>

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