Kill TCP session
rahan
kill is used to kill process.
How it's possible to kill a tcp session btw client and solaris server
without killing process ?
So, i have some tcp connexion to the application running on my solaris
server, and i need to know how it's possible to kill session btw one
client and my server.
Thank You very much for your help
Best Regards
Rahan
Brian Mac
Check out a utility called lsof - to the best of my knowledge it isn't
included with Solaris. It will list open files, including network
connections. The difference between it and netstat is that lsof will
list the PID . Here is a helpful (albeit brief) page that shows what
can be done with lsof:
http://www.akadia.com/services/lsof_intro.html
In your case, you could run something like:
lsof -iTCP@HostnameOrIPAddress:PortNumber
Thanks!
Brian
Rahan
I use lsof to print connexion, pid and process name but i don't think that
it provides options to kill session.
I will check again.
Thanks a lot
Best Regards
Rahan
"Brian Mac" <mcnama...@gmail.com> a écrit dans le message de
news:1154344476.0...@i3g2000cwc.googlegroups.com...
Ceri Davies
> rahan wrote:
>> Hi,
>>
>> kill is used to kill process.
>>
>> How it's possible to kill a tcp session btw client and solaris server
>> without killing process ?
>>
>> So, i have some tcp connexion to the application running on my solaris
>> server, and i need to know how it's possible to kill session btw one
>> client and my server.
> Check out a utility called lsof - to the best of my knowledge it isn't
> included with Solaris. It will list open files, including network
> connections. The difference between it and netstat is that lsof will
> list the PID .
The OP did ask for a way to drop the session without killing the process.
While OpenBSD and FreeBSD (at least), there is a utility called tcpdrop
which will do this. I don't think that Solaris has an equivalent,
although you could null route the client IP if you were happy to drop
all traffic between the client and server..
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
mediis
route add -host the.bad.ip.addr 127.0.0.1
Casper H.S. Dik
>While OpenBSD and FreeBSD (at least), there is a utility called tcpdrop
>which will do this. I don't think that Solaris has an equivalent,
>although you could null route the client IP if you were happy to drop
>all traffic between the client and server..
The kernel has the functionality to abort random TCP connections
using the TCP_IOC_ABORT_CONN; it is undocumented though it's usage can
be gleaned from the opensolaris sources.
Casper
Ceri Davies
Thanks for that pointer.
I did a quick and dirty port of tcpdrop which works on Solaris 9 at least
(I don't have any Solaris 10 machines with compilers installed). It can
be downloaded from http://shrike.submonkey.net/~ceri/util/tcpdrop-solaris/.
Richard L. Hamilton
Worked for me on:
Solaris 9, SPARC, latest patches, Sun C 5.7
Solaris Express build 41, SPARC, Sun C 5.7
However, the binary compiled on Solaris 9 did _not_ work on SX build 41;
I had to recompile.
I guess that's the sort of thing that can happen with undocumented
interfaces. :-)
--
mailto:rlh...@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
Casper H.S. Dik
>Thanks for that pointer.
>I did a quick and dirty port of tcpdrop which works on Solaris 9 at least
>(I don't have any Solaris 10 machines with compilers installed). It can
>be downloaded from http://shrike.submonkey.net/~ceri/util/tcpdrop-solaris/.
Note that because it is undocumented it also does not guarantee
binary compatibility; I think the S10 versions adds a zone identifier
in there somewhere.
It can also go away at any time but I have found it useful at times too.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Richard L. Hamilton
Casper H.S. Dik <Caspe...@Sun.COM> writes:
> Ceri Davies <ceri_...@submonkey.net> writes:
>
>>Thanks for that pointer.
>
>>I did a quick and dirty port of tcpdrop which works on Solaris 9 at least
>>(I don't have any Solaris 10 machines with compilers installed). It can
>>be downloaded from http://shrike.submonkey.net/~ceri/util/tcpdrop-solaris/.
>
> Note that because it is undocumented it also does not guarantee
> binary compatibility; I think the S10 versions adds a zone identifier
> in there somewhere.
>
> It can also go away at any time but I have found it useful at times too.
Yup, new field ac_zoneid at the end of the struct. Looks like it could
be either a specific zone id, or ALL_ZONES.
Question (not obvious just at a cursory glance): can one use
TCP_IOC_ABORT_CONN from within a local zone, and if so, would ac_zoneid
have to be set to the return value of getzoneid() (or would it,
dangerously, perhaps work on other zones too)? I can see that it would be
useful if the global zone could abort connections associated with any zone,
but I'd think one would really prefer that local zones could abort their
own, but only their own. What bothers me is I don't really see such a
restriction in the code, but maybe I'm not looking in the right place.
Casper H.S. Dik
>Question (not obvious just at a cursory glance): can one use
>TCP_IOC_ABORT_CONN from within a local zone, and if so, would ac_zoneid
>have to be set to the return value of getzoneid() (or would it,
>dangerously, perhaps work on other zones too)? I can see that it would be
>useful if the global zone could abort connections associated with any zone,
>but I'd think one would really prefer that local zones could abort their
>own, but only their own. What bothers me is I don't really see such a
>restriction in the code, but maybe I'm not looking in the right place.
Use the Source!
The TCP_IOC_ABORT_CONN ioctl is restricted to processes with the
"net_config" privilege; such processes do not exist in zones.
Richard L. Hamilton
Casper H.S. Dik <Caspe...@Sun.COM> writes:
>
>>Question (not obvious just at a cursory glance): can one use
>>TCP_IOC_ABORT_CONN from within a local zone, and if so, would ac_zoneid
>>have to be set to the return value of getzoneid() (or would it,
>>dangerously, perhaps work on other zones too)? I can see that it would be
>>useful if the global zone could abort connections associated with any zone,
>>but I'd think one would really prefer that local zones could abort their
>>own, but only their own. What bothers me is I don't really see such a
>>restriction in the code, but maybe I'm not looking in the right place.
>
> Use the Source!
>
> The TCP_IOC_ABORT_CONN ioctl is restricted to processes with the
> "net_config" privilege; such processes do not exist in zones.
>
Ok, I see that now:
in tcp.c:
24295 tcp_ioctl_abort_conn(queue_t *q, mblk_t *mp)
24296 {
[...]
24313 /* check permissions */
24314 if (secpolicy_net_config(iocp->ioc_cr, B_FALSE) != 0) {
24315 err = EPERM;
24316 goto out;
24317 }
That would make it difficult to change to allow a restricted (same zone as
caller) version for local zones insofar as even with that restriction
enforced, some additional restriction would be needed so that every
process wouldn't be allowed to clobber connections within its own zone.
I don't suppose there's a way to determine the the [er]uid of the process
that issued the listen() (or accept() or TLI/XTI equivalent s or whatever)
that created the connection? If that were possible, one could allow
anything in the same zone and with the same euid as the creator of a
connection to clobber connections without any special privs, or only procs
with net_config (in the global zone) to clobber any connection.
Maybe I'm just sentimental* and there's no reason to delegate what might
be a seldom-used capability...but I think I might be able to imagine times
when it might come in handy.
*in the old NCP (1822) days, some implementations actually had a command
to drop all connections to a particular remote host; handy sometimes when
something got hung.