This site has been archived. For information on the GN Project’s eduPERT initiative please visit https://archive.geant.org/projects/gn3/geant/services/edupert/Pages/Home.html

Solaris snoop

Sun's Solaris operating system includes a utility called snoop for taking and analyzing packet traces. While snoop is similar in spirit to tcpdump , its options, filter syntax, and stored file formats are all slightly different. The file format is described in the Informational RFC 1761, and supported by some other tools, notably Wireshark.

Selected options

Useful options in connection with snoop include:

  • -i filename read from capture file. Corresponds to tcpdump 's -r option.
  • -o filename dump to file. Corresponds to tcpdump 's -w option.
  • -d device capture on device rather than on the default (first non-loopback) interface. Corresponds to tcpdump 's -i option.
  • -c count stop capture after capturing count packets (same as for =tcpdump=)
  • -r do not resolve addresses to names. Corresponds to tcpdump 's -n option. This is useful for suppressing DNS traffic when looking at a live trace.
  • -V verbose summary mode - between (default) summary mode and verbose mode
  • -v (full) verbose mode

Usage examples

Capture a single ( -c 1=) =udp packet to file test.snoop :

: root@diotima[tmp]; snoop -o test.snoop -c 1 udp
Using device /dev/bge0 (promiscuous mode)
1 1 packets captured

This produces a binary file containing the captured packet as well as a small file header and a timestamp:

: root@diotima[tmp]; ls -l test.snoop
-rw-r--r-- 1 root root 120 2006-04-09 18:27 test.snoop
: root@diotima[tmp]; file test.snoop
test.snoop:	  Snoop capture file - version 2

Analyze the contents of the previously created capture file:

: root@diotima[tmp]; snoop -i test.snoop
  1	0.00000 2001:690:1fff:1661::3 -> ff1e::1:f00d:beac UDP D=10000 S=32820 LEN=20

Display the same capture file in "verbose summary" mode:

: root@diotima[tmp]; snoop -V -i test.snoop
________________________________
  1	0.00000 2001:690:1fff:1661::3 -> ff1e::1:f00d:beac ETHER Type=86DD (IPv6), size = 74 bytes
  1	0.00000 2001:690:1fff:1661::3 -> ff1e::1:f00d:beac IPv6  S=2001:690:1fff:1661::3 D=ff1e::1:f00d:beac LEN=20 HOPS=116 CLASS=0x0 FLOW=0x0
  1	0.00000 2001:690:1fff:1661::3 -> ff1e::1:f00d:beac UDP D=10000 S=32820 LEN=20

Finally, in full verbose mode:

: root@diotima[tmp]; snoop -v -i test.snoop
ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 1 arrived at 18:27:16.81233
ETHER:  Packet size = 74 bytes
ETHER:  Destination = 33:33:f0:d:be:ac, (multicast)
ETHER:  Source		= 0:a:f3:32:56:0,
ETHER:  Ethertype = 86DD (IPv6)
ETHER:
IPv6:	----- IPv6 Header -----
IPv6:
IPv6:	Version = 6
IPv6:	Traffic Class = 0
IPv6:	Flow label = 0x0
IPv6:	Payload length = 20
IPv6:	Next Header = 17 (UDP)
IPv6:	Hop Limit = 116
IPv6:	Source address = 2001:690:1fff:1661::3
IPv6:	Destination address = ff1e::1:f00d:beac
IPv6:
UDP:  ----- UDP Header -----
UDP:
UDP:  Source port = 32820
UDP:  Destination port = 10000
UDP:  Length = 20
UDP:  Checksum = 0635
UDP:

Note: the captured packet is an IPv6 multicast packet from a "beacon" system. Such traffic forms the majority of the background load on our office LAN at the moment.

References

  • RFC 1761, Snoop Version 2 Packet Capture File Format, B. Callaghan, R. Gilligan, February 1995
  • =snoop(1)= manual page for Solaris 10, April 2004, docs.sun.com

– Main.SimonLeinen - 09 Apr 2006

  • No labels