Listing connected telnet sessions???
Lars O
On RH 7.2, how can I list all *connected* telnet sessions?
If a user just shuts his computer off while still in an active telnet
session, that "disconnected session" will remain logged in for 2 hours,
before it gets killed.
Pinging all stations returned by finger or w is not reliable, since some
stations may have re-logged in (still having a disconnected session
hanging).
Any help on this would be greatly appreciated!
Thanks,
Lars (loberg@remove_this samys.com)
Lurch
If you do:
netstat -pant
you'll get a list off connections, along with the process-id of the process
that holds that connection. Just kill it :o)
Hope this helped...
--
Home: http://users.skynet.be/bk333466/
OS: Sorcerer Linux (kernel 2.4.17)
X: BlackBox 0.62.0 (XFree86-4.2.0)
Lars O
> Lars O wrote:
>
> > Hi,
> >
> > On RH 7.2, how can I list all *connected* telnet sessions?
> >
> > If a user just shuts his computer off while still in an active telnet
> > session, that "disconnected session" will remain logged in for 2 hours,
> > before it gets killed.
> >
> > Pinging all stations returned by finger or w is not reliable, since some
> > stations may have re-logged in (still having a disconnected session
> > hanging).
>
> netstat -pant
> you'll get a list off connections, along with the process-id of the process
> that holds that connection. Just kill it :o)
>
> Hope this helped...
Thanks for your reply.
Unfortunatley netstat -pant does not tell you whether the
connection is actually connected (sounds funny). For example,
20 minutes ago, a computer connected via telnet was turned off
without first logging out. Here is the output of netstat -pant
for that session:
tcp 0 0 64.13.128.24:23 64.13.128.157:3244
ESTABLISHED 26101/in.telnetd: 8
After about 2 hours (tcp_keepalive_time), telnetd (I think) will
send a number of probe packages to determine if the session is
still alive, and kill it if it does not respond.
Isn't there a way for me to send my own "probe packages" or
similar to determine if the session is alive?? Like "pinging"
ip address + tcp-port?
/ Lars
gavron
check 'man last' - *may* help..
S C Rigler
tty. You would script something to kill the pid using that
tty when the user has reached a certain threshold of idle
time. You could differentiate between users logged in thru
telnet and those on the console by the "FROM" column..
-S
Lars O
> Will the output from "w" suffice? It lists idle time and the
> tty. You would script something to kill the pid using that
> tty when the user has reached a certain threshold of idle
> time. You could differentiate between users logged in thru
> telnet and those on the console by the "FROM" column..
>
> -S
>
> >send a number of probe packages to determine if the session is
> >still alive, and kill it if it does not respond.
> >
> >Isn't there a way for me to send my own "probe packages" or
> >similar to determine if the session is alive?? Like "pinging"
> >ip address + tcp-port?
> >
> >/ Lars
No, "w" only tells me the idle time. Many of the computers are idle
quite often, so I can't rely on that to determine if the sessions are
alive.
I think that the only way to determine if a session is alive is to
send some kind of "probe package" to it and see if it responds. But
how do I do that???
/ Lars
David Means
On Fri, 15 Feb 2002 17:16:01 -0500, Lars O Articulated:
--
No trees were killed in the sending of this message. However,
a large number of electrons were terribly inconvenienced.
--
UCE Stricly forbidden!
See UCE/Spam Policy here: http://www.the-means.net/Spam-Policy.html
Lars O
session is alive or not?? ("netstat -pant" does not give you this
information)
/ Lars
David Means <dmeans...@the-means.net> wrote in message news:<ffEb8.82295$TI5.4...@e3500-atl2.usenetserver.com>...
Raj
> So what parameters do you use to get netstat to tell you wheter a
> session is alive or not?? ("netstat -pant" does not give you this
> information)
>
> / Lars
I don't know if this helps, but I was recently re-compiling the kernel
and came across an option that reduces the keep-alives for tcp
connections from the default 2 hours to 5 minutes or something - perhaps
that is what you need to do?
Also, if you use ssh (which is recommended over telnet anyways) then the
ssh server has an option to send keepalives to the client to check for
the condition you describe. I have set that and rarely get a connection
'hang' for over an hour.
cheers!
Lars O
> I don't know if this helps, but I was recently re-compiling the kernel
> and came across an option that reduces the keep-alives for tcp
> connections from the default 2 hours to 5 minutes or something - perhaps
> that is what you need to do?
> Also, if you use ssh (which is recommended over telnet anyways) then the
> ssh server has an option to send keepalives to the client to check for
> the condition you describe. I have set that and rarely get a connection
> 'hang' for over an hour.
> cheers!
Yes, that would help as a work-around. I actually posted a question
about this last week, but got no answer. Here is what I wanted to do:
tcp_keepalive_intvl: 30 (default 75)
tcp_keepalive_probes: 5 (default 9)
tcp_keepalive_time: 300 (default 7200)
But I read in another posting that the "RFC's strictly forbids
tcp_keepalive_time being below 2 hours." Why??
Anyone has more data on this?
Thanks,
Lars
Raj
>
> But I read in another posting that the "RFC's strictly forbids
> tcp_keepalive_time being below 2 hours." Why??
>
> Anyone has more data on this?
>
i have no idea. check the net for more info.. in any case, if you can do
it, it won't hurt to recompile the kernel with the new options and see
what happens. Do you know what RFC # they referred to on the other
posting? Perhaps you could find that and see why it forbids it.
cheers!
> Thanks,
>
> Lars
Lars O
tcp_keepalive_time lower than 2 hours. What it states is:
"Keep-alive packets MUST only be sent when no data or acknowledgement
packets have been received for the connection within an interval. This
interval MUST be configurable and MUST default to no less than two
hours."
So there should not be a problem to lower the value.
Thanks to everyone who replied to my question!
/ Lars
Keith
[...]
I'm wondering whether setting the timeout so low will cause problems
with other services, such as NFS. Of course, if you don't use them it
won't really matter I guess...
Lars O
Yes, I am also a bit concerned about the effect on other services, but
I have not been able to find anything written about this.
I think that keepalive timers can cause trouble mainly when you have
unreliable links involved. E.g. even if a link goes down only for a
few minutes it could be enough to kill perfectly valid (but idle)
sessions (if the link went down just before the host started sending
probe packages).
Anyhow, I have implemented the lower keepalive settings in our
production environment now. So far, so good...
Thanks,
Lars
Mr. I.M. Kitty
Try netstat -nalp
--
-----------------------------------------------------------
From the Linux Box of WarpKat
Email: war...@nointegrity.org
Download my public key from:
http://www.nointegrity.org/pubkey/war...@nointegrity.org
(Public Key expires 01/08/2003)
-----------------------------------------------------------