Solaris Snoop Packet Sniffer

Snoop is built-in Solaris sniffer and is located in the /usr/sbin directory. It is pretty cable sniffer equal or better then TCPdump.  Snoop file format was is different from PCAP and was defined in RFC 1761, Snoop Version 2 Packet Capture File Format, B. Callaghan, R. Gilligan, February 1995. Conversion is possible with Ethereal tool editcap

You can display packets as soon as they are received or saved to a file. When snoop writes to an intermediate file, packet loss under busy trace conditions is unlikely. Snoop itself can be use read and interpret the file (print summary extended summary and full packets dumps).  It has pretty powerful packet filtering engine (see especially expr capability)

The snoop command can capture both IPv4 and IPv6 packets. It can display IPv6 headers, IPv6 extension headers, ICMPv6 headers, and neighbor discovery protocol data. By default, the snoop command displays both IPv4 and IPv6 packets. By specifying the ip or ip6 protocol keywords, the snoop command displays only IPv4 or IPv6 packets. The IPv6 filter option enables you to filter through all packets, both IPv4 and IPv6, displaying only the IPv6 packets. See the snoop man page for details. See How to Monitor Only IPv6 Network Traffic for a description of procedures that use this command.

Other then IPv6 traffic snoop capabilities are very similar to tcpdump and output formats are almost identical. The snoop capture file format is described in RFC 1761. Still there are some differences and for example snort can read tcpdump binary files,  but not snoop binary files. Ethereal's editcap program can be used to convert the snoop file to a tcpdump file.

Snoop has more than a dozen options:

        [ -a ]                  # Listen to packets on audio
        [ -d device ]           # Network interface to snoop (le?, ie?, bf?, tr?)
        [ -s snaplen ]          # Truncate packets
        [ -c count ]            # Quit after count packets
        [ -P ]                  # Turn OFF promiscuous mode
        [ -D ]                  # Report dropped packets
        [ -S ]                  # Report packet size
        [ -i file ]             # Read previously captured packets
        [ -o file ]             # Capture packets in file
        [ -n file ]             # Load addr-to-name table from file
        [ -N ]                  # Create addr-to-name table
        [ -t  r|a|d ]           # Time: Relative, Absolute or Delta
        [ -v ]                  # Verbose packet display
        [ -V ]                  # Show all summary lines
        [ -p first[,last] ]     # Select packet(s) to display
        [ -x offset[,length] ]  # Hex dump from offset for length
        [ -C ]                  # Print packet filter code
        [ -q ]                  # Suppress printing packet count
        [ -r ]                  # Do not resolve address to name

        [ filter expression ]

The most typical use the snoop is to observer communication between two systems. For example, if we want to observe traffic between systems alpha and beta  we can use the following command:

# snoop alpha,beta

Typical examples of snoop usage include:

• snoop Summary output  (snoop -d bge1)
• snoop -v Detailed verbose output
• snoop -V Summary verbose output (negation of -v)
• snoop -o filename Redirects the snoop utility output to filename in summary mode
• snoop -i filename Displays packets that were previously captured in filename

Note  1: You need to press Control-C to stop the snoop utility.

Note 2:  Use the -a option to enable audible clicks, which notify you of any network traffic. Although noisy, the clicks are useful when troubleshooting, for example: snoop -a dhcp

The snoop command can only be run by superuser. In summary form, snoop only displays data pertaining to the highest-level protocol. For example, an NFS packet will only display NFS information. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if one of the verbose options (-v or -V) is chosen.

The snoop command has many options described in the snoop man page.

Some examples of using snoop are:

• Examine broadcast packets using summary mode
  
  #snoop broadcast
   
• Display the packet and header information of the broadcast from one system using the verbose mode
  Note - snoop only displays output when there is network traffic and the traffic matches the search criteria.

  # snoop -v broadcast
   
  

• Display information on any packet going to or coming from the host 128.50 .1 .250 using summary verbose mode
  
  # snoop -V 128.50.1.250
  
  
• To enable data captures from the snoop output without losing packets while writing to the screen, send the snoop output to a file. For example:
  
  # snoop -o /tmp/snooper -V 128.50.1.250
  
  Returns the same type of information as shown previously but stores it in the /tmp/snooper file. While snoop is capturing information, a record counter displays the recorded packets. The actual output of the snoop command is in a data-compressed format and can only be read with the snoop -i command. To read this format, issue the following command:

  # snoop -i /tmp/snooper
  
  

• Use snoop piped through egrep to filter out specific protocols or portions of the network trace. egrep -iv 'nfs |ack |contin |ftp' ignores upper/lower case and prints all lines except those that contain the pattern nfs, ack, contin, and ftp.
  
  # snoop | egrep -iv 'nfs |ack |contin |ftp'

Reference

snoop [-aqrCDNPSvV] [-t [r| a| d]] [-c maxcount] [-d device] [-i filename] [-n filename] [-o filename] [-p first[,last]] [-s snaplen] [-x offset[,length]] [expression]

