Allow Multiple SMB Dialects

[ahm3dgg]

Sticking to SMB 2.1.0 causes SMB Negotiate to fail on old windows server versions, the smb2 package allows for more if not specified

type Negotiator struct {
        // ....
	SpecifiedDialect      uint16   // if it's zero, clientDialects is used. (See feature.go for more details)
}

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[psycep]

Thanks for the PR. The rationale makes sense. Pinning to a single dialect (0x0210) breaks negotiation against anything that doesn't speak exactly SMB 2.1.0, so letting the negotiator fall back to the full clientDialects set is the right direction.

Before merging I want to verify the code paths this newly activates. Today everything on pkg/smb always runs 2.1.0, so the SMB 3.x signing and encryption paths have never actually executed in practice. After this change, modern Windows will negotiate 3.1.1, and since we keep RequireMessageSigning: true, the 3.1.1 AES-CMAC signing path (pre-auth-integrity keyed) will run on every connection. Encryption-required shares also become reachable for the first time. That all looks implemented in session.go, but it's a big behavioral surface with no live test coverage, so I want to smoke-test it against both a modern host (3.1.1 with signing) and an older target before this goes in.

Holding off on merge until I've confirmed those paths. Will follow up here.

[psycep]

Verified the code paths and they hold up. I built a Samba dialect matrix (one server pinned to each of SMB 2.0.2, 2.1.0, 3.0.0, 3.0.2, 3.1.1, plus a 3.1.1 server with encryption required), all with mandatory signing, and ran the actual smbclient tool with this change applied:

• All six dialects negotiate, authenticate, and sign correctly. I confirmed the real negotiated dialect on each (not just the server config), so the full range is genuinely exercised.
• The encryption required 3.1.1 server forces SMB3 encryption and the client handles it (session establishes, shares list).
• Real Windows Server 2019 also checks out end to end: a member server (local auth) and a domain controller (domain auth) both establish at SMB 3.1.1 with signing and list shares.

So removing the pinned dialect is safe across the whole 2.0.2 to 3.1.1 range, including the SMB3 signing and encryption paths that were never active while we forced 2.1.0. Merging. Thanks for the fix.

[ahm3dgg]

Glad it Works !
Thanks for your great effort on this project :)