Telnet session stays open when device disconnects

[Jesse_13]

Hey guys, got a good one for you...

I'm running an app on Unix across a WAN. The app is accessed through telnet on wireless devices. Sometimes the devices lose there connection (various reasons) without logging out, and leave the session open. When the device reconnects, it starts a new session and the old one just stays out there. I need a way to close these sessions when the device disconnects. Any suggestions?

[James R. Ferguson]

Hi:

This is a common problem. Kill the old sessions with 'kill -hup '. You can script something that looks at the process table (with 'ps'), selects orphaned candidates and kills them:

# MIN=100;
# PIDS=`ps -el|awk -v MIN=$MIN '$3 > MIN && $5 = 1 && $12 ~/\?/ {print $4}'`
# kill -hup $PIDS

This gives back a list of processes that have been inherited by 'init'. The MIN value of 100 represents the beginning of uid values which represent 'application' users. You can adjust it to your tastes as long as the value does not circumscribe system or root processes.

Regards!

...JRF...

[Jesse_13]

I'm aware of the kill factor, but isn't there a cleaner way to do this? The host should recognize the device is no longer acknowledging... maybe I'm looking for too much... has anyone read about Rocks & Racks?

[Ron Kinner]

When this happens does
netstat -a | grep telnet
show that the old connection is still ESTABLISHED or stuck in one of the WAIT states? If it does and you are running HPUX 10.3 or higher you may be able to play with ndd to get the tcp/ip connections to drop a bit quicker.

Ron

[Jesse_13]

We are running HPUX 11... The connection stays ESTABLISHED.

[Ron Kinner · Accepted solution]

ndd -h tcp_keepalive_interval

tcp_keepalive_interval:

Interval for sending keep-alive probes.

If any activity has occurred on the connection or if there is
any unacknowledged data when the time-out period expires, the
timer is simply restarted. If the remote system has crashed
and rebooted, it will presumably know nothing about this
connection, and it will issue an RST in response to the ACK.
Receipt of the RST will terminate the connection.

If the keepalive packet is not ACK'd by the remote TCP, the normal
retransmission time-out will eventually exceed threshold R2,
and the connection will be terminated.

With this keepalive behavior, a connection can time-out and
terminate without actually receiving an RST from the remote TCP.
[10000, 10*24*3600000] Default: 2 * 3600000 (2 hours)

I expect the above is your problem. Can't imagine why I would want to leave an idle connection up for 2 hrs before checking to see if it were still alive. My routers usually hangup after 15 minutes of idleness.

ndd -set /dev/tcp tcp_keepalive_interval 600000

would set it to 10 minutes (units are milliseconds). You have to edit /etc/rc.config.d/nddconf to get the change to survive a reboot.

The second timer they are talking about is presuimably:

tcp_ip_abort_interval:

Second threshold timer for established connections.

When it must retransmit packets because a timer has expired,
TCP first compares the total time it has waited against two
thresholds, as described in RFC??1122, 4.2.3.5. If it has waited
longer than the second threshold, TCP terminates the connection.
[500,-] Default: 600000 (10 minutes)

So I guess it will still take 20 minutes to kill off an idle connection but that should be better than 2 hrs 10 minutes.

Ron