[Samba] SMB Multichannel not working?

Tue Feb 7 00:23:29 UTC 2023

Jeremy,

Once again, thank you for the time; I owe you a coffee my friend!

"So your original report that Samba doesn't set the MULTI CHANNEL
bit was incorrect, we do (and in the right place)."

I would like to clarify that I was really just confused by the first SMBv2 response I got from the server (packet 6 in the capture), because the capabilities had multichannel disabled
Capabilities: 0x00000007, DFS, LEASING, LARGE MTU
    .... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
    .... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
    .... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
    .... .... .... .... .... .... .... 0... = MULTI CHANNEL: This host does NOT support MULTI CHANNEL
    .... .... .... .... .... .... ...0 .... = PERSISTENT HANDLES: This host does NOT support PERSISTENT HANDLES
    .... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
    .... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION

but the client request/response packets after that do have MC enabled as you pointed out. I was just simply confused by the switch between the two responses from the server, but that is probably a red-herring.

As for the differences in the IPC connection, that is a very interesting find! Our config file is very barebones and we have explicitly set "read only = no" on a few of our shares. The "filestore" share is not a read only share. Do you have any suggestions for a config that would be "unrestrictive" to enable us to test your theory?

[global]
    log file = /var/log/samba/%m
    log level = 1
    unix password sync = yes
    netbios name = sambatoebs
    map to guest = bad user
    guest account = samba-client
    hosts allow = 172.27.252.0/255.255.255.0
    force user = samba-client
    guest ok = yes
    force create mode = 777
    force directory mode = 777
    server multi channel support = yes
    force:server multi channel support = yes
    interfaces = "172.27.252.40;capability=RSS,speed=25000000000"
    aio write size = 1
    aio read size = 1
[filestore]
    path = /mnt/filestore
    read only = no
    writable = yes
    browsable = yes
    public = yes
[filestore_readonly]
    path = /mnt/filestore
    read only = yes
    writable = no
    browsable = yes
    public = yes
[tmp]
    path = /mnt/filestore/tmp
    read only = no
    writable = yes
    browsable = yes    public = yes

Carter Sheehan
Cloud Engineer
d: +1 (781) 224-7753
e: 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: Monday, February 6, 2023 5:06 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 Mon, Feb 06, 2023 at 09:30:13PM +0000, Carter Sheehan wrote:
> Jeremy,
> I've done some packet analysis between my two windows hosts, connecting
> via SMB and I am seeing basically the same behavior when connecting to
> Samba but my Get-SmbMultichannelConnection powershell command actually
> returns a result stating multichannel is enabled.
> Here are two S3 object URLs for that two packet captures (both links will
> expire in 3 hours)
>
> • [1]Windows to Samba
> • [2]Windows to Windows

OK, the SMB1 -> SMB2 bootstrap is a red-herring.

In [2] (Windows -> Windows) the client still does the SMB1->SMB2 bootstrap,
and the second (SMB2+) client Negprot sends:

Capabilities: 0x0000007f, DFS, LEASING, LARGE MTU, MULTI CHANNEL, PERSISTENT HANDLES, DIRECTORY LEASING, ENCRYPTION
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
.... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
.... .... .... .... .... .... .... 1... = MULTI CHANNEL: This host supports MULTI CHANNEL
.... .... .... .... .... .... ...1 .... = PERSISTENT HANDLES: This host supports PERSISTENT HANDLES
.... .... .... .... .... .... ..1. .... = DIRECTORY LEASING: This host supports DIRECTORY LEASING
.... .... .... .... .... .... .1.. .... = ENCRYPTION: This host supports ENCRYPTION

and receives back:

Capabilities: 0x0000002f, DFS, LEASING, LARGE MTU, MULTI CHANNEL, DIRECTORY LEASING
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
.... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
.... .... .... .... .... .... .... 1... = MULTI CHANNEL: This host supports MULTI CHANNEL
.... .... .... .... .... .... ...0 .... = PERSISTENT HANDLES: This host does NOT support PERSISTENT HANDLES
.... .... .... .... .... .... ..1. .... = DIRECTORY LEASING: This host supports DIRECTORY LEASING
.... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION

In [1] (Windows -> Samba) the client does the SMB1->SMB2 bootstrap,
and the second (SMB2+) client Negprot sends (as before):

Capabilities: 0x0000007f, DFS, LEASING, LARGE MTU, MULTI CHANNEL, PERSISTENT HANDLES, DIRECTORY LEASING, ENCRYPTION

and receives back:

