Re: CAR - SMB2 Write and Read in Windows 7

> 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.

> ________________________________________
> From: Edgar Olougouna
> Sent: Monday, July 06, 2009 11:08 AM
> To: Stefan (metze) Metzmacher
> Cc: pfif@...; cifs-protocol@...
> 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)