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

[John Dunning]

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: johndun at microsoft.com
Tele: (469)775-7008



-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org] 
Sent: Monday, July 06, 2009 3:45 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at 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 (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)