snoop captures packets from the network and displays their contents. snoop uses both the network packet filter and streams buffer modules to provide efficient capture of packets from the network. Captured packets can be displayed as they are received, or saved to a file for later inspection.

snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, only the data pertaining to the highest level protocol is displayed. For example, an NFS packet will have only NFS information displayed. The underlying RPC, UDP, IP, and ethernet frame information is suppressed but can be displayed if either of the verbose options are chosen.

snoop requires an interactive interface.

Options

• -a Listen to packets on /dev/audio (warning: can be noisy).
   
• -C List the code generated from the filter expression for either the kernel packet filter, or snoop's own filter.
• -D Display number of packets dropped during capture on the summary line.
   
• -N Create an IP address-to-name file from a capture file. This must be set together with the -i option that names a capture file. The address-to-name file has the same name as the capture file with .names appended.
  This file records the IP address to hostname mapping at the capture site and increases the portability of the capture file. Generate a .names file if the capture file is to be analyzed elsewhere. Packets are not displayed when this flag is used.
   
• -P Capture packets in non-promiscuous mode. Only broadcast, multicast, or packets addressed to the host machine will be seen.
   
• -q When capturing network packets into a file, do not display the packet count. This can improve packet capturing performance.
   
• -r Do not resolve the IP address to the symbolic name. This prevents snoop from generating network traffic while capturing and displaying packets. However, if the -n option is used, and an address is found in the mapping file, its corresponding name will be used.
   
• -S Display size of the entire ethernet frame in bytes on the summary line.
   
• -v Verbose mode. Print packet headers in lots of detail. This display consumes many lines per packet and should be used only on selected packets.
   
• -V Verbose summary mode. This is halfway between summary mode and verbose mode in degree of verbosity. Instead of displaying just the summary line for the highest level protocol in a packet, it displays a summary line for each protocol layer in the packet. For instance, for an NFS packet it will display a line each for the ETHER, IP, UDP, RPC and NFS layers. Verbose summary mode output may be easily piped through grep to extract packets of interest. For example to view only RPC summary lines:

  snoop -i rpc.cap -V | grep RPC

• -t [ r | a | d ] Time-stamp presentation. Time-stamps are accurate to within 4 microseconds. The default is for times to be presented in d (delta) format (the time since receiving the previous packet). Option a (absolute) gives wall-clock time. Option r (relative) gives time relative to the first packet displayed. This can be used with the -p option to display time relative to any selected packet.
   
• -c maxcount Quit after capturing maxcount packets. Otherwise keep capturing until there is no disk left or until interrupted with Control-C.
   
• -d device Receive packets from the network using the interface specified by device. The program netstat(1M), when invoked with the -i flag, lists all the interfaces that a machine has. Normally, snoop will automatically choose the first non-loopback interface it finds.
   
• -i filename Display packets previously captured in filename. Without this option, snoop reads packets from the network interface. If a filename.names file is present, it is automatically loaded into the snoop IP address-to-name mapping table (See -N flag).
   
• -n filename Use filename as an IP address-to-name mapping table. This file must have the same format as the /etc/hosts file (IP address followed by the hostname).
   
• -o filename Save captured packets in filename as they are captured. During packet capture, a count of the number of packets saved in the file is displayed. If you wish just to count packets without saving to a file, name the file /dev/null.
   
• -p first [ , last ] Select one or more packets to be displayed from a capture file. The first packet in the file is packet number 1.
   
• -s snaplen Truncate each packet after snaplen bytes. Usually the whole packet is captured. This option is useful if only certain packet header information is required. The packet truncation is done within the kernel giving better utilization of the streams packet buffer. This means less chance of dropped packets due to buffer overflow during periods of high traffic. It also saves disk space when capturing large traces to a capture file. To capture only IP headers (no options) use a snaplen of 34. For UDP use 42, and for TCP use 54. You can capture RPC headers with a snaplen of 80 bytes. NFS headers can be captured in 120 bytes.
   
• -x offset [ , length] Display packet data in hexadecimal and ASCII format. The offset and length values select a portion of the packet to be displayed. To display the whole packet, use an offset of 0. If a length value is not provided, the rest of the packet is displayed.

Filter expressions

Select packets either from the network or from a capture file. Only packets for which the expression is true will be selected. If no expression is provided it is assumed to be true.

Given a filter expression, snoop generates code for either the kernel packet filter or for its own internal filter. If capturing packets with the network interface, code for the kernel packet filter is generated. This filter is implemented as a streams module, upstream of the buffer module. The buffer module accumulates packets until it becomes full and passes the packets on to snoop. The kernel packet filter is very efficient, since it rejects unwanted packets in the kernel before they reach the packet buffer or snoop. The kernel packet filter has some limitations in its implementation; it is possible to construct filter expressions that it cannot handle. In this event, snoop tries to split the filter and do as much filtering in the kernel as possible. The remaining filtering is done by the packet filter for snoop. The -C flag can be used to view generated code for either the packet filter for the kernel or the packet filter for snoop. If packets are read from a capture file using the -i option, only the packet filter for snoop is used.

