[cifs-protocol] Re: CAR - SMB2 Write and Read in Windows 7

[Neil B Martin (MountD)]

Metze

There are still a bunch of people working on getting good answers to you.
But in brief the over 64K writes when SMB 2.1 is negotiated uses a feature
called multi-credit. An updated MS-SMB2 document is to be published next
week on MSDN (that was scheduled before your issue was raised) that
describes 
that feature. 

So without jumping the gun too much, one thing is clear. The way torture
works for over 64K writes with SMB2.1 dialect needs to be tweaked as that is
a condition where multi-credits apply. There may still be issues with the
way Windows 7 behaves - that is one of the thing that is being checked.

Neil

(neilm at thetestplace.co.uk)
(Neil.Martin at microsoft.com)



-----Original Message-----
From: cifs-protocol-bounces+neilm=thetestplace.co.uk at cifs.org
[mailto:cifs-protocol-bounces+neilm=thetestplace.co.uk at cifs.org] On Behalf
Of Stefan (metze) Metzmacher
Sent: Wednesday, July 08, 2009 9:22 AM
To: Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: [cifs-protocol] Re: CAR - SMB2 Write and Read in Windows 7

Hi Edgar,

> While investigating your inquiry, we would like to request more data to
help fully scope the issues.
> We believe we correctly understand the issues you reported in two of the
three network traces:
> - SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap
> - SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap
> 
> Regarding the SMB 2.002 Write scenario exhibited in the network trace
SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap:
> Frame 26 and Frame 28 indicate a file size of 65536 when it is opened, and
this does not suffice to prove or conclude that the write with the invalid
length 65537 did the truncation write.
> Allocation Size: 65536
> End Of File: 65536
> 
> To help clarify this, we need another trace of a slightly different
testing of this scenario:
> - First, issue a success write (say write length 65536),
> - Second (following the success write), issue an invalid write (say write
length 65537 with offset 65536) to see whether the file length becomes
131072 after the second write fails.

You're right, the tests missed to delete the file at startup, so that the
behavior of the test is consistent.

The attached capture isn't so strange anymore, the GetInfo after the write
reports allocation size and end of file as 0.

And the read gets NT_STATUS_END_OF_FILE. So it's just the different error
code.

metze

> ________________________________________
> From: Edgar Olougouna
> Sent: Monday, July 06, 2009 11:08 AM
> To: Stefan (metze) Metzmacher
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: CAR - SMB2 Write and Read in Windows 7
> 
> Hi Stefan,
> 
> I have taken ownership of this case and will be working with you for its
resolution.
> 
> Best regards,
> 
> Edgar A. Olougouna
> Sr. SEE, Microsoft DSC Protocol Team
> 
> Hi,
> 
> I'm working on SMB2 support for Samba and noticed a strange behavior
regarding the maximum read and write sizes in SMB2.
> 
> Section "3.3.5.13 Receiving an SMB2 WRITE Request" says the server must
return STATUS_INVALID_PARAMETER if the length isn't in the configured range
(which is reported to the client in the NEGOTIATE response).
> 
> The same applies to SMB2 Read requests.
> 
> However a Windows 7 server doesn't behave like this.
> (I tested this with Windows 7 RC Build 7100).
> 
> I've attached 3 network captures to this mail, which demonstrate the wrong
behavior.
> 
> SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap:
> 
> - We run our SMB2-CONNECT torture test like this:
>   bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \
>        SMB2-CONNECT --option=torture:smb2maxwrite=65537
>   (I manually excluded the SMB 2.100 dialect in our code)
> 
> - In Frame 5 SMB 2.002 is negotiated and the server returns MaxReadSize
>   and MaxWriteSize as 65536 (0x00010000).
> 
> - The Frames 17-71 (wireshark reassembles them in Frame 71) there's a
>   SMB2 Write request with length 65537 (0x00010001).
> 
> - And the SMB2 Write response in Frame 72 returns STATUS_BUFFER_OVERFLOW
>   instead of STATUS_INVALID_PARAMETER. (Then our test closes the tcp
>   connection)
> 
> - Now we run our SMB2-CONNECT torture test like this:
>   bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \
>        SMB2-CONNECT --option=torture:smb2maxwrite=65536
> 
> - The SMB2 Write response in Frame 147 returns STATUS_OK, which is
>   correct.
> 
> - Also the SMB2 Read response (reassembled) in Frame 285, gets
>   STATUS_OK.
> 
> SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap:
> 
> - Here I manually modified the write/read sizes in the SMB2-CONNECT
>   torture test and ignored any errors.
>   So that we write 65537 bytes and read 65536 bytes.
>   (I also manually excluded the SMB 2.100 dialect in our code)
> 
> - The SMB2 Write request (reassembled in Frame 142) writes 65537
>   bytes and gets STATUS_BUFFER_OVERFLOW.
> 
> - The SMB2 GetInfo response in Frame 146 returns the allocation size
>   and end of file both as 65536, which indicates that the SMB2 Write
>   was just truncated to 65536.
> 
> - The SMB2 Read request in Frame 155 asks for the first 65536 bytes of
>   the file.
> 
> - The SMB2 Read response (reassembled) in Frame 223 proves that the
>   truncated Write as it returns the exactly same bytes, which were
>   written before.
> 
> SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap:
> 
> - The behavior in SMB 2.100 mode is even more strange...
> 
> - We run our SMB2-CONNECT torture test like this:
>   bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \
>        SMB2-CONNECT --option=torture:smb2maxwrite=1048576
> 
> - In Frame 9 SMB 2.100 is negotiated and the server returns MaxReadSize
>   and MaxWriteSize as 1048576 (0x00100000).
> 
> - We try a SMB2 Write with length 1048576 (reassembled) in Frame 784,
>   but get STATUS_INVALID_PARAMETER in Frame 787. (Our test closes the
>   connection at this point.
> 
> - We run our SMB2-CONNECT torture test like this:
>   bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \
>        SMB2-CONNECT --option=torture:smb2maxwrite=1048576
> 
> - In Frame 795 SMB 2.100 is negotiated and the server returns
>   MaxReadSize and MaxWriteSize as 1048576 (0x00100000).
> 
> - We try a SMB2 Write with length 65537 (reassembled) in Frame 859,
>   but get STATUS_INVALID_PARAMETER in Frame 861. (Our test closes the
>   connection at this point.
> 
> - We run our SMB2-CONNECT torture test like this:
>   bin/smbtorture -Utest%test -p 445 //172.31.9.212/torture \
>        SMB2-CONNECT --option=torture:smb2maxwrite=65536
> 
> - In Frame 869 SMB 2.100 is negotiated and the server returns
>   MaxReadSize and MaxWriteSize as 1048576 (0x00100000).
> 
> - We try a SMB2 Write with length 65536 (reassembled) in Frame 933.
> 
> - The SMB2 Write response in Frame 935 returns STATUS_OK, which is
>   correct.
> 
> - Also the SMB2 Read response (reassembled) in Frame 1073, gets
>   STATUS_OK.
> 
> The major problem is that a client in SMB 2.100 mode can't rely on the
values returned in the NEGOTIATE response. I think it would be very, very
good if this could be fixed in the final version of Windows 7!
> 
> metze
> (Samba Team and PFIF member)