Converting SMB1 tests to SMB2

Ralph Boehme slow at
Fri Oct 18 17:10:54 UTC 2019

On 10/18/19 6:12 PM, npower wrote:
> Hi Ralph,
> On 18/10/2019 13:00, Ralph Boehme wrote:
>> Hi Noel,
>> On 10/17/19 10:14 PM, Noel Power wrote:
>>> So as a first step I tried (via brute force) e.g. changing the min
>>> protocol definitions in the generated conf files for the test
>>> environments, running the tests and seeing what was failing. I then
>>> disabled (and/or) deleted tests to get to a point where all running
>>> tests pass with 'min protocol = SMB2_02'. The intention here was to
>>> enumerate the tests involve
>> I guess I would put all failing tests into selftest/knownfail.d/smb1
> I initially thought about doing this but ran into problems (see below)
>> I'd try to generate the list with
>> <;a=commitdiff;h=0fa5ae9d30546e46a5db9ecf7936768f69a1e957>
>> then running on sn-devel.
>> Then with grep UNEXPECTED *.stdout you get a first (but incomplete) list:
>> <;a=commitdiff;h=4e2788f7d494b6e402784d217f37c08b985f3d7a>
>> I noticed a crash in smbtorture is triggered by a test, so there's
>> likely some iterations needed to manually filter out tests that induce
>> crashes.
> not only crashes but also hangs. There seems to be a whole pile of tests
> that hang (with the min protocol changes I did) this and the crashes
> kindof put me off trying to use a knownfail (because the for that to
> work you need the tests to run and complete)  So for the problematic
> tests you are left then with the choice of removing them from set of
> running tests (I really don't like that) or fix the hangs and crashes
> which are more than likely happening in SMB1 tests we will throw away :/

well, I guess we need an initial list of all those tests in
selftest/skip-smb1 and  something like this

env.OPTIONS += " --mitkrb5 --exclude=${srcdir}/selftest/skip-smb1"

in selftest/wscript.

And then figure we have to figure out why they crash or hang. Once we
know that, we can fix or remove the test.

> However if we just want to generate a list well I'd say I probably can
> do better than I did maybe using in
> combination with/without the changes I already have.

I think we need a complete list *before* doing any changes.

>>> So, if anyone can immediately identify say any tests we can just delete
>>> or port from the attached list of test diffs, that would be useful :-)
>>> Could save us some time digging.
>> I guess one of the first things I'd look as is all the torture tests
>> that run against both nt4_dc and ad_dc. I guess for most it's ok to just
>> run them against either one.
> not sure I get what you mean here, what is the significance of tests
> that run against these environments (I realise this is probably
> obvious... but not to me :-))))

I guess that's just historical practice. Look at s3/selftest/,
the final else for the block that sets up the smbtorture test is

    plansmbtorture4testsuite(t, "nt4_dc", '//$SERVER_IP/tmp \
    plansmbtorture4testsuite(t, "ad_dc", '//$SERVER/tmp \

For most tests this is not needed and it bloats your list of failing tests.

>> Everything else probably has to be assessed one by one.
>> Note that tests ported from smb1 to smb2 must also pass against Windows.
>> Fwiw, once you get to the base.delaywrite tests be warned, that Windows
>> behaviour is different between Windows 2003 (which is what Samba
>> implements) and Windows 2008 or newer. It's also different between SMB1
>> and 2, see
> I'm afraid to look, sounds awful

Just remember to come back to me when you start working on this.
Hopefully by then I know what's going on.


Ralph Boehme, Samba Team      
Samba Developer, SerNet GmbH
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

More information about the samba-technical mailing list