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:me...@samba.org] > Sent: Wednesday, July 08, 2009 3:22 AM > To: Edgar Olougouna > Cc: p...@tridgell.net; cifs-proto...@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: p...@tridgell.net; cifs-proto...@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) >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol