Hi everybody, I''m trying to use the tcpsnoop.d script with my Solaris Express Developper Edition but It doesn''t work because of a compilation error : [b]line 202 : tcp_g_q : Unknown symbol name[/b]. What can I do to resolve this problem? Thanks in advance. -- This message posted from opensolaris.org
Kate wrote:> Hi everybody, > > I''m trying to use the tcpsnoop.d script with my Solaris Express Developper Edition but It doesn''t workworks fine for me on SXDE build 55b: Solaris Nevada snv_55b X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 12 January 2007 sparvu at earth>/opt/DTT/Bin/tcpsnoop.d UID PID LADDR LPORT DR RADDR RPORT SIZE CMD 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 firefox-bin 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 558 firefox-bin 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 66 firefox-bin 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 firefox-bin 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 54 firefox-bin 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 586 firefox-bin 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 firefox-bin 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 1514 firefox-bin 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 firefox-bin Are you using DTT version 0.96 ? stefan
Stefan Parvu wrote:> Kate wrote: >> Hi everybody, >> >> I''m trying to use the tcpsnoop.d script with my Solaris Express >> Developper Edition but It doesn''t work > > works fine for me on SXDE build 55b:The kernel symbol tcp_g_q was removed in build 57. So it looks like the script needs to be updated. Erik> Solaris Nevada snv_55b X86 > Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 12 January 2007 > > > sparvu at earth>/opt/DTT/Bin/tcpsnoop.d > UID PID LADDR LPORT DR RADDR RPORT SIZE CMD > 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 > firefox-bin > 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 558 > firefox-bin > 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 66 > firefox-bin > 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 > firefox-bin > 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 54 > firefox-bin > 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 586 > firefox-bin > 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 > firefox-bin > 100 18792 192.168.1.5 56999 <- 72.5.124.61 80 1514 > firefox-bin > 100 18792 192.168.1.5 56999 -> 72.5.124.61 80 54 > firefox-bin > > Are you using DTT version 0.96 ? > > stefan > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
G''Day Kate, On Thu, May 17, 2007 at 07:31:15AM -0700, Kate wrote:> Hi everybody, > > I''m trying to use the tcpsnoop.d script with my Solaris Express Developper Edition but It doesn''t work because of a compilation error : [b]line 202 : tcp_g_q : Unknown symbol name[/b]. What can I do to resolve this problem?I just tried this on a recent build of the kernel and I get the same error - the kernel TCP/IP stack has changed (again) causing tcpsnoop.d to break (again). Sorry about that. I had a quick look, and there was no easy way to fix tcpsnoop.d. There is a workaround - if you delete the three blocks that have "port closed" in their top comments, then the script runs - but no longer matches failed TCP connections to closed ports. DTrace can still trace this activity; it just requires spending some time (days) with the kernel source to figure out how, and to test that the fix works under different known loads. And repeat that process for every significant change to the TCP/IP stack (a few times a year). The reason for all of this is that tcpsnoop.d uses the DTrace fbt provider - which traces the raw kernel. It isn''t and can never be a "stable" interface. I''ve tried to muster support within Sun for the addition of a stable network provider (there was a long thread about this on dtrace-discuss previously), which would allow a stable version of tcpsnoop.d to be written. In the meantime, tracing this activity is hard, but possible. In the future I hope this becomes both possible and easy. Brendan -- Brendan [CA, USA]
Thanks for your responses. -- This message posted from opensolaris.org
I am guessing that this just gets worse as Sun changes things in the kernel.
This was such a useful tool. I am finding that even with the workaround, the
only data I see is PID/RADDRsize and command.
Solaris 10 8/07 s10s_u4wos_12b SPARC
Copyright 2007 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 August 2007
SunOS utilserv 5.10 Generic_127111-06 sun4v sparc SUNW,Sun-Fire-T200
utilserv> ./tcpsnoop.d
UID PID LADDR LPORT DR RADDR RPORT SIZE CMD
0 9284 0.0.0.0 0 <- 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 <- 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 74 sshd
0 9284 0.0.0.0 0 <- 172.25.24.79 0 82 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 <- 172.25.24.79 0 566 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 <- 172.25.24.79 0 158 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 54 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 486 sshd
0 9284 0.0.0.0 0 -> 172.25.24.79 0 206 sshd
--
This message posted from opensolaris.org
> I am guessing that this just gets worse as Sun changes things in the > kernel. This was such a useful tool. I am finding that even with the > workaround, the only data I see is PID/RADDRsize and command.I believe that we will have something better. Network Provider. http://opensolaris.org/os/community/dtrace/NetworkProvider/ -- Vlad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20080703/49e90cc9/attachment.bin>
The Network provider is only availabe on opensolaris, not SPARC based solaris 10. According to the comment in tcpsnoop.d, new solaris 10 release changes the fbt provider, which is not back compatible. It is a pity that tcpsnoop is not supported in new solaris release. Is there anyone providing the guide line that what kind of changes in fbt could make it working? Thanks, carl On 7/3/08 9:41 AM, "Vladimir Marek" <Vladimir.Marek at Sun.COM> wrote:>> I am guessing that this just gets worse as Sun changes things in the >> kernel. This was such a useful tool. I am finding that even with the >> workaround, the only data I see is PID/RADDRsize and command. > > I believe that we will have something better. Network Provider. > > http://opensolaris.org/os/community/dtrace/NetworkProvider/
G''Day Folks, On Sun, Jul 06, 2008 at 11:59:34AM -0400, Carl Ma wrote:> The Network provider is only availabe on opensolaris, not SPARC based > solaris 10. According to the comment in tcpsnoop.d, new solaris 10 release > changes the fbt provider, which is not back compatible.Yes, the network providers will ultimately provide tcpsnoop/tcptop style capability (either directly supported, or indirectly - as a step-up from fbt); however there is still some work to go. It looks like I need to update tcpsnoop/tcptop again until these exist in a stable manner based on the network providers.> It is a pity that tcpsnoop is not supported in new solaris release. Is > there anyone providing the guide line that what kind of changes in fbt could > make it working?tcpsnoop/tcptop were never supported by Sun anyway, I wrote them as a customer and made them available as CDDL''d opensource, and continue to maintain them and the DTraceToolkit in my spare time. I''m sorry they keep breaking - when I moved to the US I left behind my test servers, and haven''t had anything to run Sol 10u5 ... until recently - I installed Sol 10u5 on a home PC last week - now I can see and fix this issue. A couple of people had sent me fixes for tcpsnoop/tcptop (which is appreciated since I have limited time and servers to develop them on) but those fixes looked equal to tcpsnoop_snv, which is already available. I''m wondering if it would be more useful for me to write a guide to how tcpsnoop was written, which people could then follow to not only update the scripts for Solaris 10 x86 and sparc, but also port the scripts to MacOS X and other OSes with DTrace... Brendan -- Brendan [CA, USA]