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

[Obaid Farooqi]

Hi Jeremy:
Windows redirector neither dictates the number of bytes read nor it checks for returned bytes. It is not a bug on redirector. Redirector's behavior is clearly documented in the MS-SMB2.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

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

And related to this whether to add mention of the "SHOULD" behavior (don't ignore short reads) ie what Linux and smbclient does (ie read the remaining missing data).

On Tue, Jun 2, 2020 at 12:53 PM Obaid Farooqi <obaidf at microsoft.com> wrote:
>
>
> 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://supp 
> > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJS
> > Uz 
> > I1NiJ9.eyJ3c2lkIjoiZjk5NGVkMjEtOGRjMS00Yjc5LTlkMmMtZTgyYTQ5NjU0ZTMzI
> > iw 
> > ic3IiOiIxMjAwNTE0MjIwMDI4MTUiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1
> > iY 
> > zUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6I
> > mY 
> > 2Y2ZmNjgwLTdkNmItNGZmNC1iY2I4LTBkODlkZmFmNWVlYiIsImlzcyI6Imh0dHBzOi8
> > vY 
> > XBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4c
> > CI 
> > 6MTU5Nzg2Mzk2OSwibmJmIjoxNTkwMDg3OTY5fQ.TCJb-9xWE1RZrXp1GDSp1Unx7yHM
> > hz 
> > J2wRb5GgLQo5EOWIofcdIIKOB4LpOaRHPtcjtJd96_OXfx_WRwLW-o0s3XMWYZ9RReQF
> > 2R 
> > sJQX8EhNXRhwBPsfUXcAKaIl3wS7hHWDdITCSLLzSs2b0vLSVeMe99oM4xEhS6PL95lk
> > KD 
> > Qp0p0WJOavfmGALp2P9TDKUAt4Frr28kYeRApGqnUW92udk2cM0s9aySc9UkMGmqPiNH
> > Qh 
> > IxowOGSXvyxu7M6KgTbur62dPriya3w85-d9AILwq_o63xv8xieNQqO6VEdODx9NHrIa
> > uU
> > ZO9KyaSzEJjlbszoktVdwyEe-ne1MFpA%26wid%3Df994ed21-8dc1-4b79-9d2c-e82
> > a4 
> > 9654e33&data=02%7C01%7Cobaidf%40microsoft.com%7Ce5bb71f17725444e
> > da
> > f308d801bac70c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63726124
> > 90 
> > 10493638&sdata=0ZEEvKPvMg2XWlzT16lxwig9c2CzEzIVpJiVQdv4tZE%3D&am
> > p;
> > 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.



--
Thanks,

Steve