slogin & telnet 60-minute timeout at remote computer. Why?
Ever since upgrading to woody 8 months ago,
both my slogin and telnet sessions lock after idling 60 minutes.
These sessions still work after 50 minutes idling,
but lock after 1 hour 10 minutes idling.
After 2 hours, the remote host ends
both the original "ssh" [telnet] and spawned "bash" processes.
Both the remote and local computers run Debian Linux,
and the remote Debian computer seems to cause the locking.
I would like my slogin working as before my upgrade to woody,
without idle timeouts every 60 minutes.
I welcome any suggestions.
Following are some of my many attempts and 35 hours of effort
to solve this problem.
These attempts almost [but nothing is absolute]
rule out timeouts arising from any of,
slogin and the spawned ssh daemon [or telnet]
bash shell
iptables and its conntrack
1. SLOGIN and TELNET
After my slogin [telnet] connection locks (at 1 hour)
and before it disappears (2 hours),
both "ssh" [in.telnetd] and its spawned "bash" shell
remain running processes on the remote Debian computer.
And "slogin" [telnet] remains a running process
on the local Debian computer.
From this, I conclude that ssh [telnet] has not timed-out,
and ssh [telnet] has not caused my local xterm to lock.
Additionally, this timeout problem occurs
with both slogin and telnet,
adding support that the problem does not lie in either.
2. BASH
If on the target computer I set "TMOUT=5",
5 seconds later I get the message,
timed out waiting for input: auto-logout
Because this message differs from the message I get
with a slogin or telnet timeout
after 120 minutes (60 minutes while locked),
Read from remote host bbmo.com: Connection timed out
then I conclude that my problem does not come
from the bash shell TMOUT variable.
3. IPTABLES/NETFILTER
The ultimate test with iptables would flush the firewall and check
for any timeout.
Unfortunately, the logs on my remote computer show numerous
nefarious connections attempts,
so I won't bring down iptables without disconnecting my DSL cable.
However, I have observed the following.
Iptable's/netfilter's connection tracking (conntrack)
for "-m state" base rules appears to work correctly,
since the third column of,
/proc/net/ip_conntrack
counts down by seconds from 5 days (hardcoded into the netfilter
file .../net/ipv4/netfilter/linux-2.5.17.tar.bz2),
432,000 #seconds
After the 428,400 second countdown mark (1 hour or 3600 seconds),
I still see netfilte's conntrack working;
indeed, after some time, I saw a count as low as
(just before 2 hours or 7200 seconds when this remote computer
removed the connection),
424,842 #seconds
Soon after this, the remote computer removed
both the "ssh" and "bash" processes, at which time this conntrack
count was reset to 5 hours,
432,000
then a few minutes later, this conntrack line was removed.
At that time, neither computer had any ghosts
of slogin [telnet] session, except in log files.
Here are two example conntrack lines I observed,
the first for ssh (sport=22), and the second for telnet (sport=223).
Remember, the third column represents the number of seconds
until netfilter times-out.
tcp 6 431811 ESTABLISHED \
src=199.129.208.230 dst=66.92.166.19 sport=724 dport=22 \
src=66.92.166.19 dst=199.129.208.230 sport=22 dport=724 \
[ASSURED] use=1
#
tcp 6 425116 ESTABLISHED \
src=199.129.208.230 dst=66.92.166.19 sport=2468 dport=23 \
src=66.92.166.19 dst=199.129.208.230 sport=23 dport=2468 \
[ASSURED] use=1
WORKAROUND: a process that displays on the local screen
from the remote screen can keep the connection open.
For example, the following process sends a message
from the remote computer to the local computer every 10 minutes,
keeping the connection open past even 2 hours.
while : ; do date; sleep 600; done
Both my remote computer and my local computer run Debian Linux.
The remote computer to which I slogin runs Debian's woody.
The local computer still runs Debian's potato.
The local potato computer can slogin to an AIX computer
and remain logged in for weeks.
I would like to do that same eternal slogin to my remote Debian woody computer.
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: