[cifs-protocol] RE: CAR - SMB2 Write and Read in Windows 7
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: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
Re: [cifs-protocol] Re: CAR - SMB2 Write and Read in Windows 7
Hi Neil, 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. Thanks for the update! Would it be possible to get a preview of this document (as we already got in the past). (If it can't be made public, then maybe only post it to the private p...@tridgell.net list and to me directly.) metze -Original Message- From: cifs-protocol-bounces+neilm=thetestplace.co...@cifs.org [mailto:cifs-protocol-bounces+neilm=thetestplace.co...@cifs.org] On Behalf Of Stefan (metze) Metzmacher Sent: Wednesday, July 08, 2009 9:22 AM To: Edgar Olougouna Cc: p...@tridgell.net; cifs-proto...@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: 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 (0x0001). - 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
[cifs-protocol] RE: CAR - SMB2 Write and Read in Windows 7
Hi Stefan, 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. Best regards, Edgar A. Olougouna Sr. SEE, Microsoft DSC Protocol Team 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 (0x0001). - 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 (0x0010). - 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 (0x0010). - 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
[cifs-protocol] RE: CAR - SMB2 Write and Read in Windows 7
Hello Stefan, Thank you for your question regarding SMB2. I will have one of my colleagues get back to you so that we can start working on this. Thanks John Dunning Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM Email: john...@microsoft.com Tele: (469)775-7008 -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Monday, July 06, 2009 3:45 AM To: Interoperability Documentation Help Cc: p...@tridgell.net; cifs-proto...@samba.org Subject: CAR - SMB2 Write and Read in Windows 7 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 (0x0001). - 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 (0x0010). - 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 (0x0010). - 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 (0x0010). - 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) ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
