none
Possible error in [ms-smb2].pdf ? RRS feed

  • Question

  • Hi,

    I am implementing an SMB2 server. I have been struggling to understand the Async Cancel messages that the Windows client sends to the server. I now have these working, but the protocol doc did not help. It turns out (on tracing two windows boxes with NetMon), that the Cancel messages are intended to cancel the Notifications that have been set previously. If STATUS_CANCELLED is not returned for the outstanding Notify messages (within about a minute) the Windows client resets the TCP connection.

    However the SMB2 headers sent by the Win 7 client do not agree with the description in the MS-SMB2 pdf. To quote from the doc:

    2.2.30 SMB2 CANCEL Request
    The SMB2 CANCEL Request packet is sent by the client to cancel a previously sent message on the same SMB2 transport connection.
    The MessageId of the request to be cancelled MUST be set in the SMB2 header of the request.

    3.3.5.16 Receiving an SMB2 CANCEL Request
    ...
    If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the cancel request, the server MUST search for a request in Connection.AsyncCommandList that matches both the MessageId and the AsyncId of the incoming cancel request. 

    However the MessageId of the cancel messages sent by the Windows client all have MessageId set to zero.

    Further, the semantics of the SessionID in the Async Header are not clear - this is set by the Windows Client, yet the doc states:

    2.2.1.1 SMB2 Packet Header - ASYNC
    ...
    SessionId SHOULD<2> be set to 0 for the following commands:
    ..
    SMB2 CANCEL request

    6 Appendix A: Product Behavior
    ...
    <2> Section 2.2.1.1: Windows-based clients always set the SessionId field to 0 for these commands, and Windows-based servers will ignore SessionId for these commands.

    So the doc and Windows do not match.

    Any clarification would be gratefully received.

    Cheers,

    James.

    James Westland Cain, Ph.D.
    Principal Software Architect
    Quantel Research & Development

     

    Monday, November 22, 2010 10:45 PM

Answers

  • Hi

    I communicated with James via email and the following solution was provided to him.

    A future release of MS-SMB2 will include the following modifications.

    Section “2.2.1.1   SMB2 Packet Header – ASYNC”

    -------------------------------------------------------------

    SMB2_CANCEL_request is removed from the list of commands that SHOULD set SessionId to 0.

     

     

    Section “3.2.4.24   Application Requests Canceling an Operation”

    -------------------------------------------------------------------------------

    1.       The sentence

     

    “The client initializes an SMB2 CANCEL Request following the syntax specified in section 2.2.30. The SMB2 header MUST be initialized as follows:”

     

    will be modified as

     

    “The client initializes an SMB2 CANCEL Request following the syntax specified in section 2.2.30. The SMB2 header is initialized as follows:”

     

    2.       The following bullet:

    “The MessageId field is set to the identifier that is previously used for the request being canceled. Because the same MessageId is reused, cancel requests MUST NOT consume a sequence number.”

     

    will be modified as

    “The MessageId field SHOULD be <WBN> set to the identifier that is previously used for the request being canceled. Because the same MessageId is reused, cancel requests MUST NOT consume a sequence number.”

     

    and the following windows behavior note (WNB) will be added in Section 6 Appendix A: Product Behavior

    “Windows based clients set the MessageId to 0, when the AsyncId is set to an asynchronous identifier of the request”

    3.       A new bullet will be added as follows:

    “The SessionId field SHOULD be set to 0. <WBN>”

     

    and the following windows behavior note (WNB) will be added in Section 6 Appendix A: Product Behavior

    “Windows based clients set the SessionId to TreeConnect.Session.SessionId, and Windows-based servers will ignore this field”

     

     

    Section “3.3.5.16   Receiving an SMB2 CANCEL Request”

    -------------------------------------------------------------------

    The following paragraph:

     

    “The server MUST locate the request being canceled by searching the Connection.RequestList. If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the cancel request, the server MUST search for a request in Connection.AsyncCommandList that matches both the MessageId and the AsyncId of the incoming cancel request. If SMB2_FLAGS_ASYNC_COMMAND is not set, then the server MUST search for a request that matches the MessageId of the incoming cancel request.”

     

    Will be modified as follows:

     

    “The server MUST locate the request being canceled by searching the Connection.RequestList. If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the cancel request, the server MUST search for a request in Connection.AsyncCommandList that matches the AsyncId of the incoming cancel request. If SMB2_FLAGS_ASYNC_COMMAND is not set, then the server MUST search for a request that matches the MessageId of the incoming cancel request.”

     


    Regards, Obaid Farooqi
    Tuesday, December 7, 2010 4:28 PM
    Owner

