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

Obaid Farooqi obaidf at microsoft.com
Tue May 26 21:38:45 UTC 2020

Hi Jeremy:
I'll look into these and will be in touch as soon as I have an snswer.

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%2Fsupport.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiZjk5NGVkMjEtOGRjMS00Yjc5LTlkMmMtZTgyYTQ5NjU0ZTMzIiwic3IiOiIxMjAwNTE0MjIwMDI4MTUiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1iYzUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6ImY2Y2ZmNjgwLTdkNmItNGZmNC1iY2I4LTBkODlkZmFmNWVlYiIsImlzcyI6Imh0dHBzOi8vYXBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4cCI6MTU5Nzg2Mzk2OSwibmJmIjoxNTkwMDg3OTY5fQ.TCJb-9xWE1RZrXp1GDSp1Unx7yHMhzJ2wRb5GgLQo5EOWIofcdIIKOB4LpOaRHPtcjtJd96_OXfx_WRwLW-o0s3XMWYZ9RReQF2RsJQX8EhNXRhwBPsfUXcAKaIl3wS7hHWDdITCSLLzSs2b0vLSVeMe99oM4xEhS6PL95lkKDQp0p0WJOavfmGALp2P9TDKUAt4Frr28kYeRApGqnUW92udk2cM0s9aySc9UkMGmqPiNHQhIxowOGSXvyxu7M6KgTbur62dPriya3w85-d9AILwq_o63xv8xieNQqO6VEdODx9NHrIauUZO9KyaSzEJjlbszoktVdwyEe-ne1MFpA%26wid%3Df994ed21-8dc1-4b79-9d2c-e82a49654e33&data=02%7C01%7Cobaidf%40microsoft.com%7Ce5bb71f17725444edaf308d801bac70c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261249010493638&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

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.



More information about the cifs-protocol mailing list