A filter expression consists of a series of one or more boolean primitives that may be combined with boolean operators (AND, OR, and NOT). Normal precedence rules for boolean operators apply. Order of evaluation of these operators may be controlled with parentheses. Since parentheses and other filter expression characters are known to the shell, it is often necessary to enclose the filter expression in quotes. Refer to Example 2 for information about setting up more efficient filters.

The primitives are:

• host hostname True if the source or destination address is that of hostname. The hostname argument may be a literal address. The keyword host may be omitted if the name does not conflict with the name of another expression primitive. For example, "pinky" selects packets transmitted to or received from the host pinky, whereas "pinky and dinky" selects packets exchanged between hosts pinky AND dinky.

  The type of address used depends on the primitive which precedes the host primitive. The possible qualifiers are "inet", "inet6", "ether", or none. These three primitives are discussed below. Having none of the primitives present is equivalent to "inet host hostname or inet6 host hostname". In other words, snoop tries to filter on all IP addresses associate with hostname.

• inet or inet6 A qualifier that modifies the host primitive that follows. If it is inet, then snoop tries to filter on all IPv4 addresses returned from a name lookup. If it is inet6, snoop tries to filter on all IPv6 addresses returned from a name lookup.
• ipaddr or etheraddr Literal addresses, both IP dotted and ethernet colon are recognized. For example,
  • "129.144.40.13" matches all packets with that IP ;
  • "2::9255:a00:20ff:fe73:6e35" matches all packets with that IPv6 address as source or destination;
  • "8:0:20:f:b1:51" matches all packets with the ethernet address as source or destination.

  An ethernet address beginning with a letter is interpreted as a hostname. To avoid this, prepend a zero when specifying the address. For example, if the ethernet address is "aa:0:45:23:52:44", then specify it by add a leading zero to make it "0aa:0:45:23:52:44".

• from or src A qualifier that modifies the following host, net, ipaddr, etheraddr, port or rpc primitive to match just the source address, port, or RPC reply.
• to or dst A qualifier that modifies the following host, net, ipaddr, etheraddr, port or rpc primitive to match just the destination address, port, or RPC call.
• ether A qualifier that modifies the following host primitive to resolve a name to an ethernet address. Normally, IP address matching is performed.
• ethertype number True if the ethernet type field has value number. Equivalent to "ether[12:2] = number".
• ip, ip6, arp, rarp True if the packet is of the appropriate ethertype.
• broadcast True if the packet is a broadcast packet. Equivalent to "ether[2:4] = 0xffffffff".
• multicast True if the packet is a multicast packet. Equivalent to "ether[0] & 1 = 1".
• apple True if the packet is an Apple Ethertalk packet. Equivalent to "ethertype 0x809b or ethertype 0x803f".
• decnet True if the packet is a DECNET packet.
• greater length True if the packet is longer than length.
• less length True if the packet is shorter than length.
• udp, tcp, icmp, icmp6, ah, esp True if the IP or IPv6 protocol is of the appropriate type.
• net net True if either the IP source or destination address has a network number of net. The from or to qualifier may be used to select packets for which the network number occurs only in the source or destination address.
• port port True if either the source or destination port is port. The port may be either a port number or name from /etc/services. The tcp or udp primitives may be used to select TCP or UDP ports only. The from or to qualifier may be used to select packets for which the port occurs only as the source or destination.
• rpc prog [ , vers [ , proc ] ] True if the packet is an RPC call or reply packet for the protocol identified by prog. The prog may be either the name of an RPC protocol from /etc/rpc or a program number. The vers and proc may be used to further qualify the program version and procedure number, for example, "rpc nfs,2,0" selects all calls and replies for the NFS null procedure. The to or from qualifier may be used to select either call or reply packets only.
• gateway host True if the packet used host as a gateway, that is, the ethernet source or destination address was for host but not the IP address. Equivalent to "ether host host and not host host".
   
• nofrag True if the packet is unfragmented or is the first in a series of IP fragments. Equivalent to "ip[6:2] & 0x1fff = 0".
   
• expr relop expr True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression composed of numbers, packet field selectors, the length primitive, and arithmetic operators +, -, *, &, |, ^, and %.
  
  The arithmetic operators within expr are evaluated before the relational operator and normal precedence rules apply between the arithmetic operators, such as multiplication before addition.
  
  Parentheses may be used to control the order of evaluation. To use the value of a field in the packet use the following syntax:

  base[expr [: size ] ]

  where expr evaluates the value of an offset into the packet from a base offset which may be ether, ip, udp, tcp, or icmp. The size value specifies the size of the field. If not given, 1 is assumed. Other legal values are 2 and 4. For example,

  ether[0] & 1 = 1

  is equivalent to multicast.

  ether[2:4] = 0xffffffff

  is equivalent to broadcast.

  ip[ip[0] & 0xf * 4 : 2] = 2049

  is equivalent to udp[0:2] = 2049

  ip[0] & 0xf > 5

  selects IP packets with options.

  ip[6:2] & 0x1fff = 0

  eliminates IP fragments.

  udp and ip[6:2]&0x1fff = 0 and udp[6:2] != 0

  finds all packets with UDP checksums.

  The length primitive may be used to obtain the length of the packet. For instance "length > 60" is equivalent to "greater 60", and "ether[length - 1]" obtains the value of the last byte in a packet.
   

