Red Hat Bugzilla – Bug 1475349
SMB2 ECHO Request implementation in libsmbclient
Last modified: 2017-07-28 03:28:37 EDT
Description of problem:
I've opened this BZ to track the request we sent to Microsoft to get some clarification about the SMB2 ECHO Request implementation currently used in libsmbclient.
[MS-SMB2] 2.2.28 defines the SMB2 ECHO Request as follows :
The SMB2 ECHO Request packet is sent by a client to determine whether a server is processing requests. This request is composed of an SMB2 header, as specified in section 2.2.1, followed by this request structure:
StructureSize (2 bytes): The client MUST set this to 4, indicating the size of the request structure, not including the header.
Reserved (2 bytes): This field MUST NOT be used and MUST be reserved. The client MUST set this to 0, and the server MUST ignore it on receipt.
The questions are:
1) Is it allowed to use a Session ID 0 in an SMB2 ECHO Request?
In [MS-SMB2] 188.8.131.52 and 184.108.40.206 it says:
SessionId (8 bytes): Uniquely identifies the established session for the command. This field MUST be set to 0 for an SMB2 NEGOTIATE Request (section 2.2.3) and for an SMB2 NEGOTIATE Response (section 2.2.4).
We believe it is allowed because an SMB2 ECHO Request is not associated with a user context. When a Microsoft Windows system receives an SMB2 ECHO Request with Session ID 0 it also replies with a SMB2 ECHO Response and STATUS_SUCCESS.
2) Should the client terminate the connection to the SMB server in case it receives an error in the SMB2 ECHO response (STATUS_INVALID_PARAMETER or STAUTS_USER_SESSION_DELETED)?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is the answer we received from Microsoft:
You are correct, Windows and SMB2 allow SessionId to be 0 for ECHO, but do not require it. It is necessary to establish a Session, but the ID does not need to be passed with the ECHO request. Non-zero MessageId is also needed, but neither a Tree Connection nor TID are necessary for ECHO.
Client behavior in regards to ECHO is implementation-specific (there is no mention in section 3.2). ECHO is merely a keep-alive ping to see if the server is responsive, so any response could be considered success. All the Server does (besides disconnecting the connection if Connection.SessionTable is empty) is validate the structure of the request. If the server returns STATUS_INVALID_PARAMETER, this indicates the Client formed the request incorrectly, but shows the Server is responsive (as does any response, error or success).
SMB1 had a lot of ECHO processing, where all known servers were regularly pinged, then the connection was disconnected if a server didn't respond in a timely manner. SMB2 has significantly simplified and reduced ECHO processing. Windows client doesn't initiate an ECHO (as far as I've been able to find), and only checks the response for valid structure, otherwise, receiving any response is considered success. However, other clients may behave differently.
SMB2 Client also has a Request Expiration timer (220.127.116.11 - optional) and Idle Connection Timer (18.104.22.168) which appear to serve the purpose previously filled by ECHO.
As a result, the following RfE has been filed:
[RFE] libsmbclient should not terminate a connection in case it receives an SMB2 ECHO Response with an error
I'm closing this bug since all questions have been answered by Microsoft. The RfE is now handled in BZ #1476153.