Upgrade SMB client in Infuse to protocol 3.1.1 (SMB3_11)


Recently i built my new file server running on TrueNAS, SMB server serves flawlessly every device and different software clients in my household. Except that Infuse wasn’t happy and server logs revealed that Infuse is still using SMB protocol 3.0.2 and tried to negotiate encryption algorithm AES-128-CCM on a media share that does not require encryption. I only had encryption set to ‘desired’ globally on SMB server. Even in same iphone, i had Apple’s Files app, VLC, nPlayer connected just fine.

I had to adjust SMB server settings to make Infuse happy. At this point SMB protocol version 3.1.1 (SMB3_11) is 9 years old, with this version AES-128-CCM and AES-128-CMAC is no longer suggested as default algorithms for encryption and signing. Is there any particular reason to stay with 3.0.2? For compatibility purpose, 3.1.1 client can still connect to legacy SMB servers that doesn’t upgrade to 3.1.1.

Thanks for considering.

(Edit: i’m running latest version of Infuse Pro on latest versions of iOS and ipadOS)

Currently, the SMB implementation in Infuse negotiates 3.0.2 dialect and doesn’t yet support 3.1.1. This is something that we would like to add but it’s a huge amount of work.

The SMB 3.0.2 dialect supports 128-bit encryption and 1 signing algorithm, whereas 3.1.1 supports 128 & 256-bit encryption algorithms, multiple signing algorithms, and all permutations of both.

The latest macOS Sonoma release supports SMB 3.1.1 dialect when acting as a client, but the macOS SMB server component only accepts 3.0.2 dialect as the maximum version. A 3.1.1 client can still connect to “legacy SMB servers” but that wouldn’t be via the 3.1.1 dialect, as it’s not backward compatible. The client would need to support both 3.0.2 and 3.1.1 dialects.

Regarding negotiating encryption, Infuse advertises that encryption is supported but it’s up to the server whether or not it responds to enable it or not. We don’t require that encryption is enabled, as it adds an overhead to packet processing (which can lead to performance issues when streaming larger files such as videos). Some versions of Windows servers will fail if they are configured with encryption or signing enabled (but not required), and a client claims to not support it.

Overall, there aren’t immediate plans to implement the 3.1.1 dialect, but we have been working on adding support for IAKerberos authentication, as some servers have blocked NTLMv2.