• and Perform a logical AND operation between two boolean values. The AND operation is implied by the juxtaposition of two boolean expressions, for example "dinky pinky" is the same as "dinky AND pinky".
   
• or or , Perform a logical OR operation between two boolean values. A comma may be used instead, for example, "dinky,pinky" is the same as "dinky OR pinky".
   
• not or ! Perform a logical NOT operation on the following boolean value. This operator is evaluated before AND or OR.
   
• slp True if the packet is an SLP packet.

Examples

Example 1 Using the snoop Command

Capture packets between funky and pinky and save them to a file. Then inspect the packets using times (in seconds) relative to the first captured packet:

;

example# snoop -o cap funky pinky
example# snoop -i cap -t r | more

To look at selected packets in another capture file:

example# snoop -i pkts - 99,108
 99   0.0027   boutique -> sunroof     NFS C GETATTR FH=8E6C
100   0.0046   sunroof -> boutique     NFS R GETATTR OK
101   0.0080   boutique -> sunroof     NFS C RENAME FH=8E6C MTra00192 to .nfs08
102   0.0102   marmot -> viper          NFS C LOOKUP FH=561E screen.r.13.i386
103   0.0072   viper -> marmot          NFS R LOOKUP No such file or directory
104   0.0085   bugbomb -> sunroof    RLOGIN C PORT=1023 h
105   0.0005   kandinsky -> sparky    RSTAT C Get Statistics
106   0.0004   beeblebrox -> sunroof  NFS C GETATTR FH=0307
107   0.0021   sparky -> kandinsky    RSTAT R
108   0.0073   office -> jeremiah        NFS C READ FH=2584 at 40960 for 8192

To look at packet 101 in more detail:

example# snoop -i pkts -v -p101
ETHER:  ----- Ether Header -----
ETHER:
ETHER:  Packet 101 arrived at 16:09:53.59
ETHER:  Packet size = 210 bytes
ETHER:  Destination = 8:0:20:1:3d:94, Sun
ETHER:  Source      = 8:0:69:1:5f:e,  Silicon Graphics
ETHER:  Ethertype = 0800 (IP)
ETHER:
IP:   ----- IP Header -----
IP:
IP:   Version = 4, header length = 20 bytes
IP:   Type of service = 00
IP:         ..0. .... = routine
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:   Total length = 196 bytes
IP:   Identification 19846
IP:   Flags = 0X
IP:   .0.. .... = may fragment
IP:   ..0. .... = more fragments
IP:   Fragment offset = 0 bytes
IP:   Time to live = 255 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 18DC
IP:   Source address = 129.144.40.222, boutique
IP:   Destination address = 129.144.40.200, sunroof
IP:
UDP:  ----- UDP Header -----
UDP:
UDP:  Source port = 1023
UDP:  Destination port = 2049 (Sun RPC)
UDP:  Length = 176
UDP:  Checksum = 0
UDP:
RPC:  ----- SUN RPC Header -----
RPC:
RPC:  Transaction id = 665905
RPC:  Type = 0 (Call)
RPC:  RPC version = 2
RPC:  Program = 100003 (NFS), version = 2, procedure = 1
RPC:  Credentials: Flavor = 1 (Unix), len = 32 bytes
RPC:     Time = 06-Mar-90 07:26:58
RPC:     Hostname = boutique
RPC:     Uid = 0, Gid = 1
RPC:     Groups = 1
RPC:  Verifier   : Flavor = 0 (None), len = 0 bytes
RPC:
NFS:  ----- SUN NFS -----
NFS:
NFS:  Proc = 11 (Rename)
NFS:  File handle = 000016430000000100080000305A1C47
NFS:                597A0000000800002046314AFC450000
NFS:  File name = MTra00192
NFS:  File handle = 000016430000000100080000305A1C47
NFS:                597A0000000800002046314AFC450000
NFS:  File name = .nfs08
NFS:  

To view just the NFS packets between sunroof and boutique:

example# snoop -i pkts rpc nfs and sunroof and boutique
1   0.0000   boutique -> sunroof    NFS C GETATTR FH=8E6C
2   0.0046    sunroof -> boutique   NFS R GETATTR OK 
3   0.0080   boutique -> sunroof    NFS C RENAME FH=8E6C MTra00192 to .nfs08

To save these packets to a new capture file:

example# snoop -i pkts -o pkts.nfs rpc nfs sunroof boutique

To view encapsulated packets, there will be an indicator of encapsulation:

example# snoop ip-in-ip
sunroof -> boutique ICMP Echo request    (1 encap)

If -V is used on an encapsulated packet:

example# snoop -V ip-in-ip
sunroof -> boutique  ETHER Type=0800 (IP), size = 118 bytes
sunroof -> boutique  IP  D=129.144.40.222 S=129.144.40.200 LEN=104, ID=27497
sunroof -> boutique  IP  D=10.1.1.2 S=10.1.1.1 LEN=84, ID=27497
sunroof -> boutique  ICMP Echo request


