SMB2 in smbtorture

[Christian M Ambach]

Hi list,

with Samba 3.6 coming nearer, I thought it would be useful to check if 
there
are automated SMB2 tests available in smbtorture that can be run against
Samba 3.6 to see if it behaves like Windows machine do and to run the 
tests
regularly to identify regressions.

I was happy to see that there are already various tests available and I 
gave
each of them a try to see what they will do against Windows machines.

Here are my results:

Intermediate connection problems
================================
If the Windows machine under test does not reply quickly enough on port 
445,
smbtorture will open a connection on 139 and on that connection, Windows 
will
refuse NegProt with SMB2 in the dialect list.
This leads to spurious errors in all smb2 tests during the connection 
phase.

This can be circumvented with the -p 445 parameter, but maybe it makes 
more
sense to automatically limit the port numbers for smb2 connections?

smb2.lock, smb2.getinfo, smb2.setinfo, smb2.streams, smb2.compound,
smb2.lease, smb2.bench-oplock,smb2.acls, smb2.compound
===================================================================
Passing against 2008R2 and Win7

smb2.connect
============
Attempts to send a WRITE request with 120.000 bytes of data.
Windows 2008R2 and Windows 7 reject this with INVALID_PARAMETER.
I have digged further into this and the outcome is that although the 
Windows
boxes announce a Maximum Write Size of 1MB in the NegProt Response, they 
will
reject attempts to write more than 64KB of data.
Changing the size of the writes requested by this test to 64KB made it 
pass.
Watching Windows<->Windows communication I was also not able to see 
requests
larger than 64KB being sent, even if the application presents a larger 
buffer as 
argument to a ReadFile call.
So this seems to be inconsistent Windows behaviour, as MS-SMB2 says that 
the
answer in NegProt indicates the maximum allowed number in WRITE requests.
The product behaviour section also does not list a limitation here.
Does somebody have more details or insight here?

smb2.read
=========
Fails against Win2008R2 and Win7 with a similar reason as smb2.connect: it 
tries
to read 70.000 bytes at once, Windows rejects this with INVALID_PARAMETER.

smb2.create, smb2.notify, smb2.durable-open, smb2.dir
=====================================================
When run against Win2008R2 and Win7, these tests print out some errors 
about
unexpected replies.

smb2.oplock
===========
Occasionally fails against Win7 and 2008R2, thus it is not reliable.

smb2.scan, smb2.scangetinfo, smb2.scansetinfo, smb2.scanfind
============================================================
Seem to be debugging tools to check which opcodes/levels are used and 
which not.

smb2.hold-oplock
================
non-automatic test, not useful for automatic testing.

Samba 3.6 results?
==================
I haven't run any of these tests yet against Samba 3.6, I'll do that for 
the
ones that pass against Windows soon?

Future strategy?
================
Looking at the SMB2 testcases, some of them seem to be adjusted copies of 
SMB1
testcases.
To increase the test coverage, an idea might be to continue copying and
converting testcases. But that does not seem to be a good idea to me.

Wouldn't it be better to enable all original testcases for SMB2 and only 
keep
SMB2-specific testcases as smb2.* testcases in smbtorture? Specifying -m 
smb2
to smbtorture does not seem to have an effect yet.

Is there anybody feeling responsible for the SMB2 testing strategy yet?
Are there tests available that I just overlooked?


Regards,
Christian