[cifs-protocol] RE: CAR - SMB2 Write and Read in Windows 7
Edgar Olougouna
edgaro at microsoft.com
Mon Jul 6 10:08:37 MDT 2009
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)
More information about the cifs-protocol
mailing list