---

Example 2 Setting Up A More Efficient Filter

To set up a more efficient filter, the following filters should be used toward the end of the expression, so that the first part of the expression can be set up in the kernel: greater, less, port, rpc, nofrag, and relop. The presence of OR makes it difficult to split the filtering when using these primitives that cannot be set in the kernel. Instead, use parenthesis to enforce the primitives that should be OR'd.

To capture packets between funky and pinky of type tcp or udp on port 80:

example# snoop funky and pinky and port 80 and tcp or udp

Since the primitive port cannot be handled by the kernel filter, and there is also an OR in the expression, a more efficeint way to filter is to move the OR to the end of the expression and to use parenthesis to enforce the OR between tcp and udp:

example# snoop funky and pinky and (tcp or udp) and port 80

EXIT STATUS

0 Successful completion.

1 An error occurred.

NEWS CONTENTS

• 30090830 : Using snoop as a Troubleshooting Tool ( Aug 30, 3009 )
• 20060810 : rdr rule interaction found on v4.1.13 ( rdr rule interaction found on v4.1.13, Aug 10, 2006 )
• 20060810 : Arguments for snoop command... ( Arguments for snoop command..., )
• 20060810 : The Secrets of Snoop ( The Secrets of Snoop, )
• 20060810 : [tcpdump-workers] Linux tcpdump and Sun Solaris Snoop ( [tcpdump-workers] Linux tcpdump and Sun Solaris Snoop, )
• 20060810 : Sun Microsystems - BigAdmin Shell Commands ( Sun Microsystems - BigAdmin Shell Commands, )

Old News ;-)

[Aug 30, 3009] Using snoop as a Troubleshooting Tool

The snoop utility can be particularly useful when troubleshooting virtually any networking problems. The traces that are produced by the snoop utility can be most helpful when attempting remote troubleshooting because an end-user (with access to the root password) can capture a snoop trace and email it or send it using ftp to a network troubleshooter for remote diagnosis.

You can use the snoop utility to display packets on the fly or to write to a file. Writing to a file using the -o switch is preferable because each packet can be interrogated later.

one# snoop -o tracefile
Using device /dev/le (promiscuous mode) 3^C
one#

You can view the snoop file by using the -i switch and the filename in any of the standard modes, namely:

Terse mode - No option switch is required.

Summary verbose mode - Use the -V switch.

Verbose mode - Use the -v switch.

Terse Mode

one# snoop -i tracefile

Summary Verbose Mode

one# snoop -V -i tracefile

Verbose is most useful when you are troubleshooting routing, network booting, Trivial File Transport Protocol (TFTP), and any network-related problems that require diagnosis at the packet level. Each layer of the packet is clearly defined by the specific headers.
one# snoop -v -i tracefile

Power user - View the snoop output file in terse mode and locate a packet or range of packets of interest. Use the -p switch to view these packets. For example, if packet two is of interest, type:

one# snoop -p2,2 -v -i tracefile

ETHER: Ether Header
ETHER:
ETHER: Packet 2 arrived at 11:19:28.74
... ...
TELNET: "/dev/le (promiscuous mode)\r\n\r\ 0000 "
TELNET:
one#

[Aug 10, 2006] rdr rule interaction found on v4.1.13

James Huang
Tue, 01 Aug 2006 10:34:05 -0700

Recently test ipfilter v4.1.13 on Sun Solaris 8 (v240), found
interactions between rdr rules.

1. correct scenario, perfect results.
# ipnat -l
List of active MAP/Redirect filters:
rdr bge0 from any to 172.25.141.88/32 port = 30000 -> 172.25.141.54
port = 4080 udp
rdr bge0 from any to 172.25.141.88/32 port = 30002 -> 172.25.141.55
port = 4130 udp

# snoop udp
172.25.141.54 -> 172.25.141.88 UDP D=30000 S=4130 LEN=24
172.25.141.54 -> 172.25.141.54 UDP D=4080 S=4130 LEN=24
172.25.141.54 -> 172.25.141.88 UDP D=30002 S=4080 LEN=24
172.25.141.54 -> 172.25.141.55 UDP D=4130 S=4080 LEN=24

2. interaction scenario
# ipnat -l
List of active MAP/Redirect filters:
rdr bge0 from any to 172.25.141.88/32 port = 30002 -> 172.25.141.54
port = 4130 udp
rdr bge0 from any to 172.25.141.88/32 port = 30000 -> 172.25.141.54
port = 4080 udp

NOTE: The rules redirect to same dest ip compare to scenario 1 that
redirects to different ip.

# snoop udp
172.25.141.54 -> 172.25.141.88 UDP D=30002 S=4080 LEN=24
172.25.141.88 -> 172.25.141.54 UDP D=4130 S=30000 LEN=24
172.25.141.54 -> 172.25.141.88 UDP D=30000 S=4130 LEN=24
172.25.141.88 -> 172.25.141.54 UDP D=4080 S=30002 LEN=24

