[cifs-protocol] OpLock break on a compound request causes W2K08 to issue RST in one case but not another

[Richard Sharpe]

Hi folks,

I was recently investigating Samba's handling of OpLock breaks during
SMB2 compound requests and noted this curious anomaly with respect to
W2K08.

I wrote a small smbtorture test case and ran it against W2K08 to
establish what should happen. Samba was failing the test and I have
suggested a fix for that.

However, I got my test case slightly different to what was in the
customer-derived capture that got me looking at this.

Attached are two packet captures that show the difference.

In one, w2k08-compound-break-success-1.pcap, the correct behavior
seems to occur. We see a STATUS_PENDING response from W2K08 and then
the OpLock break sequence.

In the second case, w2k08-compound-break-reset-2.pcap we see the
STATUS_PENDING issued, and then we see a RST from the W2K08 system.

The only difference seems to be that in the successful case I used
OPEN_EXISTING (Disposition OPEN) while in the case that fails, I used
OPEN_ALWAYS (OPEN_IF).

Can anyone comment on this? I haven't checked W2K12 yet to see how it behaves.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w2k08-compound-break-success-1.pcap
Type: application/octet-stream
Size: 4619 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20130315/baafe6ef/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w2k08-compound-break-reset-2.pcap
Type: application/octet-stream
Size: 4163 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20130315/baafe6ef/attachment-0001.obj>