Red Hat Bugzilla – Bug 1476153
[RFE] libsmbclient should not terminate a connection in case it receives an SMB2 ECHO Response with an error
Last modified: 2018-02-23 09:16:23 EST
Description of problem:
According to the specs, a SMB server should answer an SMB2 ECHO Request with STATUS_SUCCESS to demonstrate it's responsive and can process requests. In some cases SMB servers might not be able to handle ECHO Requests with a Session ID 0 (which is completely valid according to the specs) and return an ERROR instead. As a result, smblclient currently terminates the network connection:
017-07-17 14:00:40.873514 192.168.220.211 → 188.8.131.52 SMB2 138 KeepAlive Request
2017-07-17 14:00:40.873637 184.108.40.206 → 192.168.220.211 SMB2 143 KeepAlive Response, Error: STATUS_USER_SESSION_DELETED
2017-07-17 14:00:40.873676 192.168.220.211 → 220.127.116.11 TCP 66 51296 → 445 [FIN, ACK] Seq=1632 Ack=1395 Win=35712 Len=0 TSval=2284796732 TSecr=2066 075117
We reached out to Microsoft to get some clarification what exactly the client is supposed to do in such a case. Here is the answer:
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).
This RfE is about a change in current libsmbclient behavior. The client *should not* terminate the network connection in case an error is returned from the server and should continue processing SMB commands instead.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Behavior of smbclient looks as described.