telnetd: reset by peer

[j773303]

OS: 10.20
S800
npty: 200
nstrpty:200

I got the below message,
telnetd[2289]: recv: Connection reset by peer

I have installd the PHNE_24821, but the problem still occurs. Does anyon has the experiecne to fix this problem. Thanks.

[Robert-Jan Goossens]

Hi,

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063203773

Document description: Networking: telnetd[16017]: recv: Connection reset by peer
Document id: A5794011

HTH,
Robert-Jan

[T G Manikandan]

check for the patches

PHNE_7514
PHNE_10424
PHNE_14086
PHNE_12709
PHNE_9121

check the doc A5794011

[Fabio Ettore]

Hi,

try the following actions:

# cd /dev/pts
# rm *
# insf -e -s 200
# insf -d pty -n 200

I hope this helps you.

Best regards,
Ettore

[j773303]

I've try to install below patch, but OS 10.20 seems can not apply it. Why?
PHNE_7514
PHNE_10424
PHNE_14086
PHNE_12709
PHNE_9121

[T G Manikandan]

the patches look for 10.10 and below that.For 10.20

PHNE_14087:
PHNE_24821:
PHNE_7671:
PHNE_9122:

[Fabio Ettore]

TG is right and doc is lying!
Below other equivalent patches for HP-UX 10.20:

PHNE_24821 telnetd patch
PHNE_13413 telnet kernel
PHNE_22085 PTY Streams
PHNE_20747 inetd patch

Best regards,
Ettore

[j773303]

I've already install patch that mentioned above. But the "recv: Connection reset by peer" still occurs in syslog.log . Does anyone has the other solution for fixing this problem? Is it possible Lan card problem? Thanks.

[j773303]

Is it possible lan card problem. because of the linkloop with error. Thanks.

linkloop 0x080009D2525D

Link connectivity to LAN station: 0x080009D2525D
error: expected primitive 0x30, got DL_ERROR_ACK
dl_error_primitive = 0x2d
dl_errno = 0x04
dl_unix_errno = 57
error - did not receive data part of message

[Fabio Ettore]

I think that a lot of reasons could give in syslog.log that message.
Have you search out resolution problems by nslookup?
Try nslookup on name servers in /etc/resolv.conf (of course if it exist); do they reply?

Also try to reset lan card:
lanadmin ---> lan card ---> reset

Best regards,
Ettore

[Suresh Patoria]

Hi,

I think this error because of network delay
Please see your network

Thanx

[j773303]

How to confirm if it is a network delay? Thanks.

[rick jones]

Sometimes, connection reset by peer means exactly that :) the remote end reset the TCP connection.

Sometimes, that stems from the remote discovering some form of protocol error.

Sometimes, that stems from broken client code that enables and abortive close of the connection.

You might take a couple of netstat -p tcp snapshots and then dake the delta with "beforeafter" from ftp.cup.hp.com/dist/networking/tools/

then you might compare that with what is in ftp:://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt

[Sean OB_1]

In my experience this is often caused by things outside of your server. We see this a lot when we are having other network issues.

For example when the recent set of virus' that scanned other machines hit we saw this a lot because of the intense traffic load on the network.

Once we cleared the network we stopped seeing these errors.

Are your users reporting problems with their apps?

[Jim Butler]

Check to see if this error is happening at certain time intervals. I once had a script running in cron, which when run caused a telnet HUP, and this message was in my syslog. The fix was to modify the script and pipe the error to /dev/null.

Drove me nuts for a bit until I decided to do something about it.

Good Luck

[T G Manikandan]

I would also suggest to check that the duplex/speed matches at both ends(switch & server side).

Just check if there are collisions
by doing a
#lanadmin
>lan
>dis

Revert on the same

[rick jones]

_collisions_ in and of themselves will not imply a duplex mismatch. "collisions" are a normal part of half-duplex operation.

what _is_ a decent signal of a _possible_ duplex mismatch is _late_ collisions, which is a rather different beast entirely.

if the link is full-duplex, the "signal" of a possible duplex mismatch would be FCS errors.

also all else being equal, i would think that if the problem were at the link-level with a duplex mismatch, that would affect both inbound and outbound traffic and one would see a more or less even mix of connection reset by peer and connection timed-out.