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.
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 2:56 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 05:19:50PM +0000, Carter Sheehan via samba
wrote:>Rowland,
>
>Here are a few screenshots of the protocol negotiation packets between my
client (172.27.252.57) and my Samba server (172.27.252.11):
https://imgur.com/a/nXk3QRV<https://imgur.com/a/nXk3QRV>
>[https://i.imgur.com/wCcFvhc.png?fb<https://i.imgur.com/wCcFvhc.png?fb>]<https://imgur.com/a/nXk3QRV<https://imgur.com/a/nXk3QRV>>
>imgur.com<https://imgur.com/a/nXk3QRV<https://imgur.com/a/nXk3QRV>>
>Imgur: The magic of the Internet
>imgur.com
>
>
>In the screenshots, there is an initial SMB request from the client (no
capabilities specified), an SMBv2 reply from the server stating it does NOT
support multi channel, a 2nd request from the client (now in SMBv2 protocol),
and an SMBv2 reply from the server saying it supports multichannel. The two
replies from the server contradict one another. The "Session Request"
packets after the protocol negotiations show the session request did not have
multichannel enabled. I suspect this is because the client saw the first
protocol negotiation reply that said the server did not support multichannel and
so the client did not enable multichannel in it's request for a session.
OK, that's the problem. The initial SMB request from the client
has zero capabilities specified.
The code to return multi-channel capability looks like this:
if (protocol >= PROTOCOL_SMB3_00 &&
xconn->client->server_multi_channel_enabled)
{
if (in_capabilities & SMB2_CAP_MULTI_CHANNEL) {
capabilities |= SMB2_CAP_MULTI_CHANNEL;
}
}
Note that in_capabilities (capabilities offered by the
client) needs to have SMB2_CAP_MULTI_CHANNEL set in order
for the server to reply that it supports SMB2_CAP_MULTI_CHANNEL.
What client is this ?