[cifs-protocol] 114111212024789 Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context

[Anubhav Rakshit]

Hi Sreekanth,

Thanks for the explanation. The CreateGuid cache that you described is not
mentioned in the Abstract Data Model section of MS-SMB2. It will be good if
its documented.

Regards,
anubhav

On Thu, Nov 27, 2014 at 10:13 AM, Sreekanth Nadendla <srenaden at microsoft.com
> wrote:

>  Hello Anubhav,
>
> Upon further analysis today, we have found that the observed behavior is a
> result of race condition with respect to oplock processing. Below are
> additional details. This explains the behavior you are seeing.
>
>
>
> *Some background about CreateGUID.*
>
>
>
> CreateGuid is used to allow a client to replay an open for which it has
> not seen the response. The idea is when the client does not know the SMB2
> FID, it can’t use the durable v1 form of reconnecting to the Open. Client
> is expected to issue a replay, but there is no way to refer to a previous
> open.  In this situation, by allowing the client to provide a GUID that
> identifies an open, they can refer to it.  So for this purpose after
> processing a create, the server maintains this value in a cache. This cache
> is maintained for creates that we are not sure the client has seen the
> response for.
>
>
>
>
>
> When the client issues a subsequent request with actual file id, it has
> now acknowledged that it knows the SMB2 file id (i.e. it received the
> create response) so a recovery of a handle will now be a *resume* and NOT
> a *replay*.  This means that caching the create by CreateGuid is no
> longer necessary, and as such, when Server receives a request using the
> SMB2 file id, it removes it from the cache as it is no longer needed.
>
>
>
> oplock break acknowledgement serves as a request using the SMB2 file id.
> As such there is a race occurring here between when the initial operation
> processes and the result that is returned.   In the case where
> DUPLICATE_OBJECTID is returned, we see the response went out at 54.426658
> and the oplock break ack was received at 54.4279230.   (i.e. oplock ack is
> after failure, and thus the entry was still in the caching table at create
> complete.)   In the case of success we see oplock break ack arrived at
> 20.52079 and create response was sent at 20.52274.  So oplock break ACK
> removed the createGUID value from server’s cache  and hence no
> *STATUS_DUPLICATE_OBJECTID.*
>
>
>
> Note that both REPLAY in the header and the CreateGUID in the create
> context are properties of the 3.x dialect
>
> In a normal usecase scenario for 3.x dialect, the client is expected to
> set *SMB2_FLAGS_REPLAY_OPERATION bit with second create Request.*
>
>
>
>
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> *From:* Sreekanth Nadendla
> *Sent:* Wednesday, November 26, 2014 11:22 AM
> *To:* 'Anubhav Rakshit'
> *Cc:* 'cifs-protocol at samba.org'; MSSolve Case Email
> *Subject:* RE: 114111212024789 Handling
> SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context
>
>
>
> Hello Anubhav, can you tell me if this issue is blocking your
> implementation ? From our attempts to repro, we find that it does not
> reproduce at will and is timing dependent. Can you state if this reproduces
> reliably all the time at your end ? Would you be able to share your setup
> details ?
>
>
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
> *From:* Sreekanth Nadendla
> *Sent:* Wednesday, November 12, 2014 4:52 PM
> *To:* Anubhav Rakshit
> *Cc:* cifs-protocol at samba.org; MSSolve Case Email
> *Subject:* 114111212024789 Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2
> Create Context
>
>
>
> Hello Anubhav,
>
> I am the engineer who will be working with you on this issue. I am
> currently researching the problem and will provide you with an update soon.
> Thank you for your patience.
>
>
>
>
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
>
>
>
>
>
> *From:* Anubhav Rakshit [mailto:anubhav.rakshit at gmail.com
> <anubhav.rakshit at gmail.com>]
> *Sent:* Wednesday, November 12, 2014 12:58 AM
> *To:* Interoperability Documentation Help
> *Cc:* cifs-protocol at samba.org
> *Subject:* Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context
>
>
>
> With reference to MS-SMB2  v20140502 section 3.3.5.9.10 I am trying to
> test the following scenario as mentioned in the specs:
>
> *If an Open is found and the SMB2_FLAGS_REPLAY_OPERATION bit is not set in
> the SMB2 header,*
> *the server MUST fail the request with STATUS_DUPLICATE_OBJECTID. *
>
>
>
> I have two test cases. In one of the test cases, I get the expected
> error STATUS_DUPLICATE_OBJECTID and in the other I get STATUS_SUCCESS.
>
>
>
> Case 1:
>
> 1.    Send SMB2_CREATE request with SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2
> context to server. This call succeeds.
>
> 2.    Re-send the exact same request as above and the server fails the
> request with STATUS_DUPLICATE_OBJECTID. Also the server sends an Oplock
> break notification.
>
> Case 2:
>
> 1.    Send SMB2_CREATE request with SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2
> context to server. This call succeeds.
>
> 2.    Send SMB2_QUERY_INFO on the above File Handle. This call succeeds.
>
> 3.    Re-send the exact same request as 1. We see an Oplock break
> notification triggered. Also the SMB2_CREATE succeeds.
>
> According to the specs SMB2_CREATE in 3. should have failed with
> STATUS_DUPLICATE_OBJECTID. Can you please explain why the server behaves
> differently in this case?
>
>
>
> I am also attaching the Message Analyzer captures for both the cases. For
> Case 1. look at "duplicate_objectid_pass" Frame 3444. For Case 2. look at
> "duplicate_objectid_fail" Frame 45.
>
>
>
> Thanks,
>
> anubhav
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20141204/7e2b6510/attachment.html>