Jeremy,
My apologies, and thanks again for all the help!
My client is just Windows Server 2019 with nearly default settings for the SMB
Client (which should use SMBv3 by default hence the dialect 3_1_1). I have been
able trigger SMB Multichannel when connecting via SMB to another windows host so
I know my client is capable in its current hardware configuration.
As for the wireshark packet capture, I'd love to share that with you, do you
have a preferred place for file sharing?
Carter Sheehan
Cloud Engineer
o: +1 (781) 224-7753<tel:+1%20(781)%20224-7753>
e: csheehan at vestmark.com<mailto:csheehan at vestmark.com>
This e-mail and any attachments hereto, are intended for use by the addressee(s)
only and may contain information that is confidential information of Vestmark,
Inc. If you are not the intended recipient of this e-mail, or if you have
otherwise received this e-mail in error, please immediately notify me by
telephone or by e-mail, and please permanently delete the original, any print
outs and any copies of the foregoing. Any dissemination, distribution or copying
of this e-mail is strictly prohibited.
________________________________
From: Jeremy Allison <jra at samba.org>
Sent: Thursday, February 2, 2023 4:20 PM
To: Carter Sheehan <csheehan at vestmark.com>
Cc: samba at lists.samba.org <samba at lists.samba.org>
Subject: Re: [Samba] SMB Multichannel not working?
External Email
This email was NOT sent from someone at Vestmark
On Thu, Feb 02, 2023 at 08:48:01PM +0000, Carter Sheehan via samba
wrote:>Jeremy,
>
>Thanks for the clue, but I am confused by the response and evidence. In the
screenshots, as you can see there are 2 protocol negotiation requests from the
client (1 of SMB protocol, the other of SMBv2). In the first request (SMB
protocol) there simply is no part of the packet that mentions capabilities. Is
that expected from an SMB protocol packet, should the client have specified
it's capabilities? It's only when the protocol switches to SMBv2 that
the capabilities are listed (and that's where the contradictory responses
from the server come from).
>
>It's worth noting that the Get-SmbConnection command in PowerShell on my
client side shows that the dialect chosen is SMB 3_1_1, and when I run the
command smbstatus on my server I can see the client connected with SMB3_1_1.
You have to realize I can't read the things you posted,
and you're not giving access to the wireshark traces,
so I'm just going via your text descriptions.
So it looks like your client is doing the SMB1 -> SMB2 bootstrap
in negprot. That usually only done for "old" connections to
unknown servers.
Try just removing the SMB1 client code from your client.
Why is it even there ?