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

Thu Jul 9 03:40:17 MDT 2009

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
<pfif at tridgell.net> list and to me directly.)

metze

> -----Original Message-----
> From: cifs-protocol-bounces+neilm=thetestplace.co.uk at cifs.org
> [mailto:cifs-protocol-bounces+neilm=thetestplace.co.uk at cifs.org] On Behalf
> Of Stefan (metze) Metzmacher
> Sent: Wednesday, July 08, 2009 9:22 AM
> To: Edgar Olougouna
> Cc: pfif at tridgell.net; cifs-protocol at 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: 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/archive/cifs-protocol/attachments/20090709/a213a9a6/signature.bin