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) * Windows to Samba<https://csheehan-samba-troubleshooting-bucket.s3.us-east-1.amazonaws.com/client-to-samba-capture.pcapng?response-content-disposition=inline&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMX%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJIMEYCIQCPLor81XLANRtMNdpxlHiBkhYjmOegrWekxWRcubUP1QIhALsWjgKbeoydM17bBlIKRZf1XZxUN6s9jktnzLxsEKXIKvgDCE4QABoMODQ0MDY4NDE0NzU2IgwF735tbcew8Syax5cq1QOGqHQADMnTpxkgaFeTuyPtgsc9PRCCxTmXy5iVAWBEfaTEdJKeekq1skObVNXvGn%2BYE%2BQ5aE%2BILRU7FEjHTaHwoSuvryX7MyEz%2FDzZWVIpje2WBm7ofzacPRMGYgwpQ6F2psLIkpcEpeHSebV0Tt6Yi8a7%2BrIZtPKx8iSRXMx0yKXEr7IWxh%2FYOinAeOIfrg7SgQHpslIq12aAYTp2pIz3HCGFeavSLOnAA%2FCxSCb5yAhRipOiWoln0qv1gxy6eFvOASs6iIx9EHpdrq2%2FJCtGMLldYSI75%2ByzPJxzSNXBsaqK2ENW%2BzPHuW01klmufYV%2Fnihlo6wVyFfg%2Fpifd6B8DWlT49q9OnAwO8N0H7WRvicCIjyhl243l27nwH6NN3%2FsWRu2XbmVqBJ5Knj3dwi%2BnKzG6FjyZ7swojRB0ay488X58edldKAS%2B1anQQsdPFWOAvsaJyfKZbp1RwLX%2BFy8XIKYKx4fzh%2BfeJqlwDdVh4iwTkfBHSpoJ4jJsVuNEMKOFH0IgirF7LC2NMBO0ZykvCvQBXlC4iBAch5afdwItHVP%2B1cfKjKwOpD0A2zXNwkgupquR2AJFxvuYqpgKZnWXSkqwCwM5EnMBbAwlf6VFZVyYSVbMJXHhZ8GOpMCuvh2pM7vng7tloBj26sb7OCV2ijgvPOk0h7mxyZY6hdTAfUVAtJRttKIL6qL9mVfYW7tGTGXHwfvS2O7r3iwYjTflp8JAFtO%2Bkim%2B0an9DWAPqofqqGwlj1%2FEpdJxIXG3YstR9twcliM16kykELZt%2BUL6iRWAm5czTNj3Qt8OA37i3pExnZkPmaMbQ3%2FA1vGdYvi0vHOPXxRftLFk8EmbDQgmbgTMNv2OlHZEkZNWfxy%2BWEhodSYwcy5UG0I4cObWLQF9e2boN7fMCTTTY1hS0U%2F7SzStfl0Spn0yA33DBZlPBhvCcEnXmKzt67pokM42k2jMA54WdmBHni80GkQ7ULqL4Dg8SRVCN3dv%2Biu9pAtkY4%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20230206T212247Z&X-Amz-SignedHeaders=host&X-Amz-Expires=10800&X-Amz-Credential=ASIA4JBTF4USPJPXYIM3%2F20230206%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=59c345cada6e519b81ff0e69607515a86dcbb68f41db09acfa358dcb93e8c63f> * Windows to Windows<https://csheehan-samba-troubleshooting-bucket.s3.us-east-1.amazonaws.com/windows-to-windows-capture.pcapng?response-content-disposition=inline&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMX%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJIMEYCIQCPLor81XLANRtMNdpxlHiBkhYjmOegrWekxWRcubUP1QIhALsWjgKbeoydM17bBlIKRZf1XZxUN6s9jktnzLxsEKXIKvgDCE4QABoMODQ0MDY4NDE0NzU2IgwF735tbcew8Syax5cq1QOGqHQADMnTpxkgaFeTuyPtgsc9PRCCxTmXy5iVAWBEfaTEdJKeekq1skObVNXvGn%2BYE%2BQ5aE%2BILRU7FEjHTaHwoSuvryX7MyEz%2FDzZWVIpje2WBm7ofzacPRMGYgwpQ6F2psLIkpcEpeHSebV0Tt6Yi8a7%2BrIZtPKx8iSRXMx0yKXEr7IWxh%2FYOinAeOIfrg7SgQHpslIq12aAYTp2pIz3HCGFeavSLOnAA%2FCxSCb5yAhRipOiWoln0qv1gxy6eFvOASs6iIx9EHpdrq2%2FJCtGMLldYSI75%2ByzPJxzSNXBsaqK2ENW%2BzPHuW01klmufYV%2Fnihlo6wVyFfg%2Fpifd6B8DWlT49q9OnAwO8N0H7WRvicCIjyhl243l27nwH6NN3%2FsWRu2XbmVqBJ5Knj3dwi%2BnKzG6FjyZ7swojRB0ay488X58edldKAS%2B1anQQsdPFWOAvsaJyfKZbp1RwLX%2BFy8XIKYKx4fzh%2BfeJqlwDdVh4iwTkfBHSpoJ4jJsVuNEMKOFH0IgirF7LC2NMBO0ZykvCvQBXlC4iBAch5afdwItHVP%2B1cfKjKwOpD0A2zXNwkgupquR2AJFxvuYqpgKZnWXSkqwCwM5EnMBbAwlf6VFZVyYSVbMJXHhZ8GOpMCuvh2pM7vng7tloBj26sb7OCV2ijgvPOk0h7mxyZY6hdTAfUVAtJRttKIL6qL9mVfYW7tGTGXHwfvS2O7r3iwYjTflp8JAFtO%2Bkim%2B0an9DWAPqofqqGwlj1%2FEpdJxIXG3YstR9twcliM16kykELZt%2BUL6iRWAm5czTNj3Qt8OA37i3pExnZkPmaMbQ3%2FA1vGdYvi0vHOPXxRftLFk8EmbDQgmbgTMNv2OlHZEkZNWfxy%2BWEhodSYwcy5UG0I4cObWLQF9e2boN7fMCTTTY1hS0U%2F7SzStfl0Spn0yA33DBZlPBhvCcEnXmKzt67pokM42k2jMA54WdmBHni80GkQ7ULqL4Dg8SRVCN3dv%2Biu9pAtkY4%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20230206T212311Z&X-Amz-SignedHeaders=host&X-Amz-Expires=10800&X-Amz-Credential=ASIA4JBTF4USPJPXYIM3%2F20230206%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=773cee62094fcbbb35a2496c395ac165b0cf26e1e21961e2f652f361bbab1579> 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: samba <samba-bounces at lists.samba.org> on behalf of Carter Sheehan via samba <samba at lists.samba.org> Sent: Monday, February 6, 2023 3:31 PM To: Jeremy Allison <jra at samba.org> Cc: samba at lists.samba.org <samba at lists.samba.org> Subject: Re: [Samba] SMB Multichannel not working? Jeremy, That's what is so vexxing about this, the SMB client in Windows Server 2019 has SMBv1 disabled by default. Using the articles you provided, I can confirm that SMBv1 is not enabled for the SMB server/client. 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 2:17 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 Sun, Feb 05, 2023 at 09:11:41PM +0000, Carter Sheehan wrote:> Jeremy, > I am clearing the contents of the packet capture with my security team and > I'll have it available to you some time tomorrow. > Regarding protocol negotiation, I have tried using some of the available > server/client min/max protocol config options for smb.conf hoping it would > "force" the use of SMB3+ but I still see the same SMB/SMBv2 packets in a > wireshark capture and both the client and server display the connection as > using dialect 3_11, so that doesn't seem to have any impact whatsoever for > me.This is a clients feature I think, not controllable on the server-side. When connecting to an unknown server a Windows client tries the SMB1->SMB2+ upgrade. Just remove SMB1 from this client. https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server<https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server><https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server<https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server>> https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server#how-to-remove-smbv1-via-powershell<https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server#how-to-remove-smbv1-via-powershell><https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server#how-to-remove-smbv1-via-powershell<https://learn.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3?tabs=server#how-to-remove-smbv1-via-powershell>> -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba<https://lists.samba.org/mailman/options/samba>
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 WindowsOK, 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.