Samba 4.2 and Microsoft Lease test cases

[Steve French]

I did a run of Microsoft SMB2/SMB3 functional test cases against Samba
4.2 recently and noticed that the BreakReadHandleLeaseV1 cases mostly
fail (TestCases S850, S874, S898, S922, S954, S985, S648 for example)
while most other test cases (except for the Symbolic Link ones) are
fine as are all of the "BVT" category of tests. kernel oplocks are
disabled in smb.conf (in order to enable durable handles and SMB2.1
leases).

I will trace it but see things logged like:

2015-02-10 12:29:26.241 [Comment] executing step 'call
LeaseBreakAcknowledgmentRequest(ValidLeaseKey,1)'
2015-02-10 12:29:26.263 [CheckSucceeded] Assert.AreEqual succeeded.
Expect that the Command is OPLOCK_BREAK.
2015-02-10 12:29:26.265 [Comment] reaching state 'S15'
2015-02-10 12:29:26.265 [Comment] checking step 'return
LeaseBreakAcknowledgmentRequest'
2015-02-10 12:29:26.266 [Comment] reaching state 'S16'
2015-02-10 12:29:26.274 [CheckFailed] Assert.IsTrue failed. expected
matching event, found 'event
LeaseBreakResponse(STATUS_UNSUCCESSFUL,0)'. Diagnosis:
  1. event parameters do not match
    comment: checking step 'event LeaseBreakResponse(STATUS_SUCCESS,1)'
    assert  failed: expected 'STATUS_SUCCESS', actual
'STATUS_UNSUCCESSFUL' (status of LeaseBreakResponse, state S16)
    comment: This step would have covered "[MS-SMB2] The server MUST
locate the lease on which the client is acknowledging a lease break by
performing a lookup in LeaseTable.LeaseList using the LeaseKey of the
request as the lookup key.", "[MS-SMB2] The server MUST set
Lease.LeaseState to LeaseState received in the request, and MUST set
Lease.Breaking to FALSE.", "[MS-SMB2] The server then MUST construct a
lease break response using the syntax specified in section 2.2.25 with
the following values:", "[MS-SMB2] LeaseState MUST be set to
Lease.LeaseState."

Anyone successfully run the Microsoft BreakReadHandleLeaseV1 test
cases against current Samba?  I wanted to rule out misconfiguration
before I dove into debugging this much

-- 
Thanks,

Steve