SMB2 in smbtorture

Christian M Ambach christian.ambach at
Wed Feb 16 06:54:55 MST 2011

Hi list,

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.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 
buffer as 
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 
unexpected replies.

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.

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?

Future strategy?
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 mailing list