SMB2 in smbtorture
Christian M Ambach
christian.ambach at de.ibm.com
Wed Feb 16 06:54:55 MST 2011
with Samba 3.6 coming nearer, I thought it would be useful to check if
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
regularly to identify regressions.
I was happy to see that there are already various tests available and I
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
smbtorture will open a connection on 139 and on that connection, Windows
refuse NegProt with SMB2 in the dialect list.
This leads to spurious errors in all smb2 tests during the connection
This can be circumvented with the -p 445 parameter, but maybe it makes
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
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
boxes announce a Maximum Write Size of 1MB in the NegProt Response, they
reject attempts to write more than 64KB of data.
Changing the size of the writes requested by this test to 64KB made it
Watching Windows<->Windows communication I was also not able to see
larger than 64KB being sent, even if the application presents a larger
argument to a ReadFile call.
So this seems to be inconsistent Windows behaviour, as MS-SMB2 says that
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?
Fails against Win2008R2 and Win7 with a similar reason as smb2.connect: it
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
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
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
ones that pass against Windows soon?
Looking at the SMB2 testcases, some of them seem to be adjusted copies of
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
SMB2-specific testcases as smb2.* testcases in smbtorture? Specifying -m
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?
More information about the samba-technical