| SNOOP(8) | Maintenance Commands and Procedures | SNOOP(8) |
snoop - capture and inspect network packets
snoop [-afqrCDINPSvV] [-t [r | a | d]] [-c maxcount]
[-d device] [-i filename] [-n filename]
[-o filename | -O prefix:count:size]
[-p first [, last]] [-s snaplen] [-x offset [, length]]
[expression]
From a datalink or IP interface, snoop captures packets and displays their contents. If the datalink or IP interface is not specified, snoop will pick a datalink to use, giving priority to datalinks that have been plumbed for IP traffic. snoop uses the pfmod(4M) and bufmod(4M) STREAMS modules to provide efficient capture of packets from the network. Captured packets can be displayed as they are received or saved to a file (which is RFC 1761-compliant) for later inspection.
snoop can display packets in a single-line summary form or in verbose multi-line forms. In summary form, with the exception of certain VLAN packets, only the data pertaining to the highest level protocol is displayed. If a packet has a VLAN header and its VLAN ID is non-zero, then snoop will show that the packet is VLAN tagged. For example, an NFS packet will have only NFS information displayed. Except for VLAN information under the condition just described, the underlying RPC, UDP, IP, and Ethernet frame information is suppressed, but can be displayed if either of the verbose options are chosen.
In the absence of a name service, such as LDAP or NIS, snoop displays host names as numeric IP addresses.
snoop requires an interactive interface.
-C
-D
-N
-I interface
-P
-S
-V
-a
-c maxcount
-d datalink
-f
-i filename
-n filename
-o filename
-O prefix:count:size
This option is useful when you want to keep only the most recent part of a capture (sometimes called a "rolling" capture), where you're watching for some event that's difficult to reproduce, and will stop the capture just after the event happens.
For example, to make snoop keep the last 200 megabytes stored in 20 files named test1-??.snoop, run:
After the snoop capture is terminated, the collection of output files may be combined into one using mergecap (part of a Wireshark installation) as follows:
The order of files given to mergecap does not matter, because the packet time stamps determine the output order.
-p first [ , last ]
-q
-r
-s snaplen
-t [ r | a | d ]
-v
-xoffset [ , length]
expression
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 for information about setting up more efficient filters.
The primitives are:
host hostname
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 associated with hostname.
inet or inet6
ipaddr, atalkaddr, or etheraddr
from or src
to or dst
ether
ethertype number
ip, ip6, arp, rarp, pppoed, pppoes
vlan
vlan-id id
pppoe
broadcast
multicast
bootp, dhcp
dhcp6
apple
decnet
greater length
less length
udp, tcp, icmp, icmp6, ah, esp
net net
port port
rpc prog [ , vers [ , proc ] ]
zone zoneid
ldap
gateway host
nofrag
expr relop expr
base[expr [: size ] ]
where expr evaluates the value of an offset into the packet from a base offset which may be ether, ip, ip6, 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
or or ,
not or !
slp
sctp
ospf
Example 1 Using the snoop Command
Capture all packets and display them as they are received:
example# snoop
Capture packets with host funky as either the source or destination and display them as they are received:
example# snoop funky
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 -p 99,108
99 0.0027 boutique -> sunroof NFS C GETATTR FH=8E6 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 = 172.16.40.222, boutique IP: Destination address = 172.16.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=172.16.40.222 S=172.16.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 parentheses 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 efficient way to filter is to move the OR to the end of the expression and to use parentheses to enforce the OR between tcp and udp:
example# snoop funky and pinky and (tcp or udp) and port 80
0
1
/dev/audio
/dev/null
/etc/hosts
/etc/rpc
/etc/services
See attributes(7) for descriptions of the following attributes:
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Interface Stability | Committed |
For all options except -O.
ipnet(4D), audio(4I), bufmod(4M), pfmod(4M), dlpi(4P), hosts(5), rpc(5), services(5), attributes(7), dladm(8), ifconfig(8), netstat(8)
Callaghan, B. and Gilligan, R. RFC 1761, Snoop Version 2 Packet Capture File Format. Network Working Group. February 1995.
The processing overhead is much higher for real-time packet interpretation. Consequently, the packet drop count may be higher. For more reliable capture, output raw packets to a file using the -o option and analyze the packets offline.
Unfiltered packet capture imposes a heavy processing load on the host computer, particularly if the captured packets are interpreted real-time. This processing load further increases if verbose options are used. Since heavy use of snoop may deny computing resources to other processes, it should not be used on production servers. Heavy use of snoop should be restricted to a dedicated computer.
snoop does not reassemble IP fragments. Interpretation of higher level protocol halts at the end of the first IP fragment.
snoop may generate extra packets as a side-effect of its use. For example it may use a network name service to convert IP addresses to host names for display. Capturing into a file for later display can be used to postpone the address-to-name mapping until after the capture session is complete. Capturing into an NFS-mounted file may also generate extra packets.
Setting the snaplen (-s option) to small values may remove header information that is needed to interpret higher level protocols. The exact cutoff value depends on the network and protocols being used. For NFS Version 2 traffic using UDP on 10 Mb/s Ethernet, do not set snaplen less than 150 bytes. For NFS Version 3 traffic using TCP on 100 Mb/s Ethernet, snaplen should be 250 bytes or more.
snoop requires information from an RPC request to fully interpret an RPC reply. If an RPC reply in a capture file or packet range does not have a request preceding it, then only the RPC reply header will be displayed.
| July 13, 2023 | OmniOS |