I found something interesting in the smbclient
interaction with the MacOSX server if we're set
to SMB2-only (reported by a vendor).

To reproduce, set:

        client min protocol = SMB2
        client max protocol = SMB3

in the [global] section of your smb.conf
and try and use smbclient to connect to
the latest MacOSX server.

We fail to connect (to at least one version
of the MacOSX server) as we ask for zero
credits initially in this case, and the Mac server
replies with zero credits, not one credit as
a Windows server does.

It turns out that Windows clients behave
differently in the SMB2 Negprot depending
on how they first connect to a server.

In a pure Windows to windows environment,
if a Windows client first attempts an
SMB1 Negprot, including a dialect list
of SMB2, and the server replies with
an SMB2 Negprot reply granting one
initial credit.

The client then sends a subsequent SMB2
Negprot, requesting zero credits, and
the server again replies with one credit.
The conversation then continues.

However - if a Windows client *knows*
it's talking to an SMB2-enabled server,
it skips the initial SMB1 negprot, and
sends an SMB2 negprot request instead.

In that SMB2-initial Negprot it asks
for 31 initial credits, not zero. The
server replies with one credit and the
conversation continues happily..

Our client code behaves exactly as
the Windows client does in the case
where we begin with an SMB1 Negprot.

However - if the client min and max
protocol settings are set as above,
then we send an initial SMB2 negprot request
instead, and in that case we behave
*differently* to the Windows client,
in that we send an initial credit
request of zero, not 31.

A Windows server on receiving this
just replies with one credit, and
we're happy. However the Mac server
tested by the OEM replies with zero
credits (that's what we asked for,
right !) and then we fail to connect.