[cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

[Edgar Olougouna]

Jeff,

If the server does not respond to outstanding requests, the expected behavior is that the Windows client sends out an echo request. 

Can you consistently reproduce the scenario whereby the client does not send the echo request? We would be interested to investigate this, if needed.

We will update the Windows behavior note to reflect the fact that the client closes the connection regardless of the echo probe response if there is no response to the outstanding commands that "have exceeded" the Client.SessionTimeoutValue.  This update describes the behavior you observed in your testing. 

Let me clarify a bit further. Like Chris mentioned, there are two key factors, i.e. session timeout value and 30 seconds scanning interval for outstanding requests.

Per MS-CIFS Section 3.2.3, the Client.SessionTimeoutValue is set based on system policy. The "default" session timeout value is 45 seconds in Windows NT, and 60 seconds in Windows 2000 and onward. Per KB102067, Client.SessionTimeoutValue could vary depending upon the client's policy.
The scanning for outstanding commands occurs every 30 seconds (request expiration timer event). As a result this incurs a lag on the time the client effectively closes the connection. 

For example, let's assume that at the scanning interval, an outstanding command is due to expire in 8 seconds. The scavenger will not close the connection at this time; it will be closed at the next scanning cycle. This will result in:
Client.SessionTimeoutValue (45 seconds default for NT, 60 sec default for Windows 2000 and beyond) - due seconds at the scavenger timer event (8 seconds) + next scavenger time (30 seconds).
If it is the default 60 seconds session timeout, then the connection will be effectively closed at 82 seconds. 

This is the provisional update to MS-CIFS:

Current behavior note:

<WBN> Section 3.2.6.1: Windows NT and Windows 98 CIFS clients periodically scan for any commands that have not completed. The default scanning period is 30 seconds. If there are outstanding commands that have exceeded the Client.SessionTimeoutValue, an SMB_COM_ECHO (section 2.4.36) is sent to determine whether or not the connection has been lost. The client closes the connection only if there is no response to the echo request.

Provisional Windows behavior note:

<WBN> Section 3.2.6.1: Windows NT and Windows 98 CIFS clients periodically scan for any commands that have not completed. The default scanning period is 30 seconds. If there are outstanding commands that have exceeded the Client.SessionTimeoutValue, an SMB_COM_ECHO (section 2.2.4.36) is sent to determine whether or not the connection has been lost. Regardless of receiving the SMB_COM_ECHO response, the client closes the connection if there is no response to the outstanding commands that have exceeded the Client.SessionTimeoutValue. 

Regards,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Wednesday, December 08, 2010 1:45 PM
To: 'Jeff Layton'
Cc: Christopher R. Hertel; pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

The pcap format of the capture is fine. I am able to open this in Netmon. I will update you as soon I have news.

Thanks,
Edgar

-----Original Message-----
From: Jeff Layton [mailto:jlayton at poochiereds.net] On Behalf Of Jeff Layton
Sent: Wednesday, December 08, 2010 6:01 AM
To: Edgar Olougouna
Cc: Christopher R. Hertel; pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

On Tue, 7 Dec 2010 21:33:56 +0000
Edgar Olougouna <edgaro at microsoft.com> wrote:

> Jeff,
> 
> Could you provide some network captures so I can further investigate the behavior you described?
> 
> Thanks,
> Edgar
> 

Certainly...attached.

The capture is in libpcap format (hope that's OK). If not, then let me know and I can convert it to another.

The setup is a win2k8 host talking to my crippled smbd that doesn't respond to WriteAndX requests. Basically I just mapped the share to a drive letter, and then used "copy" from the command line on the win2k8 host to try to copy a file to the share. I believe the win2k8 host is fully patched (at least as of a week or two ago).

As you can see, the client consistently disconnects the share after getting no response from the write, even though echoes do get a response. Also note that on the first copy attempt, the share was disconnected without the client sending any echoes.

--
Jeff Layton <jlayton at samba.org>