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

Edgar Olougouna edgaro at microsoft.com
Tue Feb 2 16:02:54 UTC 2016


[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


More information about the cifs-protocol mailing list