This client is not compatible with the server if ONLY minVersion SMB300 or later

[thanh-vn]

We did some testing for combinations of jcifs.smb.client.minVersion and jcifs.smb.client.maxVersion . Looks like there is an issue when there is NO jcifs.smb.client.maxVersion AND jcifs.smb.client.minVersion = SMB300 or SMB302 or SMB311. No problem occurs if both minVersion and maxVersion are set together.

For example, error with the properties below testing to Windows 10

-- listing properties --
jcifs.smb.client.minVersion=SMB302
-- End listing properties --

Error:

2020-04-18 10:54:07 DEBUG SmbTransportPoolImpl:96 - New transport connection Transport1[localhost/127.0.0.1:445,state=0,signingEnforced=false,usage=1]
2020-04-18 10:54:07 DEBUG Transport:568 - Connecting Transport1
2020-04-18 10:54:07 DEBUG SmbTransportImpl:703 - Connecting in state 1 addr 127.0.0.1
2020-04-18 10:54:07 INFO SmbTransportImpl:652 - Response len = 72
2020-04-18 10:54:07 DEBUG SmbTransportImpl:727 - Negotiation response on Transport1 :jcifs.internal.SmbNegotiation@875180fc
2020-04-18 10:54:07 DEBUG Transport:640 - Interrupting transport thread
2020-04-18 10:54:07 DEBUG Transport:642 - Joining transport thread
2020-04-18 10:54:07 DEBUG Transport:644 - Joined transport thread
2020-04-18 10:54:07 DEBUG SmbTransportPoolImpl:261 - Scheduling transport connection for removal Transport1[localhost/127.0.0.1:445,state=4,signingEnforced=false,usage=1] (-2085829664)
2020-04-18 10:54:07 DEBUG SmbTransportPoolImpl:273 - Removing transport connection Transport1[localhost/127.0.0.1:445,state=4,signingEnforced=false,usage=0] (-2085829664)
2020-04-18 10:54:07 DEBUG SmbTransportPoolImpl:96 - New transport connection Transport2[localhost/0:0:0:0:0:0:0:1:445,state=0,signingEnforced=false,usage=1]
2020-04-18 10:54:07 DEBUG Transport:568 - Connecting Transport2
2020-04-18 10:54:07 DEBUG SmbTransportImpl:703 - Connecting in state 1 addr 0:0:0:0:0:0:0:1
2020-04-18 10:54:07 INFO SmbTransportImpl:652 - Response len = 72
2020-04-18 10:54:07 DEBUG SmbTransportImpl:727 - Negotiation response on Transport2 :jcifs.internal.SmbNegotiation@1767ad6f
2020-04-18 10:54:07 DEBUG Transport:640 - Interrupting transport thread
2020-04-18 10:54:07 DEBUG Transport:642 - Joining transport thread
2020-04-18 10:54:07 DEBUG Transport:644 - Joined transport thread
2020-04-18 10:54:07 DEBUG SmbTransportPoolImpl:261 - Scheduling transport connection for removal Transport2[localhost/0:0:0:0:0:0:0:1:445,state=4,signingEnforced=false,usage=1] (-355287509)
2020-04-18 10:54:07 DEBUG SmbTreeConnection:587 - Referral failed, trying next
jcifs.smb.SmbException: Failed to connect: localhost/0:0:0:0:0:0:0:1
at jcifs.smb.SmbTransportImpl.ensureConnected(SmbTransportImpl.java:691)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:217)
at jcifs.smb.SmbTransportPoolImpl.getSmbTransport(SmbTransportPoolImpl.java:48)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:571)
at jcifs.smb.SmbTreeConnection.connectHost(SmbTreeConnection.java:495)
at jcifs.smb.SmbTreeConnection.connect(SmbTreeConnection.java:471)
at jcifs.smb.SmbTreeConnection.connectWrapException(SmbTreeConnection.java:432)
at jcifs.smb.SmbFile.ensureTreeConnected(SmbFile.java:589)
at jcifs.smb.SmbFile.exists(SmbFile.java:883)
at Test_readDir.main(Test_readDir.java:91)
Caused by: jcifs.util.transport.TransportException: jcifs.smb.SmbException: This client is not compatible with the server.
at jcifs.util.transport.Transport.run(Transport.java:759)
at java.lang.Thread.run(Thread.java:785)
Caused by: jcifs.smb.SmbException: This client is not compatible with the server.
at jcifs.smb.SmbTransportImpl.doConnect(SmbTransportImpl.java:731)
at jcifs.util.transport.Transport.run(Transport.java:732)
... 1 more

Thanks for your help!
tvn

[mbechler]

Can provide a packet capture of the initial nagotiation? The only code paths I can find that would result in this errror without an additional message, is when there is something wrong with the encryption/integrity negotation contexts.

[dbreslau]

When jcifs.smb.client.maxVersion is left unset (as in the OP), then BaseConfiguration.maxVersion defaults to SMB210 (see BaseConfiguration.initProtocolVersions(DialectVersion, DialectVersion) at around line 750.)

So if the caller sets jcifs.smb.client.minVersion to SMB300 (or higher) and leaves jcifs.smb.client.maxVersion unset, then the client supports no SMB protocol versions! This is reflected in the SMB2 Negotiate request, in which the Dialect array is empty. The server responds to this request with STATUS_INVALID_PARAMETER.

I've attached three packet traces in the file jcifs-ng-issue-216-dbreslau.zip:

SMBFailedMin311Max210 has jcifs.smb.client.maxVersion set explicitly to 210, while jcifs.smb.client.minVersion is set to 311. This is obviously invalid, and (as above) results in an empty dialects array in the SMB2 Negotiate request; the server responds with STATUS_INVALID_PARAMETER.

SMBFailedMin300NoMax sets the minVersion to 300, while the maxVersion is left unset (as in the OP). This has the same result: An empty dialects array, and a STATUS_INVALID_PARAMETER.

jcifs-ng-issue-216-dbreslau.zip

In SMBSuccessMin300Max311, I set minVersion to 300 and maxVersion to 311. This resulted in a successful connection request.

[dbreslau]

Not to derail this thread, but I think that defaulting maxVersion to 210 also explains why I found I had to explicitly set maxVersion to 300 or higher before I saw any effect from setting jcifs.smb.client.encryptionEnabled to "true" . (Of course, this ultimately still had no effect, since jcifs-ng doesn't currently support encryption -- correct me if I'm wrong there!)

A somewhat future-proof way to set the default for maxVersion would be:

this.maxVersion = max != null ? max : DialectVersion.values()[DialectVersion.values().length - 1];

which would work so long as newer protocol versions are always added at the end of the DialectVersion enum definition.

[thanh-vn]

Thanks @dbreslau for the investigation.
I think having the maxVersion at least equals the minVersion if no jcifs.smb.client.maxVersion is also an option.

This would also resolve issue when people making mistake of setting jcifs.smb.client.minVersion > jcifs.smb.client.maxVersion, such as:

jcifs.smb.client.minVersion=SMB311
jcifs.smb.client.maxVersion=SMB302

[mbechler]

Good catch.
The original intention was to leave SMB3 disabled by default until the next major release, so I guess the safe "minor version" fix for this is to set the maxVersion to at least the minVersion.

[thanh-vn]

Thanks, the fix works.