With regard to my previous message, the 15-minute inactivity timeout is expected.
The attempt to send an echo request without re-negotiating is not, and thus the server is closing the connection with a reset. Commit b8c600120fc87d53642476f48c8055b38d6e14c7 "Call echo service immediately after socket reconnect" This path likely introduced or contributed to the behavior we're seeing. Prior to this, when the system reconnected, the TCP socket would be brought open in connect.c:cifs_reconnect(), but no echos were scheduled, and it was simply left in a CifsNeedsNegotiate state. The connection was re-negotiated when the next "real" SMB request was made. The SMBv1 echo code itself is unable to re-negotiate the connection: When I follow the connect.c:cifs_echo_request() code through to "server->ops->echo(server)" which is called when we need a re- negotiate, that brings me to cifssmb.c:CIFSSMBEcho(). CIFSSMBEcho() calls small_smb_init() with tcon=NULL. small_smb_init() calls cifs_reconnect_tcon() with tcon=NULL, which then exits with rc=0, as it can't get references to session or server without tcon. The rest of the CIFSSMBEcho() code completes, and attempts to send an echo request to the server, without re-negotiating the connection. The server resets the connection, connect.c:cifs_readv_from_socket() notices this, calls connect.c:cifs_reconnect(), and the entire process repeats itself, ~1000 times per second in my testing. I would consider marking this a CRITICAL issue, as it could cause a significant DDOS against windows servers. I haven't done a diff with Linux 4.11-rc6, but a quick review of the patches do not appear to mention any of this behavior. Additionally, I value the need for this patch, as the TCP session will be reestablished as soon as the connection is reset, but echos are not required until "real" SMB services are requested again by the client... --Luke Suchocki
