Ravi Swaminathan
2005-Jun-29 15:04 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi , I have posted DTrace script to snoop tcp traffic and also provided a wrapper script for it to filter out unwanted traffic. http://blogs.sun.com/roller/comments/raviswam/Weblog/tcp_snoop_using_dtrace Please let me know if you have any feedback/comments on this. Thanks Ravi
Brendan Gregg
2005-Jun-29 16:27 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
G''Day Ravi, On Wed, 29 Jun 2005, Ravi Swaminathan wrote:> Hi , > > I have posted DTrace script to snoop tcp traffic and also provided a > wrapper script > for it to filter out unwanted traffic. > > http://blogs.sun.com/roller/comments/raviswam/Weblog/tcp_snoop_using_dtrace > > Please let me know if you have any feedback/comments on this.The blog has really messed it up - could you post it to this list? Just from reading it I believe it doesn''t match Process ID or executable name correctly - have you tested this with a variety of traffic including inbound telnet? thanks, Brendan
Ravi Swaminathan
2005-Jun-29 23:55 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi Brendan, I have attahed the script here. Brendan I have tested this with telnet and sendmail . The reason you do not see any filter for matching any pid or execname is because its all part of $filter variable (shell variable) which is dynamically built using the user inputs -This is done in the shell script -. By default filter is initalized to "pid==pid" , then based on user input to the shell script filter variable get overwritten. For eg ./snoop1.ksh -e telnet -p 1234 would generate a value of ((execname == "telnet" )) && pid==1234 for the filter variable This variable is then used in the DTrace "here" script as / arg0 && $filter / so we end up with / arg0 && ((execname == "telnet" )) && pid==1234 / Please le me know If I missed something. Thanks Ravi Brendan Gregg wrote:>G''Day Ravi, > >On Wed, 29 Jun 2005, Ravi Swaminathan wrote: > > > >>Hi , >> >>I have posted DTrace script to snoop tcp traffic and also provided a >>wrapper script >>for it to filter out unwanted traffic. >> >>http://blogs.sun.com/roller/comments/raviswam/Weblog/tcp_snoop_using_dtrace >> >>Please let me know if you have any feedback/comments on this. >> >> > >The blog has really messed it up - could you post it to this list? > >Just from reading it I believe it doesn''t match Process ID or executable >name correctly - have you tested this with a variety of traffic including >inbound telnet? > >thanks, > >Brendan > > >-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: snoop.ksh.txt URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20050630/9d600285/attachment.txt>
Brendan Gregg
2005-Jun-30 02:38 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
G''Day Ravi, On Thu, 30 Jun 2005, Ravi Swaminathan wrote:> Hi Brendan, > > I have attahed the script here. > > Brendan I have tested this with telnet and sendmail . > > The reason you do not see any filter for matching any pid or execname is > because its all part of $filter variable (shell variable) which is > dynamically > built using the user inputs -This is done in the shell script -.No, I did see that. I''m aware of how wrapping dtrace in scripts works. Here is the output of your script on telnet traffic, where it misidentifies "sched" with PID 0 as the process responsible, ================================Begin===================================(0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] ------------------------------------------------------------------------- [...] ====================================END================================= ================================Begin===================================(0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] ------------------------------------------------------------------------- [...] And the same for ssh, ================================Begin===================================(0 sched tcp_input)192.168.1.5:22 > 192.168.1.1:45455 [TCPS_ESTABLISHED] ------------------------------------------------------------------------- [...] And port 6000 traffic wasn''t picked up at all. Brendan
Ravi Swaminathan
2005-Jun-30 04:00 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi Brendan, You see pid=0 and execname == "sched" because this is the process responsible to respond for services defined in /etc/services (since 23 -telnet and 22 ssh are defined in /etc/services) and this is what we should be expecting , Right ? About port 6000 can you let me know what parameters are being passed to the script. Thanks Ravi Brendan Gregg wrote:>G''Day Ravi, > >On Thu, 30 Jun 2005, Ravi Swaminathan wrote: > > > >>Hi Brendan, >> >>I have attahed the script here. >> >>Brendan I have tested this with telnet and sendmail . >> >>The reason you do not see any filter for matching any pid or execname is >>because its all part of $filter variable (shell variable) which is >>dynamically >>built using the user inputs -This is done in the shell script -. >> >> > >No, I did see that. I''m aware of how wrapping dtrace in scripts works. > >Here is the output of your script on telnet traffic, where it >misidentifies "sched" with PID 0 as the process responsible, > >================================Begin===================================>(0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] > >------------------------------------------------------------------------- >[...] > >====================================END=================================> >================================Begin===================================>(0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] > >------------------------------------------------------------------------- >[...] > > >And the same for ssh, > >================================Begin===================================>(0 sched tcp_input)192.168.1.5:22 > 192.168.1.1:45455 [TCPS_ESTABLISHED] > >------------------------------------------------------------------------- >[...] > > >And port 6000 traffic wasn''t picked up at all. > >Brendan > >_______________________________________________ >dtrace-discuss mailing list >dtrace-discuss at opensolaris.org > >
Ravi Swaminathan
2005-Jul-01 01:58 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi , After a lot of feedback about the source code not appearing correctly on the Blog site, I have updated the website and cleaned it up to the best of my ability. I am still working with experts to fix cut-d''.'' -f appearing as cut <del>''.''</del> on the website. Thanks for all the feedback . Cheers Ravi
Brendan Gregg
2005-Jul-01 03:19 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
G''Day Ravi, Let me be clear about something to start with - I think posting this script to dtrace-discuss is the right thing to do so we can discuss it and sort out problems before it''s any more ''public''. So I am glad you did... On Thu, 30 Jun 2005, Ravi Swaminathan wrote:> Hi Brendan, > > You see pid=0 and execname == "sched" because this is the process > responsible to respond for services defined in /etc/services > (since 23 -telnet and 22 ssh are defined in /etc/services) and this > is what we should be expecting , Right ?No, that''s completely wrong.> About port 6000 can you let me know what parameters are being passed > to the script.Hang on - are *you* able to snoop port 6000 traffic with the script? By now customers will be using this script and believing it gives them correct data. Your description starts with, "Capability This script can snoop on incoming and outgoing TCP /IP v4 traffic. This script can filter out traffic based on Process ID..." Ok, that''s wrong. I''m worried because I know customers find these scripts and then believe their output. They may well base important decisions on that. Or, they may become confused by the incorrect data and hassle other Sun staff. To make matters worse, you work @Sun - so customers are indeed likely to believe what you have written without question. Please test the script. Please make it clear what it can and can''t do. Oh, and PLEASE stop doing this, #pragma D option bufsize=256m You realise that this is PER CPU? Brendan> Thanks > > Ravi > > > > Brendan Gregg wrote: > > >G''Day Ravi, > > > >On Thu, 30 Jun 2005, Ravi Swaminathan wrote: > > > > > > > >>Hi Brendan, > >> > >>I have attahed the script here. > >> > >>Brendan I have tested this with telnet and sendmail . > >> > >>The reason you do not see any filter for matching any pid or execname is > >>because its all part of $filter variable (shell variable) which is > >>dynamically > >>built using the user inputs -This is done in the shell script -. > >> > >> > > > >No, I did see that. I''m aware of how wrapping dtrace in scripts works. > > > >Here is the output of your script on telnet traffic, where it > >misidentifies "sched" with PID 0 as the process responsible, > > > >================================Begin===================================> >(0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] > > > >------------------------------------------------------------------------- > >[...] > > > >====================================END=================================> > > >================================Begin===================================> >(0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] > > > >------------------------------------------------------------------------- > >[...] > > > > > >And the same for ssh, > > > >================================Begin===================================> >(0 sched tcp_input)192.168.1.5:22 > 192.168.1.1:45455 [TCPS_ESTABLISHED] > > > >------------------------------------------------------------------------- > >[...] > > > > > >And port 6000 traffic wasn''t picked up at all. > > > >Brendan > > > >_______________________________________________ > >dtrace-discuss mailing list > >dtrace-discuss at opensolaris.org > > > > > >
Ravi Swaminathan
2005-Jul-01 06:10 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi Brendan, Just to let you know , I am working on this and will feedback with what test I have already carried out. Thanks Ravi Brendan Gregg wrote:>G''Day Ravi, > >Let me be clear about something to start with - I think posting this >script to dtrace-discuss is the right thing to do so we can discuss it >and sort out problems before it''s any more ''public''. So I am glad you >did... > >On Thu, 30 Jun 2005, Ravi Swaminathan wrote: > > > >>Hi Brendan, >> >>You see pid=0 and execname == "sched" because this is the process >>responsible to respond for services defined in /etc/services >>(since 23 -telnet and 22 ssh are defined in /etc/services) and this >>is what we should be expecting , Right ? >> >> > >No, that''s completely wrong. > > > >>About port 6000 can you let me know what parameters are being passed >>to the script. >> >> > >Hang on - are *you* able to snoop port 6000 traffic with the script? > >By now customers will be using this script and believing it gives them >correct data. Your description starts with, > > "Capability > > This script can snoop on incoming and outgoing TCP /IP v4 traffic. This > script can filter out traffic based on Process ID..." > >Ok, that''s wrong. > >I''m worried because I know customers find these scripts and then believe >their output. They may well base important decisions on that. Or, they may >become confused by the incorrect data and hassle other Sun staff. To make >matters worse, you work @Sun - so customers are indeed likely to believe >what you have written without question. > >Please test the script. Please make it clear what it can and can''t do. > >Oh, and PLEASE stop doing this, > > #pragma D option bufsize=256m > >You realise that this is PER CPU? > >Brendan > > > > >>Thanks >> >>Ravi >> >> >> >>Brendan Gregg wrote: >> >> >> >>>G''Day Ravi, >>> >>>On Thu, 30 Jun 2005, Ravi Swaminathan wrote: >>> >>> >>> >>> >>> >>>>Hi Brendan, >>>> >>>>I have attahed the script here. >>>> >>>>Brendan I have tested this with telnet and sendmail . >>>> >>>>The reason you do not see any filter for matching any pid or execname is >>>>because its all part of $filter variable (shell variable) which is >>>>dynamically >>>>built using the user inputs -This is done in the shell script -. >>>> >>>> >>>> >>>> >>>No, I did see that. I''m aware of how wrapping dtrace in scripts works. >>> >>>Here is the output of your script on telnet traffic, where it >>>misidentifies "sched" with PID 0 as the process responsible, >>> >>>================================Begin===================================>>>(0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] >>> >>>------------------------------------------------------------------------- >>>[...] >>> >>>====================================END=================================>>> >>>================================Begin===================================>>>(0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED] >>> >>>------------------------------------------------------------------------- >>>[...] >>> >>> >>>And the same for ssh, >>> >>>================================Begin===================================>>>(0 sched tcp_input)192.168.1.5:22 > 192.168.1.1:45455 [TCPS_ESTABLISHED] >>> >>>------------------------------------------------------------------------- >>>[...] >>> >>> >>>And port 6000 traffic wasn''t picked up at all. >>> >>>Brendan >>> >>>_______________________________________________ >>>dtrace-discuss mailing list >>>dtrace-discuss at opensolaris.org >>> >>> >>> >>> >> >> > > > > > >
Ravi Swaminathan
2005-Jul-01 07:29 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi Brendan,
Sorry about the long e-mail I would rather be sure this time,
since Brendan''s email is quite serious.
My Test case
========
CASE I - execname test
================Window - I
------------
# ./snoop1.ksh -e telnet -E sendmail
Verify Paramters
In Verify...
Build Filter
build filter
NOW BUILDING ...
((execname == "telnet" ) || (execname == "sendmail" ))
Window - II
-------------
# telnet localhost smtp
Trying 127.0.0.1...
Connected to localhost.
Escape character is ''^]''.
220 ipalppo1.east.sun.com ESMTP Sendmail 8.13.3+Sun/8.13.3; Fri, 1 Jul
2005 02:26:21 -0400 (EDT)
HELP
214-2.0.0 This is sendmail version 8.13.3+Sun
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation contact Sun Microsystems
214-2.0.0 Technical Support.
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
quit
221 2.0.0 ipalppo1.east.sun.com closing connection
Connection to localhost closed by foreign host.
Output
--------
================================Begin===================================(5206
telnet tcp_output)129.152.221.90:22 > 129.159.197.62:52997
[TCPS_ESTABLISHED]
(5206 telnet tcp_input)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_ESTABLISHED]
(5206 telnet tcp_input)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_ESTABLISHED]
(5207 sendmail tcp_input)127.0.0.1:38955 > 0.0.0.0:0 [TCPS_BOUND]
(5207 sendmail tcp_output)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_ESTABLISHED]
(5206 telnet tcp_output)127.0.0.1:38954 > 127.0.0.1:25 [TCPS_ESTABLISHED]
(5207 sendmail tcp_output)129.152.221.90:22 > 129.159.197.62:52997
[TCPS_ESTABLISHED]
(5207 sendmail tcp_output)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_ESTABLISHED]
(5206 telnet tcp_input)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_TIME_WAIT]
(5207 sendmail tcp_output)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_ESTABLISHED]
(5207 sendmail tcp_input)127.0.0.1:38954 > 127.0.0.1:25 [TCPS_CLOSE_WAIT]
(5207 sendmail tcp_input)127.0.0.1:25 > 127.0.0.1:38954 [TCPS_FIN_WAIT_2]
Picks up correct execnames.
Qusetion ?
Why do you feel IPV6 is not being filtered out.
I have a hardcoded condition saying
/ self->tcp->tcp_ipversion== IPV4_VERSION /
as part of filter I have manually verfied this value and this works
correctly,
unfortunately I do not have any H/W I can test this out. So how will
IPV6 traffic be displayed if it has been filtered out
CASE - II
=======PID test
=====# ps -ef | grep 22667 | grep -v grep
root 22669 22667 0 11:40:32 pts/17 0:00 /bin/sh
/usr/bin/imqbrokerd -javahome /usr/jdk/entsys-j2se -varhome /var/opt/SU
root 22667 1 0 11:40:27 pts/17 6:04
/opt/SUNWappserver/appserver/lib/appservDAS domain1
# ./snoop1.ksh -p 22667
Verify Paramters
In Verify...
Build Filter
build filter
NOW BUILDING ...
pid==22667
execute_dtrace
(22667 appservDAS tcp_output)127.0.0.1:39073 > 127.0.0.1:45320
[TCPS_ESTABLISHED]
(22667 appservDAS tcp_input)127.0.0.1:45320 > 127.0.0.1:39073
[TCPS_ESTABLISHED]
(22667 appservDAS tcp_input)127.0.0.1:45320 > 127.0.0.1:39073
[TCPS_ESTABLISHED]
(22667 appservDAS tcp_output)127.0.0.1:39073 > 127.0.0.1:45320
[TCPS_ESTABLISHED]
Also verified
# pfiles 22667 | egrep "39073|45320"
sockname: AF_INET 127.0.0.1 port: 45320
sockname: AF_INET 127.0.0.1 port: 45320
Note : execname,pid,port# are all picked up correctly.
CASE III
======PORT test
(your case for port 6000 , I tested this for port 9010)
# netstat -an | grep 9010
*.9010 *.* 0 0 65536 0 LISTEN
./snoop1.ksh -o 6010
Verify Paramters
In Verify...
Build Filter
build filter
NOW BUILDING ...
(((BSWAP_16(self->p->th_sport)==6010 ||
BSWAP_16(self->p->th_dport)==6010)))
execute_dtrace
(5523 telnet tcp_input)127.0.0.1:6010 > 127.0.0.1:39214 [TCPS_ESTABLISHED]
(5523 telnet tcp_input)127.0.0.1:6010 > 127.0.0.1:39214 [TCPS_ESTABLISHED]
(5523 telnet tcp_output)127.0.0.1:39214 > 127.0.0.1:6010 [TCPS_ESTABLISHED]
(5523 telnet tcp_input)127.0.0.1:6010 > 127.0.0.1:39214 [TCPS_CLOSE_WAIT]
# netstat -an | grep LISTEN | grep 6010
127.0.0.1.6010 *.* 0 0 65536 0 LISTEN
CASE -- IMPT
==========
For port 22 (ports listed in /etc/services) - The Bone of contention
==========================
(0 sched tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_ESTABLISHED]
(0 sched tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_ESTABLISHED]
(5604 sshd tcp_input)127.0.0.1:39338 > 127.0.0.1:22 [TCPS_CLOSE_WAIT]
(5603 telnet tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_FIN_WAIT_2]
(5603 telnet tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_TIME_WAIT]
My explanation on why this is correct is since this is a loop back traffic
it gets redirected back which is done by sched, so this is correct.
When you snoop the traffic going out of the box , source targe on diffrent
boxes the execname is displayed correctly.
# ./snoop1.ksh -p 3246
Verify Paramters
In Verify...
Build Filter
build filter
NOW BUILDING ...
pid==3246
execute_dtrace
(3246 sshd tcp_output)129.152.221.90:22 > 129.159.197.62:52994
[TCPS_ESTABLISHED]
(3246 sshd tcp_output)129.152.221.90:22 > 129.159.197.62:52994
[TCPS_ESTABLISHED]
(3246 sshd tcp_output)129.152.221.90:22 > 129.159.197.62:52994
[TCPS_ESTABLISHED]
(3246 sshd tcp_output)129.152.221.90:22 > 129.159.197.62:52994
[TCPS_ESTABLISHED]
# pfiles 3246 | grep port
sockname: 129.152.221.90 port: 22
peername: 129.159.197.62 port: 52994
I would really appreciate if you could let me know where the script is
failing.
#pragma D option bufsize=256m
Is something I learned from this discussion - Thank you. :)
I will not make this mistake again.
Thanks
Ravi
Brendan Gregg wrote:
>G''Day Ravi,
>
>Let me be clear about something to start with - I think posting this
>script to dtrace-discuss is the right thing to do so we can discuss it
>and sort out problems before it''s any more
''public''. So I am glad you
>did...
>
>On Thu, 30 Jun 2005, Ravi Swaminathan wrote:
>
>
>
>>Hi Brendan,
>>
>>You see pid=0 and execname == "sched" because this is the
process
>>responsible to respond for services defined in /etc/services
>>(since 23 -telnet and 22 ssh are defined in /etc/services) and this
>>is what we should be expecting , Right ?
>>
>>
>
>No, that''s completely wrong.
>
>
>
>>About port 6000 can you let me know what parameters are being passed
>>to the script.
>>
>>
>
>Hang on - are *you* able to snoop port 6000 traffic with the script?
>
>By now customers will be using this script and believing it gives them
>correct data. Your description starts with,
>
> "Capability
>
> This script can snoop on incoming and outgoing TCP /IP v4 traffic. This
> script can filter out traffic based on Process ID..."
>
>Ok, that''s wrong.
>
>I''m worried because I know customers find these scripts and then
believe
>their output. They may well base important decisions on that. Or, they may
>become confused by the incorrect data and hassle other Sun staff. To make
>matters worse, you work @Sun - so customers are indeed likely to believe
>what you have written without question.
>
>Please test the script. Please make it clear what it can and can''t
do.
>
>Oh, and PLEASE stop doing this,
>
> #pragma D option bufsize=256m
>
>You realise that this is PER CPU?
>
>Brendan
>
>
>
>
>>Thanks
>>
>>Ravi
>>
>>
>>
>>Brendan Gregg wrote:
>>
>>
>>
>>>G''Day Ravi,
>>>
>>>On Thu, 30 Jun 2005, Ravi Swaminathan wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi Brendan,
>>>>
>>>>I have attahed the script here.
>>>>
>>>>Brendan I have tested this with telnet and sendmail .
>>>>
>>>>The reason you do not see any filter for matching any pid or
execname is
>>>>because its all part of $filter variable (shell variable) which
is
>>>>dynamically
>>>>built using the user inputs -This is done in the shell script -.
>>>>
>>>>
>>>>
>>>>
>>>No, I did see that. I''m aware of how wrapping dtrace in
scripts works.
>>>
>>>Here is the output of your script on telnet traffic, where it
>>>misidentifies "sched" with PID 0 as the process
responsible,
>>>
>>>================================Begin===================================>>>(0
sched tcp_input)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED]
>>>
>>>-------------------------------------------------------------------------
>>>[...]
>>>
>>>====================================END=================================>>>
>>>================================Begin===================================>>>(0
sched tcp_output)192.168.1.5:23 > 192.168.1.1:36699 [TCPS_ESTABLISHED]
>>>
>>>-------------------------------------------------------------------------
>>>[...]
>>>
>>>
>>>And the same for ssh,
>>>
>>>================================Begin===================================>>>(0
sched tcp_input)192.168.1.5:22 > 192.168.1.1:45455 [TCPS_ESTABLISHED]
>>>
>>>-------------------------------------------------------------------------
>>>[...]
>>>
>>>
>>>And port 6000 traffic wasn''t picked up at all.
>>>
>>>Brendan
>>>
>>>_______________________________________________
>>>dtrace-discuss mailing list
>>>dtrace-discuss at opensolaris.org
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
Brendan Gregg
2005-Jul-01 13:50 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
G''Day Ravi, My very first email said, "Just from reading it I believe it doesn''t match Process ID or executable name correctly - have you tested this with a variety of traffic including inbound telnet?" Ok, please demonstrate inbound telnet. This is what I get with your script, # snoop.ksh -O 23 Verify Paramters In Verify... Build Filter build filter NOW BUILDING ... (((BSWAP_16(self->p->th_dport)==23 || BSWAP_16(self->p->th_sport)==23))) execute_dtrace (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (14681 in.telnetd tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_output)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] (0 sched tcp_input)192.168.1.5:23 > 192.168.1.1:43611 [TCPS_ESTABLISHED] SOME of it is "in.telnetd", but MOST of it is reported as "sched" PID 0.> CASE III > ======> PORT test > > (your case for port 6000 , I tested this for port 9010)# snoop.ksh -O 6000 Verify Paramters In Verify... Build Filter build filter NOW BUILDING ... (((BSWAP_16(self->p->th_dport)==6000 || BSWAP_16(self->p->th_sport)==6000))) execute_dtrace dtrace: buffer size lowered to 8m ^C Nothing. # snoop.ksh -o 6000 Verify Paramters In Verify... Build Filter build filter NOW BUILDING ... (((BSWAP_16(self->p->th_sport)==6000 || BSWAP_16(self->p->th_dport)==6000))) execute_dtrace dtrace: buffer size lowered to 8m ^C Nothing. # snoop port 6000 Using device /dev/rtls0 (promiscuous mode) mars -> jupiter XWIN C port=43645 test\r\n jupiter -> mars XWIN R port=43645 jupiter -> mars XWIN R port=43645 mars -> jupiter XWIN C port=43645 mars -> jupiter XWIN C port=43645 jupiter -> mars XWIN R port=43645 But the traffic is certainly there!> CASE -- IMPT > ==========> > > For port 22 (ports listed in /etc/services) - The Bone of contention > ==========================Arugh! If /etc/services ports are the bone of your contention - it''s a pretty big bone.> (0 sched tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_ESTABLISHED] > (0 sched tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_ESTABLISHED] > (5604 sshd tcp_input)127.0.0.1:39338 > 127.0.0.1:22 [TCPS_CLOSE_WAIT] > (5603 telnet tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_FIN_WAIT_2] > (5603 telnet tcp_input)127.0.0.1:22 > 127.0.0.1:39338 [TCPS_TIME_WAIT] > > > My explanation on why this is correct is since this is a loop back traffic > it gets redirected back which is done by sched, so this is correct.Arugh!!! Will you stop trying to say it''s correct!!!??? It''s NOT correct! Even if your story was correct - if you say, "This script can filter out traffic based on Process ID" then customers are going to expect that if it''s ssh traffic, then ssh or sshd will be the process identified.> When you snoop the traffic going out of the box , source targe on diffrent > boxes the execname is displayed correctly.Outbound, mostly. Inbound traffic is asynchronous to the process. Brendan
Wee Yeh Tan
2005-Jul-04 02:11 UTC
[dtrace-discuss] TCP Snoop & wrapper shell script posted
Hi Brendan & all, I was trying to do something similiar but at a much reduced scale. I am interested in matching incoming traffic to the program/thread that will finally receive that data. My primitive script is reporting the stolen context of the firing CPU ala Ravi''s script. Is there a way to identify quickly who the receipient is short of looping around the output of "pfiles" and then targeting the pid for activity? A io-net provider similiar to io provider will be great :). -- Just me, Wire ...