Capabilities: 0x0000000f, DFS, LEASING, LARGE MTU, MULTI CHANNEL
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
.... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
.... .... .... .... .... .... .... 1... = MULTI CHANNEL: This host supports MULTI CHANNEL
.... .... .... .... .... .... ...0 .... = PERSISTENT HANDLES: This host does NOT support PERSISTENT HANDLES
.... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
.... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION

the only difference being Samba isn't reporting support
for DIRECTORY LEASING (which is planned but not yet implemented).

So your original report that Samba doesn't set the MULTI CHANNEL
bit was incorrect, we do (and in the right place).

The difference starts after that. In the Windows -> Windows trace
the client opens IPC$ and then sends:

Function: FSCTL_QUERY_NETWORK_INTERFACE_INFO (0x001401fc)

and receives back in the reply two interfaces - thus allowing
the client to start multichannel setup.

In the Windows -> Samba trace the client opens IPC$ but DOES
NOT SEND FSCTL_QUERY_NETWORK_INTERFACE_INFO, which is required
to start multichannel setup.

So let's look at the differences in the tcon connection request
to the IPC$ share.

Windows -> Windows returns these flags:

Share flags: 0x00000030
.... .... .... .... .... .... .... ...0 = DFS: False
.... .... .... .... .... .... .... ..0. = DFS root: False
.... .... .... .... .... ...0 .... .... = Restrict exclusive opens: False
.... .... .... .... .... ..0. .... .... = Force shared delete: False
.... .... .... .... .... .0.. .... .... = Allow namespace caching: False
.... .... .... .... .... 0... .... .... = Access based directory enum: False
.... .... .... .... ...0 .... .... .... = Force level II oplock: False
.... .... .... .... ..0. .... .... .... = Enable hash V1: False
.... .... .... .... .0.. .... .... .... = Enable hash V2: False
.... .... .... .... 0... .... .... .... = Encrypted data required: False
.... .... .... .0.. .... .... .... .... = Identity Remoting: False
.... .... ...0 .... .... .... .... .... = Compressed IO: False
Caching policy: No caching (00000030)
Access Mask: 0x011f01ff (this is full access).

In contrast, Windows -> Samba tcon connection request
to the IPC$ share returns these flags:

Share flags: 0x00000000
Access Mask: 0x001f00a9
.... .... .... .... .... .... .... ...1 = Read: READ access
.... .... .... .... .... .... .... ..0. = Write: NO write access
.... .... .... .... .... .... .... .0.. = Append: NO append access
.... .... .... .... .... .... .... 1... = Read EA: READ EXTENDED ATTRIBUTES access
.... .... .... .... .... .... ...0 .... = Write EA: NO write extended attributes access
.... .... .... .... .... .... ..1. .... = Execute: EXECUTE access
.... .... .... .... .... .... .0.. .... = Delete Child: NO delete child access
.... .... .... .... .... .... 1... .... = Read Attributes: READ ATTRIBUTES access
.... .... .... .... .... ...0 .... .... = Write Attributes: NO write attributes access
.... .... .... ...1 .... .... .... .... = Delete: DELETE access
.... .... .... ..1. .... .... .... .... = Read Control: READ ACCESS to owner, group and ACL of the SID
.... .... .... .1.. .... .... .... .... = Write DAC: OWNER may WRITE the DAC
.... .... .... 1... .... .... .... .... = Write Owner: Can WRITE OWNER (take ownership)
.... .... ...1 .... .... .... .... .... = Synchronize: Can wait on handle to SYNCHRONIZE on completion of I/O
.... ...0 .... .... .... .... .... .... = System Security: System security is NOT set
.... ..0. .... .... .... .... .... .... = Maximum Allowed: Maximum allowed is NOT set
...0 .... .... .... .... .... .... .... = Generic All: Generic all is NOT set
..0. .... .... .... .... .... .... .... = Generic Execute: Generic execute is NOT set
.0.. .... .... .... .... .... .... .... = Generic Write: Generic write is NOT set
0... .... .... .... .... .... .... .... = Generic Read: Generic read is NOT set

Share flags are not set to No caching policy. And
the access mask *isn't* set to full access.

Looks like this is a read-only share ?

As a test, can you try and change the Samba
share access to be the same as the Windows one ?

Also, the tcon to IPC$ on the Windows share is done
to the IP address string "\\172.27.252.55\IPC$"
but the tcon to IPC$ on the Samba share is done to
the DNS name string "\\pte-fileshare.vdc.local\IPC$"
although I can't see how that would make a difference.

As the IPC$ tcon is the only relevent SMB2 call done
before the FSCTL_QUERY_NETWORK_INTERFACE_INFO request
on the IPC$ share, my guess is there's some difference
there the client doesn't like w.r.t. setting up
multi-channel.

But I don't know what yet :-).

Jeremy.