&%$@: The source ip and port of outgoing packets are accidentally changed.

Need you help to fix it, Thanks a lot.

Arguments for snoop command...

Usage: snoop
[ -a ] # Listen to packets on audio
[ -d device ] # settable to le?, ie?, bf?, tr?
[ -s snaplen ] # Truncate packets
[ -c count ] # Quit after count packets
[ -P ] # Turn OFF promiscuous mode
[ -D ] # Report dropped packets
[ -S ] # Report packet size
[ -i file ] # Read previously captured packets
[ -o file ] # Capture packets in file
[ -n file ] # Load addr-to-name table from file
[ -N ] # Create addr-to-name table
[ -t r|a|d ] # Time: Relative, Absolute or Delta
[ -v ] # Verbose packet display
[ -V ] # Show all summary lines
[ -p first[,last] ] # Select packet(s) to display
[ -x offset[,length] ] # Hex dump from offset for length
[ -C ] # Print packet filter code
[ -q ] # Suppress printing packet count
[ -r ] # Do not resolve address to name

[ filter expression ]

Example:
snoop -o saved host fred

snoop -i saved -tr -v -p1

DESCRIPTION
snoop captures packets from the network and displays their
contents. snoop uses both the network packet filter and
streams buffer modules to provide efficient capture of pack-
ets from the network. Captured packets can be displayed as
they are received, or saved to a file for later inspection.

snoop can display packets in a single-line summary form or
in verbose multi-line forms. In summary form, only the data
pertaining to the highest level protocol is displayed. For
example, an NFS packet will have only NFS information
displayed. The underlying RPC, UDP, IP, and ethernet frame
information is suppressed but can be displayed if either of
the verbose options are chosen.

snoop requires an interactive interface.

The Secrets of Snoop

To capture data to a file, the command is
#snoop –o filename

This saves all the data in binary format to filename. To see data real-time, exclude the command "-o filename". Otherwise, all command syntax is the same for snoop.

The first thing we need to do is determine how many packets to capture. If no number is determined, snoop will continue to gather packets until you CRTL-C or run out of resources. To set the number, use the command.

#snoop –o filename –c 1000 .

Snoop will capture 1000 packets in about 60 seconds on a standard 10Mbps network.

Next, we want to determine what level of detail we need. Snoop comes in three flavors, summary (default), verbose summary (-V), and verbose mode (-v).

Summary gives us the least information, only the highest protocol level, layer 5,6 or 7 , and packet source/destination. Below is a single packet in summary mode. This is the 27^th packet captured, it shows a Telnet connection between squirrel and my school account. 0.01743 is the time between packet 26 and 27.

27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TELNET C port=45330

Verbose summary (-V) gives us all the layers of the OSI model, (layers 2,3,4, and 5, 6 or 7) but in summarized fashion, one line for each layer. Below we see an example, packet 27 again. Notice it gives us layer 2 (ETHER), layer 3 (IP), layer 4 (TCP), and layer 7 (Telnet). Note how it also gives Syn and Seq (sequence number). There is no Ack (Acknowledge number) so this is the first packet for this Telnet session.

27 0.01743 squirrel -> ICARUS.CC.UIC.EDU ETHER Type=0800 (IP), size = 58 bytes
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU IP D=128.248.121.53 S=208.194.41.20 LEN=44, ID=6082
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TCP D=23 S=45330 Syn Seq=678057692 Len=0 Win=8760
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TELNET C port=45330

Verbose gives us all the gory details of each packet, all the way to the bit level on the OSI model. Below is a packet 27 in verbose mode. Here we see detailed information of each layer, layer 2 (Ethernet), layer 3 (IP), and layer 4 (TCP) header. See RFC 894 (Ether), 791 (IP), and 793 (TCP) for specific header information.

ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 27 arrived at 10:40:36.07
ETHER: Packet size = 58 bytes
ETHER: Destination = 8:0:20:8d:fc:d2, Sun
ETHER: Source = 8:0:20:c:df:aa, Sun
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 44 bytes
IP: Identification = 6082
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 7005
IP: Source address = 208.194.41.20, squirrel
IP: Destination address = 128.248.121.53, ICARUS.CC.UIC.EDU
IP: No options
IP:
TCP: ----- TCP Header -----
TCP:
TCP: Source port = 45330
TCP: Destination port = 23 (TELNET)
TCP: Sequence number = 678057692
TCP: Acknowledgement number = 0
TCP: Data offset = 24 bytes
TCP: Flags = 0x02
TCP: ..0. .... = No urgent pointer
TCP: ...0 .... = No acknowledgement
TCP: .... 0... = No push
TCP: .... .0.. = No reset
TCP: .... ..1. = Syn
TCP: .... ...0 = No Fin
TCP: Window = 8760
TCP: Checksum = 0x517a
TCP: Urgent pointer = 0
TCP: Options: (4 bytes)
TCP: - Maximum segment size = 1460 bytes
TCP:
TELNET: ----- TELNET: -----
TELNET:
TELNET: ""
TELNET:

