What are these errors?

[Dwyane Everts_1]

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

[harry d brown jr]

see: http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1111582602971+28353475&threadId=247948

live free or die
harry d brown jr

[Dwyane Everts_1]

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]

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]

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]

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.

[Dwyane Everts_1]

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 · Accepted solution]

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).