CifsClient: pslsocket: read error: [232] Connection reset by peer

[Kirk MacLean_2]

Hello fellow admins:

I'm new to an existing environment. On an HP-UX 11.00 cifs client A.01.06, upon examining /var/opt/cifsclient/debug, noticed an error reappearing every 25 minutes or so. Any idea what this is? Searching google and ITRC turned up little useful information.

see below...

11/11 14:33:00.53 [0] Server LM: Windows Server 2003 5.2
11/11 14:48:22.83 [1] pslsocket: read error: [232] Connection reset by peer
11/11 14:48:55.16 [1] pslsocket: read error: [232] Connection reset by peer
11/11 14:49:01.20 [0] Server OS: Windows NT 4.0
11/11 14:49:01.20 [0] Server LM: NT LAN Manager 4.0
11/11 14:49:01.21 [0] Server OS: Windows Server 2003 3790
11/11 14:49:01.21 [0] Server LM: Windows Server 2003 5.2
11/11 15:04:22.85 [1] pslsocket: read error: [232] Connection reset by peer
11/11 15:04:55.16 [1] pslsocket: read error: [232] Connection reset by peer
11/11 15:05:21.79 [0] Server OS: Windows NT 4.0
11/11 15:05:21.79 [0] Server LM: NT LAN Manager 4.0
11/11 15:05:21.80 [0] Server OS: Windows Server 2003 3790
11/11 15:05:21.80 [0] Server LM: Windows Server 2003 5.2
11/11 15:30:22.89 [1] pslsocket: read error: [232] Connection reset by peer
11/11 15:30:55.17 [1] pslsocket: read error: [232] Connection reset by peer

[Sameer_Nirmal]

Hi,
It seems that the Windows CIFS servers are rebooted.
The messages shows that HP-UX host which is acting as a CIFS client tried to contact those servers whenever cifslogin is used. There are socket errors meaning the connection has been reset by CIFS servers. Windows CIFS server breaks the socket connection if it is rebooted.

Refer the following document for details and workaround.

http://www1.itrc.hp.com/service/cki/search.do?category=c0&prevQueryString=read+error+232+Connection+reset+by+peer&searchLevel=newsearch&mode=text&searchString=read+error+232+Connection+reset+by+peer+cifs&searchCrit=allwords&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&dateRange=all

[Kirk MacLean_2]

The link you provided returns:

Note: We're sorry but your search produced 0 results.


Is there a specific document instead of a search?

Thank you.

[Sameer_Nirmal · Accepted solution]

The document is attached herewith.

[Eric Raeburn]

Kirk,

The "connection reset" messages do not occur only when the server is rebooted. I've just examined several CIFS Client logfiles and have found a consistent pattern of such messages occurring after about fifteen minutes of inactivity on the mountpoint. The servers in these cases were Win2000. They drop the TCP connection until activity is resumed. This is quite normal for a Windows server.

After a little experiment with a network trace tool, I observe this: When there is no activity from the client, the NetBIOS Session Service on the server sends TCP "keep-alive" packets to the client, at intervals of about 2min 11sec. The client replies positively to these packets (it sends "ACKs"). After seven of these exchanges (the aforementioned fifteen minute interval), the server's NBSS sends a TCP reset.

When CIFS Clients (including Windows and the HP CIFS Client) again attempt to access the server, they automatically re-establish both their drive mapping (or cifs mount) and logins. This is a standard feature, and, as is now plain to see, a necessary feature, due to the behavior of the server.

If you want to see the gory details, enable the "cifsTrace" and "nfsTrace" log levels, and examine your logs again, you will see that after one of those reset messages, when the first request on the montpoint occurs, the CIFS Client automatically re-establishes its connection with the server. The NFS log messages indicate what the original request is from the shell, and the CIFS log messages will show first a typical set of connection exchanges (negotiate, session setup, tree connect), followed by a CIFS exchange that satisfies the original request from the shell.

You might also use a network trace tool, like tethereal or tcpdump, to watch the keep-alives and the eventual reset.

HP CIFS Client logging consumes a lot of disk, and slows performance of the daemon, so after you have completed your investigation, please remember to disable the log levels.

I've attached the output from my experiment: a CIFS Client log and a tethereal trace. Note that I did not turn on the extra log levels in the CIFS Client.

-Eric

[Eric Raeburn]

Kirk,

The attachment in the previous message was done with vi on HPUX. I may be hard to read if you're using a PC (Unix newlines). Here is (I hope) a cleaner version of the attachment, formatted as html.

-Eric

[Bryan Strait]

I'm having a similar problem on HP-UX 11.23 (Sept 04, no additional patches) using CIFS client A.1.09.03. I am also getting the "pslsocket: read error Connection reset by peer" messages. However, this occurs on a system that runs 24hrs a day for months at a time. At seemingly random times throughout the month, we'll see 1 or more of these messages. Some of these messages seem to correlate to file read/write errors we're getting on some custom software.

I haven't been able to capture the CIFS transactions yet with tcpdump or ethereal due to its intermittent nature. Any ideas what could be causing those errors in these cases?

[Eric Raeburn]

Bryan,

In my message above (timestamp Nov 12, 2005 07:02:43 GMT) I explained that this is a normal occurance, and should not be a problem. Are you saying simply that the "reset" message is disconcerting, or is there a real problem, like a read or write failure? If there is a real problem, we definitely want to hear about it.

Remember, the reset is initiated by the server--not the client--after some period of inactivity on the share.

Here are some suggestions:

1. Please upgrade to the latest CIFS Client. A.01.xx is no longer supported on HP-UX 11.23, and there have been many improvements since that version. If you decide to call support, they will probably ask you to upgrade before they spend a lot of time on the problem. Note that if you use the CIFS Client database feature, you should first read the Migration chapter in the Admin Guide, available at docs.hp.com.

2. To capture an intermittent problem on the network, use the "ring buffer" feature of "tethereal", the command-line interface to ethereal (and delivered with it). See the -a and -b options, to set the size and number of buffers, and -w to set the output file names. The only tricky part of this is to quickly terminate the capture when the desired event occurs. The method I usually use is to start tethereal in a shell script, get its PID, and then in a loop, sleep 1 second and then check a logfile for evidence that the event has occured. If it has, do "kill -s INT ". Do not use kill -9, or you will probably lose the output of the current buffer.

3. Sometimes you can get read or write errors as the result of file contention: another process, either on the CIFS Client host or some other client (including Windows) may try to access the same file on the server at the same time. This can cause the original CIFS Client process to stop accessing the file.

-Eric Raeburn