Bug 15112 - Samba missing a Lease Break when a write occurs and Read/Handle lease is granted
Summary: Samba missing a Lease Break when a write occurs and Read/Handle lease is granted
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.13.4
Hardware: All Other
: P5 major (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-01 20:43 UTC by suinn
Modified: 2022-08-18 16:17 UTC (History)
2 users (show)

See Also:


Attachments
Packet traces showing Samba Failure and Windows Server working (41.02 KB, application/zip)
2022-07-01 20:43 UTC, suinn
no flags Details
smbdDebugLogAndPackets (393.67 KB, application/zip)
2022-07-05 23:09 UTC, suinn
no flags Details
Samba log and packet trace (446.28 KB, application/zip)
2022-07-21 15:16 UTC, suinn
no flags Details
QNAP script that enables/disables the Samba logging (2.78 KB, application/x-sh)
2022-07-21 15:18 UTC, suinn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description suinn 2022-07-01 20:43:34 UTC
Created attachment 17405 [details]
Packet traces showing Samba Failure and Windows Server working

Configuration:
QNAP TVS-h1288X (QuTS hero)
Firmware: h5.0.0.1892
smbd (samba daemon) Version 4.13.14

Steps to Reproduce:
1. First SMB Client logs into the server
2. Second SMB Client logs into the server
3. First client Creates test dirs and test file of PR_blah/PT_0000000000/testfile and writes initial data into the file.  A Read/Write/Handle lease is requested and granted.
4. Second client attempts to open the same file
5. Lease Break Notification is sent by server changing lease from RWH to Read/Handle
6. Second client opens test file and does read of initial data
7. First Client does a write on the file

Expected Results:
The write should generate a lease break from RH to none to the second client.

Actual Results:
Samba server does not send out any lease break to second client. This is incorrect according to [MS-SMB2] 3.3.14 which states that the server must Read caching if data is written to the file.

I have attached a packet trace showing the incorrect behavior from Samba (Write attempt at 202) and the correct behavior from Windows (Write attempt at 206).
Comment 1 Jeremy Allison 2022-07-01 21:16:43 UTC
Can you upload a debug level 10 log from the smbd processes as well ? We should see a debug message from contend_level2_oplocks_begin_default() in the smbd that receives the write that looks like:

                DEBUG(10, ("Breaking through lease key %"PRIu64"/%"PRIu64"\n",
                           state.lease_key.data[0],
                           state.lease_key.data[1]));
Comment 2 suinn 2022-07-05 23:09:05 UTC
Created attachment 17408 [details]
smbdDebugLogAndPackets
Comment 3 Jeremy Allison 2022-07-19 01:10:35 UTC
(In reply to suinn from comment #2)

Yeah, same problem. log.smbd doesn't match the packet traces :-(.
Comment 4 suinn 2022-07-21 15:16:14 UTC
Created attachment 17438 [details]
Samba log and packet trace
Comment 5 suinn 2022-07-21 15:18:31 UTC
Created attachment 17439 [details]
QNAP script that enables/disables the Samba logging

I run it with "samba_log.sh redirect"
Run my test, then wait a min or so, then run
"samba_log.sh default"

Then copy the logs out of Public/log.*
Comment 6 Jeremy Allison 2022-08-17 17:08:23 UTC
Could this be the same as:

https://bugzilla.samba.org/show_bug.cgi?id=15148

Looks like it to me.
Comment 7 Stefan Metzmacher 2022-08-17 18:31:54 UTC
(In reply to Jeremy Allison from comment #6)

Yes, likely.

I have a test and patches almost ready, I'll check the logs here tomorrow
and may close my report...

This is the wip fix:
https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=7bc7eb97157ac6c76307d21ee3e24ea8bbe351e4
within https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master-fileid
Comment 8 Stefan Metzmacher 2022-08-18 10:04:00 UTC
(In reply to Stefan Metzmacher from comment #7)

This is not the same as bug #15148
Comment 9 Stefan Metzmacher 2022-08-18 16:17:02 UTC
(In reply to Stefan Metzmacher from comment #8)

This test seems to demonstrate that upstream doesn't have any problem:

https://gitlab.com/samba-team/devel/samba/-/commit/1515746ff5469f9f120178a34aed1256b171e915

Here's a pipeline running with it:
https://gitlab.com/samba-team/devel/samba/-/pipelines/617051742

I tested in by hand like this:

TDB_NO_FSYNC=1 make -j test _FAIL_IMMEDIATELY=1 SOCKET_WRAPPER_KEEP_PCAP=1 TESTS='smb2.lease'

The test also applies to v4-13-test and also passes there...

Jeremy I mainly based the test on SambaLeaseBreak.pcapng

See wireshark st/w/pcap/samba3_smb2_lease_nt4_dc_.pcap after running
the above...

Jeremy do you see any difference?

Would the test (something like):

bin/smbtorture //server/share -U'DOMAIN\user' smb2.lease.v2_bug15112

also reproduce it against that server?

Currently I'd assume it a QNAP problem...