ttloop peer died
Tom Melvin
I have been seeing an increase in 'ttloop peer died' messages
in /usr/adm/syslog (on 5.0.6 and 5.0.7). The TA (107691) does
mention it but not in any detail
Anyone got any more information on the cause of this error and
which combination of the keepalive options can be tweeked to
reduce them.
Tom
--
========================================================================
Tom Melvin t...@tkrh.demon.co.uk http://www.tkrh.demon.co.uk
Veterinary Solutions Ltd Sysop Compuserve Unixforum
========================================================================
Jean-Pierre Radley
|
| I have been seeing an increase in 'ttloop peer died' messages
| in /usr/adm/syslog (on 5.0.6 and 5.0.7). The TA (107691) does
| mention it but not in any detail
Is TA115066 more relevant?
--
JP
Bela Lubkin
> I have been seeing an increase in 'ttloop peer died' messages
> in /usr/adm/syslog (on 5.0.6 and 5.0.7). The TA (107691) does
> mention it but not in any detail
>
> Anyone got any more information on the cause of this error and
> which combination of the keepalive options can be tweeked to
> reduce them.
The messages themselves aren't a problem. Are you seeing an effect that
_is_ a problem -- like user's sessions being dropped? Get a good
description of this (for instance, does their client just suddenly exit
in the middle of doing something? Or does it freeze up for a while,
then exit? Or does it only happen when they've been away from their
desk for a while, come back, find that the client window is gone?)
The most typical cause I've seen of the message is connection attempts
from a client that dies during the initial connection (due to a client
bug or misconfiguration). In which case they are just messages in a
log, not representing any problem at the Unix end.
>Bela<
Tom Melvin
Don't think so.
The customer is not complaining of failed login, it is a 15 user m/c I
would think the default 64 pseudo ttys are fine. Actually, just relooked
at syslog:
Oct 13 01:57:22 cvntry telnetd[28609]: ttloop: peer died: Unknown error
Oct 13 02:08:08 cvntry telnetd[28616]: ttloop: peer died: Unknown error
Oct 13 02:20:57 cvntry telnetd[28630]: ttloop: peer died: Unknown error
Oct 13 02:32:32 cvntry telnetd[28637]: ttloop: peer died: Unknown error
Oct 13 02:43:26 cvntry telnetd[28639]: ttloop: peer died: Unknown error
Oct 13 02:54:18 cvntry telnetd[28641]: ttloop: peer died: Unknown error
Oct 13 03:05:14 cvntry telnetd[28663]: ttloop: peer died: Unknown error
Oct 13 03:16:04 cvntry telnetd[28674]: ttloop: peer died: Unknown error
Oct 13 03:27:01 cvntry telnetd[28681]: ttloop: peer died: Unknown error
Oct 13 03:38:02 cvntry telnetd[28683]: ttloop: peer died: Unknown error
Oct 13 03:48:52 cvntry telnetd[28685]: ttloop: peer died: Unknown error
Oct 13 04:00:28 cvntry telnetd[28692]: ttloop: peer died: Unknown error
Oct 13 04:10:29 cvntry telnetd[28703]: ttloop: peer died: Unknown error
Oct 13 04:18:59 cvntry telnetd[28705]: ttloop: peer died: Unknown error
Oct 13 04:27:29 cvntry telnetd[28712]: ttloop: peer died: Unknown error
Oct 13 04:35:59 cvntry telnetd[28714]: ttloop: peer died: Unknown error
Oct 13 04:44:27 cvntry telnetd[28716]: ttloop: peer died: Unknown error
Oct 13 04:52:53 cvntry telnetd[28718]: ttloop: peer died: Unknown error
Oct 13 05:02:17 cvntry telnetd[28725]: ttloop: peer died: Unknown error
Oct 13 05:11:16 cvntry telnetd[28736]: ttloop: peer died: Unknown error
All these times are in the early am - they do not use the system over
night - those must be left over from during the day but then again,
the 13th was a monday, they also don't use the system on Sunday's
so I have no idea where those are comming from. Weird
Bela Lubkin
It could be some sort of an attack; or some device (like a network
printer) wigging out. Notice that the times are pretty evenly spaced:
about 10 minutes apart, until the last few which are about 8.5 minutes
apart. The regularity strongly suggests some sort of automated process.
You could put in a little watcher daemon, something like:
#!/bin/sh
while :; do
tail -0f /usr/adm/syslog | grep -q ttloop
date >> /usr/adm/ttloop-netstat
netstat -n -p tcp | fgrep '.23 ' >> /usr/adm/ttloop-netstat
done
You're looking for output that looks something like:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 127.0.0.1.23 127.0.0.1.1160 TIME_WAIT
Here I had done a `telnet localhost` and immediately disconnected. Your
mystery connections will probably be from a different host, and may be
in a different state than TIME_WAIT (but probably TIME_WAIT). The "-n"
flag skips hostname lookups, which could be slow in some cases, and
might possibly make it miss the actual lines you're interested in. Once
you have an idea of which lines are the mystery telnets, you can look
the names up witn `ping`, `host`, `nslookup`, etc.
>Bela<
Tom Melvin
> Tom Melvin wrote:
>
> > The customer is not complaining of failed login, it is a 15 user m/c I
> > would think the default 64 pseudo ttys are fine. Actually, just relooked
> > at syslog:
> >
> > Oct 13 01:57:22 cvntry telnetd[28609]: ttloop: peer died: Unknown error
Yes it was an user who decided to probe all the ports just to see if the
machines were still alive. The little script quickly showed where it was
coming from - thanks