[cifs-protocol] CAR - SMB2 Write and Read in Windows 7
Stefan (metze) Metzmacher
metze at samba.org
Wed Jul 15 05:01:43 MDT 2009
Hi Edgar,
> 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/.
Thanks, I understand how it's supposed to work now.
metze
> 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)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20090715/375c3599/attachment.pgp>
More information about the cifs-protocol
mailing list