[cifs-protocol] [EXTERNAL] Re: Clarification on expected behavior with SMB2 short reads/writes. [120051422002815]

[Obaid Farooqi]

Hi Jeremy:
I have filed a bug against MS-SMB2 to document the behavior of Windows for this scenario.

Please let me know if it does not answer your question.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Jeremy Allison <jra at samba.org> 
Sent: Tuesday, May 26, 2020 4:21 PM
To: Obaid Farooqi <obaidf at microsoft.com>
Cc: cifs-protocol <cifs-protocol at lists.samba.org>; Stefan Metzmacher <metze at samba.org>; Bradley Suinn <suinn at apple.com>; Steve French <smfrench at gmail.com>; support <support at mail.support.microsoft.com>; jra at samba.org
Subject: [EXTERNAL] Re: Clarification on expected behavior with SMB2 short reads/writes. [120051422002815]

On Thu, May 21, 2020 at 07:12:08PM +0000, Obaid Farooqi wrote:
> Hi Jeremy:
> When you conducted this experiment, what tool on the Windows client you used? 
> Also please upload the wireshark trace to the following link:
> 
> File Transfer - Case 120051422002815
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> I1NiJ9.eyJ3c2lkIjoiZjk5NGVkMjEtOGRjMS00Yjc5LTlkMmMtZTgyYTQ5NjU0ZTMzIiw
> ic3IiOiIxMjAwNTE0MjIwMDI4MTUiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1iY
> zUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6ImY
> 2Y2ZmNjgwLTdkNmItNGZmNC1iY2I4LTBkODlkZmFmNWVlYiIsImlzcyI6Imh0dHBzOi8vY
> XBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4cCI
> 6MTU5Nzg2Mzk2OSwibmJmIjoxNTkwMDg3OTY5fQ.TCJb-9xWE1RZrXp1GDSp1Unx7yHMhz
> J2wRb5GgLQo5EOWIofcdIIKOB4LpOaRHPtcjtJd96_OXfx_WRwLW-o0s3XMWYZ9RReQF2R
> sJQX8EhNXRhwBPsfUXcAKaIl3wS7hHWDdITCSLLzSs2b0vLSVeMe99oM4xEhS6PL95lkKD
> Qp0p0WJOavfmGALp2P9TDKUAt4Frr28kYeRApGqnUW92udk2cM0s9aySc9UkMGmqPiNHQh
> IxowOGSXvyxu7M6KgTbur62dPriya3w85-d9AILwq_o63xv8xieNQqO6VEdODx9NHrIauU
> ZO9KyaSzEJjlbszoktVdwyEe-ne1MFpA%26wid%3Df994ed21-8dc1-4b79-9d2c-e82a4
> 9654e33&data=02%7C01%7Cobaidf%40microsoft.com%7Ce5bb71f17725444eda
> f308d801bac70c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372612490
> 10493638&sdata=0ZEEvKPvMg2XWlzT16lxwig9c2CzEzIVpJiVQdv4tZE%3D&
> reserved=0
> 
> 
> username: 120051422002815_noemail at dtmxfer.onmicrosoft.com
> Password: G[+3G99l

OK. The files are there.

win10short-read.pcapng is the wireshark trace of copying the file: aaa.txt (a file consisting of 10MB of the letter 'A'). badfile.txt is what I ended up with on the Windows10 client after deliberately returning a short read on one of the read requests.

$ md5sum aaa.txt
cfc7616fa5ff7bcdd7e3c1a07ae89b7f  aaa.txt

$ md5sum badfile.txt
d2178e7afdd1ee1a170abd46a2696dc0  badfile.txt

Looking at the wireshark trace you can see the read request at packet 44 - requesting a read of 32768 bytes at offset 0, and my deliberately short reply (-2 bytes) at packet 68 - I return 32766 bytes.

The Windows client never goes back for those 2 bytes.

Let me know if you need more info !

To reproduce, add the following patch to any recent Samba.

diff --git a/source3/smbd/smb2_read.c b/source3/smbd/smb2_read.c index 3441ac27c0c..f59d3ebcbb9 100644
--- a/source3/smbd/smb2_read.c
+++ b/source3/smbd/smb2_read.c
@@ -419,6 +419,10 @@ NTSTATUS smb2_read_complete(struct tevent_req *req, ssize_t nread, int err)
                (unsigned long)state->in_offset,
                (unsigned long)nread));
 
+       if (state->in_offset == 0 && nread > 2) {
+               nread -= 2;
+       }
+
        state->out_data.length = nread;
        state->out_remaining = 0;

and then copy a file.

Cheers,

	Jeremy.