All replies

  • Hi James:

    I have alerted the Protocol Documentation Team regarding your question on MS-SMB2. A member of the team will be in touch soon.


    Regards, Obaid Farooqi
    Monday, November 22, 2010 11:54 PM
    Owner
  • Hi James:

    I'll assist you with this issue. I'll be in touch as soon as I have an answer for you. If I have a question or clarification, I'll post here.

     


    Regards, Obaid Farooqi
    Tuesday, November 23, 2010 12:05 AM
    Owner
  • Hi James:

    Can you please provide some network traces to illustrate the issue? You can send them

    To: intopdoc@microsoft.com

    CC: casemail@microsoft.com

    Subject: [REG: 210112286332872001]


    Regards, Obaid Farooqi
    Wednesday, November 24, 2010 6:41 PM
    Owner
  • Hi Obaid,

    A zip of a NetMon trace has been emailed as requested.

    Cheers,

    James.

    Wednesday, November 24, 2010 8:59 PM
  • Hi

    I communicated with James via email and the following solution was provided to him.

    A future release of MS-SMB2 will include the following modifications.

    Section “2.2.1.1   SMB2 Packet Header – ASYNC”

    -------------------------------------------------------------

    SMB2_CANCEL_request is removed from the list of commands that SHOULD set SessionId to 0.

     

     

    Section “3.2.4.24   Application Requests Canceling an Operation”

    -------------------------------------------------------------------------------

    1.       The sentence

     

    “The client initializes an SMB2 CANCEL Request following the syntax specified in section 2.2.30. The SMB2 header MUST be initialized as follows:”

     

    will be modified as

     

    “The client initializes an SMB2 CANCEL Request following the syntax specified in section 2.2.30. The SMB2 header is initialized as follows:”

     

    2.       The following bullet:

    “The MessageId field is set to the identifier that is previously used for the request being canceled. Because the same MessageId is reused, cancel requests MUST NOT consume a sequence number.”

     

    will be modified as

    “The MessageId field SHOULD be <WBN> set to the identifier that is previously used for the request being canceled. Because the same MessageId is reused, cancel requests MUST NOT consume a sequence number.”

     

    and the following windows behavior note (WNB) will be added in Section 6 Appendix A: Product Behavior

    “Windows based clients set the MessageId to 0, when the AsyncId is set to an asynchronous identifier of the request”

    3.       A new bullet will be added as follows:

    “The SessionId field SHOULD be set to 0. <WBN>”

     

    and the following windows behavior note (WNB) will be added in Section 6 Appendix A: Product Behavior

    “Windows based clients set the SessionId to TreeConnect.Session.SessionId, and Windows-based servers will ignore this field”

     

     

    Section “3.3.5.16   Receiving an SMB2 CANCEL Request”

    -------------------------------------------------------------------

    The following paragraph:

     

    “The server MUST locate the request being canceled by searching the Connection.RequestList. If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the cancel request, the server MUST search for a request in Connection.AsyncCommandList that matches both the MessageId and the AsyncId of the incoming cancel request. If SMB2_FLAGS_ASYNC_COMMAND is not set, then the server MUST search for a request that matches the MessageId of the incoming cancel request.”

     

    Will be modified as follows:

     

    “The server MUST locate the request being canceled by searching the Connection.RequestList. If SMB2_FLAGS_ASYNC_COMMAND is set in the Flags field of the SMB2 header of the cancel request, the server MUST search for a request in Connection.AsyncCommandList that matches the AsyncId of the incoming cancel request. If SMB2_FLAGS_ASYNC_COMMAND is not set, then the server MUST search for a request that matches the MessageId of the incoming cancel request.”

     


    Regards, Obaid Farooqi
    Tuesday, December 7, 2010 4:28 PM
    Owner