[Samba] SMB Multichannel not working?

[Jeremy Allison]

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.