G''Day Folks, The following is my first release of udpsnoop.d - to track UDP network I/O by process, # udpsnoop.d UID PID LADDR LPORT DR RADDR RPORT SIZE CMD 0 27127 192.168.1.5 35534 -> 192.168.1.1 53 29 nslookup 0 27127 192.168.1.5 35534 <- 192.168.1.1 53 181 nslookup 1 221 192.168.1.5 111 <- 192.168.1.1 37524 56 rpcbind 1 221 192.168.1.5 111 -> 192.168.1.1 37524 28 rpcbind 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 40 rpc.sprayd 0 27128 192.168.1.5 35116 -> 192.168.1.1 37524 24 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 44 rpc.sprayd 0 27128 192.168.1.5 35116 <- 192.168.1.1 37524 40 rpc.sprayd 0 27128 192.168.1.5 35116 -> 192.168.1.1 37524 36 rpc.sprayd ^C The above shows an outbound nslookup, followed by an inbound spray. It''s on my website @ http://www.brendangregg.com/dtrace.html, beneath the tcpsnoop programs I completed recently. I''ll put it in the DTraceToolkit after it''s passed more testing. ... Well, UDP by process turned out harder than expected. With UDP as a simple stateless protocol I had guessed that it would be easy. wrong! With TCP there as a unique conn_t struct for each TCP session, which I found handy to use as a unique key; there is no equivalent (that works) for UDP. In hindsight it all makes sense, I shouldn''t have expected it to be easy in the first place. :-| This is the first release of udpsnoop.d - and there are a couple of niggling bugs (listed in "Known Bugs" in the code). They''ll be much easier for me to solve once OpenSolaris contains the ip source. :-D (yes, I was wrong - in the past I''ve said that not using source is no big deal, but one month after public release and I''m already quite dependant on it! :). cheers, Brendan [Sydney, Australia]
Hi. Today I setup a new Solaris system to test tcpsnoop.d, and it works fine. But when I tried to execute udpsnoop.d (the script was not in DTraceToolkit, so I downloaded it from the website directly), I got following error message. # ./udpsnoop.d dtrace: failed to compile script ./udpsnoop.d: "/usr/include/sys/neti.h", line 125: syntax error near "net_ifaddr_t" Is there any workaround known for this problem? best regards, bjlee This message posted from opensolaris.org
I forgot to attach my uname information. Sorry. # uname -a SunOS bjlee-solaris 5.11 snv_52 i86pc i386 i86pc regards, bjlee This message posted from opensolaris.org
Hi. Actually, I finally succeeded in removing the error messages by changing ''[]'' to ''*" in the header file ''neti.h''. But this time, the udpsnoop.d does not work correctly. The udpsnoop.d does not show any response though I keep entering the command ''nslookup'' :-( Plz comment. Regards, bjlee This message posted from opensolaris.org
G''Day, On Sun, Feb 04, 2007 at 09:47:45PM -0800, Byung-Joon Lee wrote:> Hi. > Today I setup a new Solaris system to test tcpsnoop.d, and it works fine. > But when I tried to execute udpsnoop.d (the script was not in DTraceToolkit, > so I downloaded it from the website directly), I got following error message. > > # ./udpsnoop.d > dtrace: failed to compile script ./udpsnoop.d: "/usr/include/sys/neti.h", > line 125: syntax error near "net_ifaddr_t" > > Is there any workaround known for this problem?Sorry about that; I''ve just uploaded a newer version that shouldn''t have this problem. I also added the following warning to the script: * ATTENTION: This script is currently fragile as it uses the "fbt" DTrace * provider, which is an unstable interface. This script is likely to fail * on future Solaris versions, including minor updates. This fbt based * script was released to provide temporary observability until a stable * network provider has been released and this script can be rewritten. * See the OpenSolaris dtrace-discuss mailing list for more information. I never added it to the DTraceToolkit as I suspected it was fragile (due to fbt) and it didn''t match every different source of UDP packets (which I documented in the Known Bugs section). If network scripts such as udpsnoop.d help you identify problems, then great. However if their stability or accuracy is a concern - it may be best not to use them until after a network provider has been released and they have been rewritten. thanks for the email, Brendan -- Brendan [CA, USA]
hello, Please i need your help "bgregg", i have to realese a simple D script which have a look to the network activity (juste ip bound and outound). I try to anderstand your script udpsnoop, but it''s too complicated. i''d juste want to have a simple example without C or ksh, just D script. -- This message posted from opensolaris.org
G''Day, On Wed, May 02, 2007 at 04:05:21AM -0700, alain wrote:> hello, > > Please i need your help "bgregg", i have to realese a simple D script which have a look to the network activity (juste ip bound and outound). > > I try to anderstand your script udpsnoop, but it''s too complicated. > > i''d juste want to have a simple example without C or ksh, just D script.DTrace makes easy what was previously hard, and possible what was previously impossible. Much of where DTrace is useful and the examples you will see are of the first variety - making easy what was previously hard to do. The tcpsnoop/udpsnoop scripts are about making possible what previously wasn''t, which is great, but they are currently unavoidably complex (you''ll need to read the kernel source code to understand them properly). Tracing networking events in that much detail is useful, and should be much easier for everyone to do. Hopefully this will happen with the future release of a stable networking provider (or providers). The "fbt" provider that these scripts currently use is an unstable interface, making the tcpsnoop/udpsnoop scripts not just complex - but also prone to failure for minor updates to Solaris (including patches). Yes, using "fbt" isn''t ideal, but with it we are *much* better off than we were on Solaris 9. Any large customer who really really needs an answer to some networking question, can answer it; it make take much time and effort, but it will be answerable. So if you meant that you want to "release a simple D script" to observe network activity - then either you use the "mib" provider (not much detail), or wait for the stable networking providers (which I should return to working on sometime soon). An example of using mib is, # dtrace -n ''mib:::udp* { @[probename] = count(); }'' dtrace: description ''mib:::udp* '' matched 22 probes ^C udpHCOutDatagrams 7 udpHCInDatagrams 8 PS - ok, I can think of one way to do tcpsnoop/udpsnoop style scripts in older Solaris 9, but it is a *lot* of work may as well be called impossible (involves using TNF probes and inserting a custom IP module). Brendan -- Brendan [CA, USA]