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

Fri Jul 10 08:34:34 MDT 2009

Hi Stefan,

I have completed investigation on your request. Please find the answers below.

1.      SMB2-CONNECT-w7rc-smb2.002.writesize-01.pcap:

The scenario you described relates to SMB 2.002 clients issuing overly large writes. The Product Team confirmed a bug in the Windows 7 implementation regarding the return code STATUS_BUFFER_OVERFLOW instead of STATUS_INVALID_PARAMETER as documented in [MS-SMB2] 3.3.5.13.  The fix is planned to be available in SP1. This issue is minor and we may not provide a patch prior to that, since it requires a client to send an invalid request, thus not following the protocol.
There will be a Windows behavior note similar to this (not exactly this wording):
<WB> The STATUS_BUFFER_OVERFLOW is returned for read/write exceeding max read/write size since Vista and we will correct it in Windows 7 SP1.

2.      SMB2-CONNECT-w7rc-smb2.002.writesize-strange-02.pcap:

Based on the clarification provided by the new network trace I requested (SMB2-CONNECT-w7rc-smb2.002.writesize-not-strange-03.pcap), we came to the conclusion and agreement to rule out the truncation claim of your original request. The behavior in the new trace is consistent and expected.

3.      SMB2-CONNECT-w7rc-smb2.100.writesize-01.pcap:

This scenario relates to SMB 2.1 clients issuing writes with MaxWriteSize over 64KB.
The behavior you experienced is expected per multi-credit (large MTU) operations, a new capability introduced with SMB 2.1 dialect. The CreditCharge for a request is used for requests larger than 64 KB, and the credits consumed is equal to the (RequestLength rounded up to 64k boundary) / 64k.  For instance, a 65 KB request would require 2 credits, etc. Supplying insufficient credits will cause the operation (by design) to fail with INVALID_PARAMETER since the request is mal-formed.

In the near future, an RTM release of the MS-SMB2 document that specifies SMB2.1 multi-credit (large MTU) operations will be available. In the interim, the following resources provide relevant information on the topic:
*       Blog post: "SMB 2.1 Multi-Credit (Large MTU) Operations" http://blogs.msdn.com/openspecification/archive/2009/06/22/smb-2-1-multi-credit-large-mtu-operations.aspx
*       Channel9 presentation: "Server Message Block (SMB2.1) Drill-down" http://channel9.msdn.com/posts/Darryl/Server-Message-Block-SMB21-Drill-down/
You may also receive information concerning document update postings by subscribing to the "e-Newsletter - Microsoft Open Protocols" at http://www.microsoft.com/protocols/e-newsletter/.

Best regards,
Edgar A. Olougouna
Sr. SEE, Microsoft DSC Protocol Team

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Wednesday, July 08, 2009 3:22 AM
To: Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: 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)