[cifs-protocol] [REG:116020213658088] After reconnect a SMB2 connection turns into a SMB3 connection

[Edgar Olougouna]

Ralph,

We confirm the symptom and workaround as documented in KB 2756452: Windows 8: SMB reconnections fail with “Invalid Signature” upon server upgrade to SMB 3.0 http://support.microsoft.com/kb/2756452

A Windows-based client does not support dynamic dialect upgrade from SMB 2.x to 3.x. The protocol specification and Windows client implementation assume that the negotiated dialect will remain unchanged during reconnection. This issue could occur with any server implementation. Here are some underlying reasons:
•	The validate dialect negotiation will fail due to the change in the signing algorithm in SMB 3.0. 
•	The SMB 2.x protocol uses HMAC-SHA256 for signing, while SMB 3.0 uses AES-CMAC. 
•	Our client holds the old keys generated for SMB 2.x and at reconnection the client is not regenerating the keys for SMB 3.x with the new crypto.

Windows 8: SMB reconnections fail with “Invalid Signature” upon server upgrade to SMB 3.0
http://support.microsoft.com/kb/2756452

SMB3 Secure Dialect Negotiation
http://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspx

Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Tuesday, February 2, 2016 10:03 AM
To: Ralph Wuerthner <ralphw at de.ibm.com>
Cc: MSSolve Case Email <casemail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: [REG:116020213658088] After reconnect a SMB2 connection turns into a SMB3 connection

[Case number in subject]
[Casemail to cc]
[Dochelp to bcc]

Hello Ralph,

Thank you for this question regarding SMB2/SMB3. The case number 116020213658088 has been created to track this request. One of our team members will follow up with you soon.

Regards,
Edgar

-----Original Message-----
From: Ralph Wuerthner [mailto:ralphw at de.ibm.com]
Sent: Tuesday, February 2, 2016 5:57 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: After reconnect a SMB2 connection turns into a SMB3 connection

Hi!

When testing SMB2 and SMB3 with Samaba 4.2 and Windows Server acting as SMB client I noticed the following unexpected behaviour:

A Windows Server 2012R2 is connected to a SMB2.1 share and the share is mapped as a network drive. Next the SMB server is closing the connection, causing the SMB client to immediately reopening the connection. This time the SMB server is responding with SMB3.0 in the negotiation response.

The expected behaviour would be that the network drive is unavailable for a short amount of time and further access works without issues.

The actual behaviour is different: after connecting to the previously opened share a FSCTL_VALIDATE_NEGOTIATE_INFO request is submitted with an invalid signature and the SMB server is responding with ACCESS_DENIED. The client continues with a second tree connect to the same share followed by an invalidly signed FSCTL_VALIDATE_NEGOTIATE_INFO request and so on.
In the end there are 20-30 tree connects to the same share and when trying to access the network drive the following error message pops up:

An error occurred while reconnecting Z: to \\10.0.100.133\abc Microsoft Windows Network: The local device name is already in use.

This connections has not been restored

For recovering from this error state and regain access to the network drive I identified the two different procedures:
- unmap and remap the network drive
or
- reboot the SMB client

Please see also the attached network trace.

What is wrong here? Is this a client or server bug? Are there any other possibilities to recover the SMB client?


With best regards,

Ralph Wuerthner

IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294