No one level of detail is "better" then the other. It depends on what type of information you are looking for. Keep in mind however that snoop can be resource intensive. In verbose mode, snoop may overwhelm the system, forcing it to drop packets depending on your network traffic. In some cases, you may have to use a dedicated server for snoop, depending on your verbose level and number of packets gathered. To capture 1000 packets in verbose summary mode:

#snoop –V –o filename –c 1000

To read a capture file, use –i filename. If you captured packets in verbose mode, you can read a capture file in summary, verbose summary, or verbose mode. I recommend you scan through the capture file in summary mode, identify what packets are interesting, then view specific packets in verbose mode. To look at a specific packet, use –ppacket#. Below is an example of looking at packets 10-32 and packet 56 in verbose mode.

snoop –i filename –v –p10-32,56

Now lets leverage the true power of snoop. Snoop has a variety of filtering tools, allowing us to focus on the type of packets we capture, be it source, destination, protocol layer, etc. Here we will cover some of the most commonly used options. However, for complete information, be sure to do a man on snoop(1).

First, we can select what systems, by either MAC (layer 2) or IP or host name, (layer 3) will be snooped. This limits what packets are captured at the interface. If you have just one node you want to snoop, include its IP address. If there are several, use the expression "and" or "or" between the nodes. You can focus the expression even more with the qualifier "from" or "to" which match the source or destination address. The "!" or "not" performs a logical NOT operation. Last, the expression "net" captures all packets that belong to a specific network. The command below captures all packets coming from zeus, going to 8:0:20:f1:b3:51, or packets belonging to the network 192.168.3.0, except 192.168.3.58. Note, the host name zeus must be resolvable, be it /etc/hosts or DNS.

snoop –o filename from zeus or to 8:0:20:f1:b3:51or net 192.168.3.0 not 192.168.3.58

Just as we can qualify specific hosts or networks at layer 2 or 3, we can limit packets captured at layers 4, 5, 6, and 7. At layer 4, we can qualify "tcp", "udp", or "icmp" (actually RFC 792 states icmp is a layer 3 protocol, but I have placed it here to reflect snoop's man page). For layers 5,6 and 7 use the qualifiers "port" and "rpc" (based on the /etc/services and /etc/rpc files). The command below captures all DNS or NFS packets

snoop –o filename –V port domain or rpc nfs

Snoop and Security

Now that we have covered the flexibility of snoop, lets apply it to your network security. With snoop, you silently sit on the network and capture data. Unlike active measures, such as network discovery using ICMP, snoop does not alert anyone to its presence. This allows you to analyze the security of your network, without notifying anyone. Also, snoop can run over a long period of time, compared to active measures that run in a single point of time. If a server is down for several minutes while you are pinging the network, you will miss it. Snoop will pick up these servers, as long as they eventually send or receive traffic.

Snoop does two critical things for security, it tells you who is on your network, and what they are doing. You need to first identify what your security concern is, then configure snoop to find that information.

Often, a security concern is having a node or gateway on your network that you do not know about. This node could be an innocent dial-up server, or a gateway a hacker set-up. I know of a company where an unknown Internet connection was recently identified with a sniffer. Active measures will tell you who is on the network, only if the machine is on. But what if a node is on only at night, or has been configured not to ICMP_REPLY, then what? Using the qualifiers we covered above, snoop could capture information on your network. With a perl or shell script, you could parse this information, identifying unknown nodes on your network.

Another security issue is what is going on your network. You may be concerned about specific websites or downloads. Perhaps you are concerned that users are downloading the latest hacker attacks. You can snoop your network, looking for FTP downloads from known websites. I know of a recent incident where an employee was identified of this during a routine network analysis.

Perhaps you have several critical servers that have been hit with denial of service attacks, such as land.c or ping of death. You can qualify snoop to look for land.c by capturing packets with source and destination the same. For ping of death, look for icmp packets with extremely large lengths.

So far we have discussed what snoop can do, now we will cover what snoop cannot do. Unlike active measures, snoop, like most sniffers, cannot operate in a switched environment. Snoop only records packets that cross the designated interface. Switches block and forward IP packets based on their MAC , layer 2, address. If you have a switch, snoop will capture only the packets in its collision domain.

Where you snoop is just as important as what you snoop. If you want to monitor all the traffic on your network, place your sniffer on the Internet router segment. This way your are capturing all Internet traffic, you are no limited to specific collision domains.

[tcpdump-workers] Linux tcpdump and Sun Solaris Snoop

Dear Tcpdump Expert,

I discovered your email in the manual page for tcpdump. Linux tcpdump and Sun Solaris snoop seem to have a common ancestor. I have been unable to discover any way to read a dump captured with Sun Solaris snoop (snoop -r -o file) using tcpdump -n -v -r file
Is there a way to accomplish this?
My goal is to assist my Linux based ISP with a trace I captured on a Sun.
I have both available.

Thank you for your time.

Bob Styma

• To: Robert Styma <[email protected]>
• Subject: Re: [tcpdump-workers] Linux tcpdump and Sun Solaris Snoop
• From: Guy Harris <[email protected]>
• Date: Fri, 22 Nov 2002 22:24:30 -0800

On Thu, Nov 21, 2002 at 06:32:30PM -0700, Robert Styma wrote:
>    I discovered your email in the manual page for tcpdump.  Linux 
> tcpdump and Sun Solaris snoop seem to have a common ancestor.

It may seem that way, but if there is such an ancestor, it's Sun's
etherfind, and neither tcpdump nor snoop much resemble that - I don't
think it even *had* a save file format, as it had no option to save
captured packets in raw binary form (raw hex, yes; raw binary, no):

	http://www.cs.rit.edu/~hpb/Man/_Man_SunOS_4.1.3_html/html8/etherfind.8c.html

> I have been unable to discover any way to read a dump captured with
> Sun Solaris snoop (snoop -r -o file) using tcpdump -n -v -r file
> Is there a way to accomplish this?

1) get Ethereal, and use its editcap program to convert the snoop file
   to a tcpdump file.

