Bug 10966 - Can't connect to a Mac SMB2 server due to credit request bug.
Can't connect to a Mac SMB2 server due to credit request bug.
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: libsmbclient
unspecified
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-26 17:42 UTC by Jeremy Allison
Modified: 2015-07-31 21:09 UTC (History)
2 users (show)

See Also:


Attachments
git-am fix for 4.2.0 - backport from master. (1.93 KB, patch)
2014-11-26 21:18 UTC, Jeremy Allison
slow: review+
Details
git-am fix for 4.1.next - backport from master (1.95 KB, patch)
2014-11-26 21:47 UTC, Jeremy Allison
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Allison 2014-11-26 17:42:59 UTC
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.
Comment 1 Jeremy Allison 2014-11-26 17:43:30 UTC
Fix that went into master to follow once it passes autobuild.
Comment 2 Jeremy Allison 2014-11-26 21:18:46 UTC
Created attachment 10465 [details]
git-am fix for 4.2.0 - backport from master.
Comment 3 Jeremy Allison 2014-11-26 21:47:36 UTC
Created attachment 10466 [details]
git-am fix for 4.1.next - backport from master
Comment 4 Jeremy Allison 2014-12-01 17:35:11 UTC
Reassigning to Karolin for inclusion in 4.2.0, 4.1.next.
Comment 5 Karolin Seeger 2014-12-03 20:15:46 UTC
Pushed to autobuild-v4[1|2]-test.
Comment 6 Karolin Seeger 2014-12-07 19:30:20 UTC
(In reply to Karolin Seeger from comment #5)
Pushed to both branches.
Closing out bug report.

Thanks!