none
Client sending FileID of previous session as part of certain requests of the new session established RRS feed

  • Question

  • We don't support "Durable Handles" in our implementation of SMBv2 dialect. However, based on the description in section 3.3.5.9 of [MS-SMB2]:

    "Successful Open Initialization:

    Open.DurableFileId is set to a generated value that uniquely identifies this open in GlobalOpenTable"

    we started to fill the FileID.Persistent with a unique ID we generate. Upon sending FileIDs filled with the Persistent part, client upon reconnect is sending few requests with a FileID that was opened/sent to it in previous session (before reconnect). So, even when server conveyed durable handles feature is not supported can we know why client is sending requests with FileID opened in previous session?


    S Rahul Kumar

    Saturday, July 29, 2017 2:39 PM

Answers

  • This is summary post that we archived this issue. It is observed that the client is compounding Create and ChangeNotify where no durable handle is involved. After reconnection, it’s not expected that the FileId in the subsequent ChangeNotify has the old FileId. Old file IDs should have been invalidated already when the connection was lost. This appears an unexpected client implementation behavior, which should not affect the server and the server must fail the request with STATUS_FILE_CLOSED if it can’t find an open that matches the FileId.

    Reference [MS-SMB2] 3.3.5.19 Receiving an SMB2 CHANGE_NOTIFY Request

    Thanks,

    Edgar

    Tuesday, August 15, 2017 4:21 PM
    Moderator

All replies

  • Hello S Rahul,

    Thank you for raising your questions on MS-SMB2 regarding persistent file ID and durable handles. I have created a support request to track your question and a member of the Open Specifications Support team will reply to your posting regarding your questions.

    Sincerely,
    Will Gregg | open specifications

    Saturday, July 29, 2017 10:39 PM
    Moderator
  • Rahul,

    Can you send me a network trace (captured with Wireshark or Microsoft network monitor) at this address: dochelp < at > microsoft < dot > com? Please mention this thread and address the message to my attention. I’d like to take a look.

    Thanks,
    Edgar

    Sunday, July 30, 2017 4:42 AM
    Moderator
  • This is summary post that we archived this issue. It is observed that the client is compounding Create and ChangeNotify where no durable handle is involved. After reconnection, it’s not expected that the FileId in the subsequent ChangeNotify has the old FileId. Old file IDs should have been invalidated already when the connection was lost. This appears an unexpected client implementation behavior, which should not affect the server and the server must fail the request with STATUS_FILE_CLOSED if it can’t find an open that matches the FileId.

    Reference [MS-SMB2] 3.3.5.19 Receiving an SMB2 CHANGE_NOTIFY Request

    Thanks,

    Edgar

    Tuesday, August 15, 2017 4:21 PM
    Moderator