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

[Edgar Olougouna]

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)