on the network interface:
# snoop
Using device /dev/hme (promiscuous mode)
narwhal -> 192.32.99.10 UDP D=7204 S=32823 LEN=252
2100::56:a00:20ff:fe8f:ba43 -> ff02::1:ffb6:12ac ICMPv6 Neighbor solicitation
caramba -> schooner NFS C GETATTR3 FH=0CAE
schooner -> caramba NFS R GETATTR3 OK
caramba -> schooner TCP D=2049 S=1023 Ack=341433529 Seq=2752257980 Len=0 Win=24820
caramba -> schooner NFS C GETATTR3 FH=B083
schooner -> caramba NFS R GETATTR3 OK
mp-broadcast -> 224.12.23.34 UDP D=7204 S=32852 LEN=177
caramba -> schooner TCP D=2049 S=1023 Ack=341433645 Seq=2752258092 Len=0 Win=24820
...
By default snoop displays only a summary of the
data pertaining to the highest level protocol. The first column
displays the source and destination of the network packet in the form
"source -> destination".
Snoop maps the IP address to the hostname when
possible, otherwise it displays the IP address. The second column
lists the highest level protocol type. The first line of the example
shows the host narwhal sending a request to the
address 192.32.99.10 over UDP. The second line shows a neighbor
solicitation request initiated by the host with global IPv6 address
2100::56:a00:20ff:fe8f:ba43. The destination is a
link-local multicast address (prefix FF02:). The contents of the
third column depend on the protocol. For example, the 252 byte-long
UDP packet in the first line has a destination port = 7204 and a
source port= 32823. NFS packets use a C to
denote a call, and an R to denote a reply,
listing the procedure being invoked.
The fourth packet in the example is the reply from the NFS server
schooner to the client
caramba. It reports that the NFS GETATTR (get
attributes) call returned success, but it doesn't display the
contents of the attributes. Snoop simply
displays the summary of the packet before disposing of it. You can
not obtain more details about this particular packet since the packet
was not saved. To avoid this limitation, snoop
should be instructed to save the captured network packets in a file
for later processing and display by using the -o
option:
# snoop -o /tmp/capture -c 100
Using device /dev/hme (promiscuous mode)
100 100 packets captured
The -o option instructs
snoop to save the captured packets in the
/tmp/capture file. The capture file mode bits
are set using root 's file mode creation
mask. Non-privileged users may be able to invoke
snoop and process the captured file if given
read access to the capture file. The
-c option instructs snoop
to capture only 100 packets. Alternatively, you can interrupt
snoop when you believe you have captured enough
packets.
The captured packets can then be analyzed as many times as necessary
under different filters, each presenting a different view of data.
Use the -i option to instruct
snoop where to read the captured packets from:
# snoop -i /tmp/capture -c 5
1 0.00000 caramba -> mickey PORTMAP C GETPORT prog=100003 (NFS)
vers=3 proto=UDP
2 0.00072 mickey -> caramba PORTMAP R GETPORT port=2049
3 0.00077 caramba -> mickey NFS C NULL3
4 0.00041 mickey -> caramba NFS R NULL3
5 0.00195 caramba -> mickey PORTMAP C GETPORT prog=100003 (NFS)
vers=3 proto=UDP
5 packets captured
The -i option instructs
snoop to read the packets from the
/tmp/capture capture file instead of capturing
new packets from the network device. Note that two new columns are
added to the display. The first column displays the packet number,
and the second column displays the time delta between one packet and
the next in seconds. For example, the second packet's time
delta indicates that the host caramba received a
reply to its original portmap request 720 microseconds after the
request was first sent.
By default, snoop displays summary information
for the top-most protocol in the network stack for every packet. Use
the -V option to instruct snoop to display
information about every level in the network stack. You can also
specify packets or a range of them with the -p
option:
# snoop -i /tmp/capture -V -p 3,4
_______________________________ _
3 0.00000 caramba -> mickey ETHER Type=0800 (IP), size = 82 bytes
3 0.00000 caramba -> mickey IP D=131.40.52.27 S=131.40.52.223 LEN=68,
ID=35462
3 0.00000 caramba -> mickey UDP D=2049 S=55559 LEN=48
3 0.00000 caramba -> mickey RPC C XID=969440111 PROG=100003 (NFS)
VERS=3 PROC=0
3 0.00000 caramba -> mickey NFS C NULL3
_______________________________ _
4 0.00041 mickey -> caramba ETHER Type=0800 (IP), size = 66 bytes
4 0.00041 mickey -> caramba IP D=131.40.52.223 S=131.40.52.27 LEN=52,
ID=26344
4 0.00041 mickey -> caramba UDP D=55559 S=2049 LEN=32
4 0.00041 mickey -> caramba RPC R (#3) XID=969440111 Success
4 0.00041 mickey -> caramba NFS R NULL3
The -V option instructs
snoop to display a summary line for each
protocol layer in the packet. In the previous example, packet 3 shows
the Ethernet, IP, UDP, and RPC summary information, in addition to
the NFS NULL request. The -p option is used to
specify what packets are to be displayed, in this case
snoop displays packets 3 and 4.
Every layer of the network stack contains a wealth of information
that is not displayed with the -V option. Use
the -v option when you're interested in
analyzing the full details of any of the network layers:
# snoop -i /tmp/capture -v -p 3
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 3 arrived at 15:08:43.35
ETHER: Packet size = 82 bytes
ETHER: Destination = 0:0:c:7:ac:56, Cisco
ETHER: Source = 8:0:20:b9:2b:f6, 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 = 68 bytes
IP: Identification = 35462
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 = 17 (UDP)
IP: Header checksum = 4503
IP: Source address = 131.40.52.223, caramba
IP: Destination address = 131.40.52.27, mickey
IP: No options
IP:
UDP: ----- UDP Header -----
UDP:
UDP: Source port = 55559
UDP: Destination port = 2049 (Sun RPC)
UDP: Length = 48
UDP: Checksum = 3685
UDP:
RPC: ----- SUN RPC Header -----
RPC:
RPC: Transaction id = 969440111
RPC: Type = 0 (Call)
RPC: RPC version = 2
RPC: Program = 100003 (NFS), version = 3, procedure = 0
RPC: Credentials: Flavor = 0 (None), len = 0 bytes
RPC: Verifier : Flavor = 0 (None), len = 0 bytes
RPC:
NFS: ----- Sun NFS -----
NFS:
NFS: Proc = 0 (Null procedure)
NFS:
The Ethernet header displays the source and destination addresses as
well as the type of information embedded in the packet. The IP layer
displays the IP version number, flags, options, and address of the
sender and recipient of the packet. The UDP header displays the
source and destination ports, along with the length and checksum of
the UDP portion of the packet. Embedded in the UDP frame is the RPC
data. Every RPC packet has a transaction ID used by the sender to
identify replies to its requests, and by the server to identify
duplicate calls. The previous example shows a request from the host
caramba to the server
mickey. The RPC version = 2 refers to the
version of the RPC protocol itself, the program number 100003 and
Version 3 apply to the NFS service. NFS procedure 0 is always the
NULL procedure, and is most commonly invoked with no authentication
information. The NFS NULL procedure does not take any arguments,
therefore none are listed in the NFS portion of the packet.
The amount of traffic on a busy network can be overwhelming,
containing many irrelevant packets to the problem at hand. The use of
filters reduces the amount of noise captured and displayed, allowing
you to focus on relevant data. A filter can be applied at the time
the data is captured, or at the time the data is displayed. Applying
the filter at capture time reduces the amount of data that needs to
be stored and processed during display. Applying the filter at
display time allows you to further refine the previously captured
information. You will find yourself applying different display
filters to the same data set as you narrow the problem down, and
isolate the network packets of interest.
Snoop uses the same syntax for capture and
display filters. For example, the host filter
instructs snoop to only capture packets with
source or destination address matching the specified host:
# snoop host caramba
Using device /dev/hme (promiscuous mode)
caramba -> schooner NFS C GETATTR3 FH=B083
schooner -> caramba NFS R GETATTR3 OK
caramba -> schooner TCP D=2049 S=1023 Ack=3647506101 Seq=2611574902 Len=0 Win=24820
In this example the host filter instructs
snoop to capture packets originating at or
addressed to the host caramba. You can specify
the IP address or the hostname, and snoop will
use the name service switch to do the conversion.
Snoop assumes that the hostname specified is an
IPv4 address. You can specify an IPv6 address by using the
inet6 qualifier in front of the
host filter:
# snoop inet6 host caramba
Using device /dev/hme (promiscuous mode)
caramba -> 2100::56:a00:20ff:fea0:3390 ICMPv6 Neighbor advertisement
2100::56:a00:20ff:fea0:3390 -> caramba ICMPv6 Echo request (ID: 1294 Sequence number: 0)
caramba -> 2100::56:a00:20ff:fea0:3390 ICMPv6 Echo reply (ID: 1294 Sequence number: 0)
You can restrict capture of traffic addressed to the specified host
by using the to or dst
qualifier in front of the host filter:
# snoop to host caramba
Using device /dev/hme (promiscuous mode)
schooner -> caramba RPC R XID=1493500696 Success
schooner -> caramba RPC R XID=1493500697 Success
schooner -> caramba RPC R XID=1493500698 Success
Similarly you can restrict captured traffic to only packets
originating from the specified host by using the
from or src qualifier:
# snoop from host caramba
Using device /dev/hme (promiscuous mode)
caramba -> schooner NFS C GETATTR3 FH=B083
caramba -> schooner TCP D=2049 S=1023 Ack=3647527137 Seq=2611841034 Len=0 Win=24820
Note that the host keyword is not required when
the specified hostname does not conflict with the name of another
snoop primitive.The previous snoop
from host caramba command could have been invoked without
the host keyword and it would have generated the
same output:
# snoop from caramba
Using device /dev/hme (promiscuous mode)
caramba -> schooner NFS C GETATTR3 FH=B083
caramba -> schooner TCP D=2049 S=1023 Ack=3647527137 Seq=2611841034 Len=0 Win=24820
For clarity, we use the host keyword throughout
this book. Two or more filters can be combined by using the logical
operators and and or :
# snoop -o /tmp/capture -c 20 from host caramba and rpc nfs 3
Using device /dev/hme (promiscuous mode)
20 20 packets captured
Snoop captures all NFS Version 3 packets
originating at the host caramba. Here,
snoop is invoked with the
-c and -o options to save
20 filtered packets into the /tmp/capture file.
We can later apply other filters during display time to further
analyze the captured information. For example, you may want to narrow
the previous search even further by only listing TCP traffic by using
the proto filter:
# snoop -i /tmp/capture proto tcp
Using device /dev/hme (promiscuous mode)
1 0.00000 caramba -> schooner NFS C GETATTR3 FH=B083
2 2.91969 caramba -> schooner NFS C GETATTR3 FH=0CAE
9 0.37944 caramba -> rea NFS C FSINFO3 FH=0156
10 0.00430 caramba -> rea NFS C GETATTR3 FH=0156
11 0.00365 caramba -> rea NFS C ACCESS3 FH=0156 (lookup)
14 0.00256 caramba -> rea NFS C LOOKUP3 FH=F244 libc.so.1
15 0.00411 caramba -> rea NFS C ACCESS3 FH=772D (lookup)
Snoop reads the previously filtered data from
/tmp/capture, and applies the new filter to only
display TCP traffic. The resulting output is NFS traffic originating
at the host caramba over the TCP protocol. We
can apply a UDP filter to the same NFS traffic in the
/tmp/capture file and obtain the NFS Version 3
traffic over UDP from host caramba without
affecting the information in the /tmp/capture
file:
# snoop -i /tmp/capture proto udp
Using device /dev/hme (promiscuous mode)
1 0.00000 caramba -> rea NFS C NULL3
So far, we've presented filters that let you specify the
information you are interested in. Use the not
operator to specify the criteria of packets that you wish to have
excluded during capture. For example, you can use the
not operator to capture all network traffic,
except that generated by the remote shell:
# snoop not port login
Using device /dev/hme (promiscuous mode)
rt-086 -> BROADCAST RIP R (25 destinations)
rt-086 -> BROADCAST RIP R (10 destinations)
caramba -> schooner NFS C GETATTR3 FH=B083
schooner -> caramba NFS R GETATTR3 OK
caramba -> donald NFS C GETATTR3 FH=00BD
jamboree -> donald NFS R GETATTR3 OK
caramba -> donald TCP D=2049 S=657 Ack=3855205229 Seq=2331839250 Len=0 Win=24820
caramba -> schooner TCP D=2049 S=1023 Ack=3647569565 Seq=2612134974 Len=0 Win=24820
narwhal -> 224.2.127.254 UDP D=9875 S=32825 LEN=368
On multihomed hosts (systems with more than one network interface
device), use the -d option to specify the
particular network interface to snoop on:
snoop -d hme2
You can snoop on multiple network interfaces
concurrently by invoking separate instances of
snoop on each device. This is particularly
useful when you don't know what interface the host will use to
generate or receive the requests. The -d option
can be used in conjunction with any of the other options and filters
previously described:
# snoop -o /tmp/capture-hme0 -d hme0 not port login &
# snoop -o /tmp/capture-hme1 -d hme1 not port login &
Filters help refine the search for relevant packets. Once the packets
of interest have been found, use the -V or
-v options to display the packets in more
detail. You will see how this top-down technique is used to debug
NFS-related problems in . Often you can
use more than one filter to achieve the same result. Refer to the
documentation shipped with your OS for a complete list of