[cifs-protocol] [MS-SMB2] 3.3.5.22.1 NT_STATUS_REQUEST_NOT_ACCEPTED?

[Volker Lendecke]

Hi!

While investigating oplocks I wrote a little test leading to
the attached trace, which surprised me a bit.

This test is running against Windows 2012 server.

In frame 56 I get an exclusive oplock.

In frame 57 I try to open the file a second time on a
different connection, asking for an exclusive oplock again,
create disposition as OPEN_IF.

Frame 60 is the expected break response, breaking to level2.
This break response is not replied to immediately.

In frame 63 I try to open the file a third time on a third
connection, asking for an exclusive oplock with create
disposition OVERWRITE_IF. To my understanding this should
trigger a break to none.

In frame 66 I reply to the break response in frame 60,
breaking to what was asked in frame 60: Level2.

Frame 67 is what I find surprising and what I can not find
in the documentation: I get a STATUS_REQUEST_NOT_ACCEPTED.
According to [MS-SMB2], this only is sent in response to a
lease break, not an oplock break.

Although there was a REQUEST_NOT_ACCEPTED, the immediate
reply to the pending opens shows me that some processing
of the break response must have happened, I just don't find
in [MS-SMB2] what exactly happened.

Can you explain the sequence that happens in response to
Frame 66? How does STATUS_REQUEST_NOT_ACCEPTED happen and
how does the server do its further processing? In
particular, what oplock level does the handle that got the
oplock break have after this sequence.

I can easily reproduce and slightly modify the test. If for
example in frame 66 I break to "no oplock", I get a
NT_STATUS_OK in frame 67. But the client that got the break
can't know that frame 63 happened.

Thanks,

Volker Lendecke
PFIF member, Samba Team

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dochelp.cap
Type: application/cap
Size: 13664 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20131022/2232a2ab/attachment.cap>