- 论坛徽章:
- 1
|
错误 提示问题（急！！！！！！！！！！！！！！！！！！！）
Problem
Commands such as who(C), finger(C), and ps(C) may show established telnet sessions when the client end of the TCP connection no longer exists, for example, when the client computer crashes, is powered off or reset without first closing the telnet session. Established sessions may also be shown when network connectivity to the client has failed. There may also be errors in /usr/adm/syslog:
telnetd: ttloop peer died
The telnet server daemon, telnetd(ADMN), arranges to use TCP transport-level keepalive probes to distinguish an inactive client from a TCP connection for which the remote end of the connection no longer exists. When TCP finds a connection has been inactive for a specified period of time, it sends a keepalive probe to the client, and listens for a response. If there is no response to the probe, additional probes are sent at a specified frequency. If there is no response from the client after a specified number of probes have been sent, it is assumed that the connection has been lost, and the telnet session is closed. If the client responds to a probe, the session is kept alive. This sequence of events is repeated if the session remains or again becomes idle. The timing for the sequence of events is determined by the three parameters just mentioned: idle interval, probe frequency, and number of probes. These values may be specified by telnetd, or left at the system-wide defaults.
When the who and ps commands both show a telnet login as active, it is likely that they are correctly reporting a session that hasn't been closed by the client, and for which the sequence of events leading to automatic closing of the connection by the server, hasn't completed. That will be the case for an ordinary established connection over a properly functioning network. That will also be the case when keepalive probing hasn't yet completed for a client that has failed to disconnect properly, or with which connectivity has been lost. In the most insidious case, the client's TCP may not respond correctly to keepalive probes after failing to disconnect properly, and then rebooting. Rather than sending a reset response, the client sends an acknowledgement, causing the connection to be kept alive when it should have been closed. This article addresses the above cases. In particular, the "Solution" section of this article addresses how telnetd's keepalive parameters can be modified to minimize problems due to telnet clients that fail to disconnect properly.
When who shows a telnet user logged in, while ps shows that the session has in fact been closed, it is possible that /etc/utmp and related files have stale entries. Output from who and related commands is based on these files. The stale entries may be due to corruption in files that are read by utilities that update utmp, or to faulty third-party software. These cases are addressed in other technical articles in the SCO Support Library, listed at the end of this article. Note that it is possible to have both types of problem appear on the same system.
Solution
Use the following diagnostic to distinguish the two problem types just mentioned ("#" indicates the root command line prompt):
# kill -0 `who -u | awk '{print $7;}'`
Any output indicates a stale /etc/utmp entry associated with that process id. Consult other technical articles in this database, listed at the end of this article, for guidance in dealing with stale utmp entries. This article applies in cases for which the diagnostic produces no output.
The sending of keepalive probes can be configured to reduce the problem of telnet sessions that haven't been disconnected properly. Some experimentation may be necessary to find the configuration that works best with the clients on a given network. The parameters that may be configured are described in the Keepalives section of the telnetd(ADMN) man page:
Keepalives ++++++++++
Transport-level keepalive messages are enabled unless the -n option is present. The use of keepalive messages allows sessions to be timed out if the client crashes or becomes unreachable.
If keepalives are being used, several parameters may be controlled using the following options:
-k n The argument n specifies the time (in seconds) that a connection
must be idle before the first keepalive probe will be sent.
-K n The argument n specifies the interval (in seconds) between
keepalive probes if no response is received.
-N n The argument n specifies the number of unanswered keepalive probes
that will be sent prior to dropping the connection.
The default keepalive values corresponding to these options are controlled by the parameters tcp_keepidle (7200 seconds), tcp_keepintvl (75 seconds), and tcp_nkeep ( . These can be tuned on a system-wide basis using inconfig (ADMN). These options exist solely to provide finer control of keepalives on per application basis.
Note
The last paragraph of the man page excerpt above refers to system- wide defaults. The keepalive options provided by the telnet server daemon allow these system-wide keepalive parameters to be overridden for telnet connections, without affecting keepalive behavior of other applications.
The minimum value of 10 for -k is not documented in the man page. Values less than 10 for the -k flag will be ignored, and the default value will be used.
Because telnetd(ADMN) is started by inetd(ADMN), the keepalive flags need to be appended to the telnet line in /etc/inetd.conf.
As an example, the line:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd
would be edited with vi(C) to read:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd -k 30 -K 1 -N 6
Execute the following command to apply the new configuration:
# kill -1 `cat /etc/inetd.pid`
The values given in this example are chosen so that a session will be idle thirty seconds (-k 30) before the first probe is sent, will probe every second (-K 1) until a response is received, or will close the session if no response is received during five seconds of probing (-N 6 and -K 1).
The values in this example might apply for an intranet with fast and reliable connectivity, and a problem client that answers keepalive probes incorrectly. If the client reboots quickly, these aggressive values may be of no avail. A shorter idle time may be configured, down to the minimum value of 10 for -k, but this will further burden the network with keepalive probe traffic, possibly leading to network performance problems.
A second example illustrates possible values for a slower and less reliable Internet connection, with a client that correctly responds to keepalive probes:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd -k 60 -K 30 -N 5
In this case, a session will be idle one minute (-k 60) before the first probe is sent, will probe every thirty seconds (-K 30) until a response is received, or will close the session if no response is received during two minutes of probing (-N 5 and -K 30).
The number of seconds of probing is given by:
K * ( N -1 )
The number of seconds from the last activity to the last probe is given by:
k + ( K * ( N -1 ))
This is over two hours using the system defaults, and 35 seconds and three minutes, respectively, in the examples.
A third example illustrates an alternative approach: putting multiple telnet services on different ports, with different sets of keepalive parameters, and configuring only misbehaved clients to come in through a fast-timeout port.
A fast-timeout telnet port is set up in /etc/services on a port not already in use (823 in this example):
telnet2 823/tcp # fast-timeout telnet port
A corresponding entry is made in /etc/inetd.conf, with keepalive values appropriate for the clients that will be configured to use the fast-timeout telnet port:
telnet stream tcp nowait NOLUID /etc/telnetd telnetd
telnet2 stream tcp nowait NOLUID /etc/telnetd telnetd -k 30 -K 1 -N 6
Apply the server configuration as in the other examples, and configure the misbehaved telnet clients to use port 823 instead of 23. It is important to note that some telnet clients cannot be configured to connect to ports other than the default port 23. The approach suggested in this third example cannot be used with such clients.
The examples are intended to be illustrative; the values chosen will depend on the specific situation. Some experimentation may be required to determine the best values. |
|
免费注册
发表于 2004-08-24 14:09
