SMB multichannel troubleshooting

This article describes how to troubleshoot issues that are related to SMB multichannel.

Check the network interface status

Make sure that the binding for the network interface is set to True on the SMB client (MS_client) and SMB server (MS_server). When you run the following cmdlet, the output should show True under Enabled for both network interfaces:

Get-NetAdapterBinding -ComponentID ms_server,ms_msclient

After that, make sure the network interface is listed in the output of the following cmdlets:

Get-SmbServerNetworkInterface

Get-SmbClientNetworkInterface

You can also run the Get-NetAdapter cmdlet to view the interface index to verify the result. The interface index shows all the active SMB adapters that are actively bound to the appropriate interface.

Check the firewall

If there's only a link-local IP address, and no publicly routable address, the network profile is likely set to Public. This means that SMB is blocked at the firewall by default.

The following cmdlet reveals which connection profile is being used. You can also use the Network and Sharing Center to retrieve this information.

Get-NetConnectionProfile

Under the File and Printer Sharing group, check the firewall inbound rules to make sure that SMB-In is enabled for the correct profile.

You can also enable File and Printer Sharing in the Network and Sharing Center window. To do this, select Change advanced sharing settings in the menu on the left, and then select Turn on file and printer sharing for the profile. This option enables the File and Printer Sharing firewall rules.

Capture client and server sided traffic for troubleshooting

You need the SMB connection tracing information that starts from the TCP three-way handshake. We recommend that you close all applications (especially Windows Explorer) before you start the capture. Restart the Workstation service on the SMB client, start the packet capture, and then reproduce the issue.

Make sure that the SMBv3.x connection is being negotiated, and that nothing in between the server and the client is affecting dialect negotiation. SMBv2 and earlier versions don't support multichannel.

Look for the NETWORK_INTERFACE_INFO packets. This is where the SMB client requests a list of adapters from the SMB server. If these packets aren't exchanged, multichannel doesn't work.

The server responds by returning a list of valid network interfaces. Then, the SMB client adds those to the list of available adapters for multichannel. At this point, multichannel should start and, at least, try to start the connection.

For more information, see:

• 3.2.4.20.10 Application Requests Querying Server's Network Interfaces
• 2.2.32.5 NETWORK_INTERFACE_INFO Response
• 3.2.5.14.11 Handling a Network Interfaces Response

In the following scenarios, an adapter can't be used:

• There's a routing issue on the client. This is typically caused by an incorrect routing table that forces traffic over the wrong interface.
• Multichannel constraints have been set. For more information, see New-SmbMultichannelConstraint.
• Something blocked the network interface request and response packets.
• The client and server can't communicate over the extra network interface. For example, the TCP three-way handshake failed, the connection is blocked by a firewall, session setup failed, and so on.

If the adapter and its IPv6 address are on the list that is sent by the server, the next step is to see whether communications are tried over that interface. Filter the trace by the link-local address and SMB traffic, and look for a connection attempt. If this is a NetConnection trace, you can also examine Windows Filtering Platform (WFP) events to see whether the connection is being blocked.