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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]