1475349 – SMB2 ECHO Request implementation in libsmbclient

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1475349 - SMB2 ECHO Request implementation in libsmbclient

Summary: SMB2 ECHO Request implementation in libsmbclient

Keywords:
Status:	CLOSED NOTABUG
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	samba
Sub Component:
Version:	7.4
Hardware:	All
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Andreas Schneider
QA Contact:	qe-baseos-daemons
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2017-07-26 13:31 UTC by Thorsten Scherf
Modified:	2020-12-14 09:15 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-07-28 07:28:37 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Description Thorsten Scherf 2017-07-26 13:31:33 UTC

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 [1]:

"""
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] 2.2.1.1 and 2.2.1.2 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)?

[1] https://msdn.microsoft.com/en-us/library/cc246540.aspx

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

Comment 5 Thorsten Scherf 2017-07-28 07:28:14 UTC

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 (3.2.2.1 - optional) and Idle Connection Timer (3.2.2.2) 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
https://bugzilla.redhat.com/show_bug.cgi?id=1476153

I'm closing this bug since all questions have been answered by Microsoft. The RfE is now handled in BZ #1476153.

Note You need to log in before you can comment on or make changes to this bug.