1833891 Members
1900 Online
110063 Solutions
New Discussion

What are these errors?

 
SOLVED
Go to solution
Dwyane Everts_1
Honored Contributor

What are these errors?

Hi, all...

Can anyone tell me what these errors are trying to say?

Mar 22 20:09:46 telnetd[24380]: getpid: peer died: Error 0
Mar 22 20:43:38 telnetd[21971]: Time out occurred in the initial option negotiation

I'm getting a ton of them. This RP8400 (HPUX 11.11) is accessed via telnet (migrating to ssh) by some 1500 users. And I'm finding it impossible to track down if this is caused by a particular user or if it is intermittent across all users.

Any suggestions are greatly appreciated....
Dwyane
7 REPLIES 7
harry d brown jr
Honored Contributor

Re: What are these errors?

Dwyane Everts_1
Honored Contributor

Re: What are these errors?

Harry,

Thanks for the quick response! My patches are all up-to-date. So, I have to assume the first error is user error. I've tried the logging in the past and was unable to determine the exact user or network associated with the problem (to much other stuff being logged to quickly).

What about the "negotiation" error? I didn't see a reference, nor can I find a reference, for that error.

Dwyane
Robert-Jan Goossens
Honored Contributor

Re: What are these errors?

Dwayne,

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

Document id: KBRC00014017

Maybe above doc gives you a clue.

Regards,
Robert-Jan
Dwyane Everts_1
Honored Contributor

Re: What are these errors?

Robert-Jan,

Thanks for the link, I've had that one bookmarked for quite a while, and have used it "religiously" in the past. Problem is, the logging level is either on full blast or off. And there is so much logging being done, it is difficult to correlate what messages go with which user session.

I'm pretty well convinced I have a user with a "flaky" NIC. I was hoping someone had a "trick" (easy way) to help figure out "who."

Dwyane
rick jones
Honored Contributor

Re: What are these errors?

since there is a one-to-one correspondence of telnet process to telnet connection, there is a one-to-one correspondence of telnet process to remote user, sooo ass-u-me-ing that telnetd/inetd are logging stuff completely enough, you should be able to see which remote user. Thankfully, the pid for the inetd making the logging entry:

Mar 24 10:36:35 tardy inetd[2017]: telnet/tcp: Connection from localhost (127.0.
0.1) at Thu Mar 24 10:36:35 2005

is after the fork - it is not the same as my main inetd daemon:

ps -ef | grep inetd
root 2035 2011 1 10:37:15 pts/16 0:00 grep inetd
root 2013 1 0 10:36:24 ? 0:00 inetd -l

whcih means that the pid (that number in the []'s) is I believe the same as the pid for what will be the telnetd. and indeed, it is:

Mar 24 10:38:37 tardy inetd[2037]: telnet/tcp: Connection from localhost (127.0.0.1) at Thu Mar 24 10:38:37 2005
Mar 24 10:38:40 tardy inetd[2053]: registrar/tcp: Connection from tardy (15.244.44.58) at Thu Mar 24 10:38:40 2005
$ ps -ef | grep telnetd
root 2037 2013 0 10:38:37 pts/ta 0:00 telnetd
raj 2059 2041 0 10:38:55 pts/ta 0:00 grep telnetd

so, all you have to do is match-up the numbers in the []'s and you will find your user. If you are concerned about the overhead of hostname lookups, if you are sufficiently patched, inetd takes an -s option which is like the -l option, but it does not try to do the PTR lookup to go from incoming IP address to remote hostname.
there is no rest for the wicked yet the virtuous have no pillows
Dwyane Everts_1
Honored Contributor

Re: What are these errors?

Rick...

WOW! If I didn't need a beer before, I need one now. :) Your solution looks viable, and appears to give me the desired results. Using your solution, I will generate a script to extract the data immediately upon detection. And have OVO monitor this issue.

Its happening frequently enough to suspect multiple PCs, or my server NIC (1 of 4).

Thanks!
Dwyane
rick jones
Honored Contributor
Solution

Re: What are these errors?

My money is on stuff other than the NIC. If you have a flaky NIC I would expect other problems to be logged as well like connections being dropped due to retransmission timeout or the like.

Lanadmin -g mibstats can retrieve statistics for the specified ppa - aka link. Make sure those are "clean"

BTW, there seems to be a telnetd option to change the option negotiation timeout. Described in the telnetd manpage. Doubtful that it would help unless someone has set it too low, but thought I'd mention it. (Perhaps someone else already did).
there is no rest for the wicked yet the virtuous have no pillows