2) modify libpcap to read snoop files as well as tcpdump files (which
   can't be done the same way it's done with Ethereal - Ethereal, when
   checking for types of capture files seeks backwards to the beginning
   of the file and starts re-reading it for each new file type, but
   libpcap has to be able to read from a pipe and can't seek backward).

I think I still have some code to do 2), but I don't seem to have it
here at home, so I can't supply it now (and probably won't be able to do
so until Monday at the earliest).  If people think it's a reasonable
thing to add to libpcap, I could check it in once the CVS server is
available again.

I'd suggest looking into 1) - Ethereal should run on any modern Linux
distribution, and also runs on Solaris (just as tcpdump does - tcpdump
isn't a Linux-specific program; it was originally developed for, I
think, BSD and SunOS).  See

	http://www.ethereal.com/

or check whether it's installed on your ISP's Linux boxes already or
came with their Linux distribution - if not, you could download and
build it for on your Solaris boxes, although you'd have to download and
install GLib as well (and GTK+, if you want Ethereal itself).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[email protected]?body=unsubscribe

Sun Microsystems - BigAdmin Shell Commands

snoop -S -ta [machine] /* Snoop for network packets and get size and time stamp entries. */

2005-11-04

Recommended Links

Softpanorama Recommended

Top articles

Sites

Network Sniffers

SunService Tip Sheet for Miscellaneous Networking Programs

Solaris Network Troubleshooting

Tcpdump on Solaris

Snort on Solaris

Recommended Papers

SunService Tip Sheet for Miscellaneous Networking Programs Revision: 1.0Date: October 30, 1995

... ... ...

To see all the packets involving a certain machine:

# snoop machine-name

To see all the packets between two machines:

# snoop machine1 and machine2

To see all the packets on a network:

# snoop

Here's what a standard snoop output looks like:

Using device /dev/le (promiscuous mode)
jfn35 -> smiley-116 NFS C CREATE FH=5882 .cshrc
marlowe -> jfn35 TCP D=33237 S=48864 Ack=3354199170 Seq=2006870529 Len=0 Win=8632
smiley-116 -> jfn35 NFS R CREATE OK FH=6AD4
jfn35 -> smiley-116 NFS C WRITE FH=6AD4 at 0 for 10
smiley-116 -> jfn35 NFS R WRITE OK
sun-soft -> psi RLOGIN C port=1017
psi -> sun-soft RLOGIN R port=1017 /dev/le (promiscuous

You'll note that each line tells us the sending and the receiving machine, some information about what program is running, and some of the arguments that are being passed. For example, on the uot;.cshrc" and on the last line, we see the output being passed on by rlogin "/dev/le (promiscuous". For most packets, you'll see a message sent out (marked with a "C"), and then a reply to that message (marked with an "R").

A few things can be done to extract more information out of snoop.

To produce slightly verbose output:

# snoop -V

To produce very verbose output:

# snoop -v

The verbose output on snoop is very much so, and it's not very easy to look at in real time. For that reason, you can save snoop output to a file:

# snoop -o filename

You will just see an incrementing number as packets are saved. Hit ^C when you are down collecting information. You can then read the information back in:

# snoop -i filename

You can look at the entire snoop output in verbose mode:

# snoop -i filename -v

Alternatively, you can view individual packets in verbose mode:

# snoop -i filename -p12 -v

If you run 'snoop -i filename' and realize that packet 12 is the interesting one, you would then run the above command to see exactly what was in the twelfth packet.

snoop can give you extremely good information on exactly what each packet on the network contains. The snoop man page gives additional information on other snoop options.

snoop is only available under Solaris.

The Secrets of Snoop by Lance Spitzner Pretty weak and superficial paper

Sniffers have exploded in popularity over the past several years, from Network General's Netxray and Microsoft's Network Monitor, to public domain tools such as Etherman and Curry Sniffer. These tools are used for various reasons, including network troubleshooting, traffic analysis, node discovery, etc. We will be covering one of the most common, yet effective sniffers, snoop. Of all the sniffers, this is one standby you always have access to with Solaris. The purpose of this article is to demonstrate how to leverage snoop, with examples focusing on network security.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019