13.5. Network analyzers
Network analyzers are ultimately the most useful
tools available when it comes to
debugging network problems. They are powerful tools that allow you to
inspect network traffic at every level of the network stack in
various degrees of detail. Good network analyzers provide powerful
filters that reduce the amount of information to what is relevant for
the task at hand.
Snoop,
ethereal, and
tcpdump are
three of the most popular network analyzers available today.
Snoop and
ethereal provide
excellent support for RPC protocols
and we use them throughout the rest of
this book. The
snoop network analyzer is bundled
with Solaris, it provides powerful filters for analysis of problems
related to NFS, RPC and NIS.
ethereal is a
GUI-based network analyzer program available free of charge. It is
available for various types of operating systems, including many
flavors of Unix. These utilities require
superuser privileges in order to open the
network interface device.
13.5.1. snoop
The
snoop network analyzer bundled
with
Solaris
captures packets from the network and displays them in various forms
according to the set of filters specified.
Snoop
can capture network traffic and display it on the fly, or
save it into a file for future analysis.
Being able to save the network traffic into a file allows you to
display the same data set under various filters, presenting different
views of the same information.
In its simplest form,
snoop captures and
displays all packets present
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
Chapter 14, "NFS Diagnostic Tools". 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
available filters.
13.5.2. ethereal / tethereal
ethereal is an open source free network
analyzer
for Unix and Windows. It allows you to examine data from a live
network or from a capture file on disk. You can interactively browse
the capture data, viewing summary and detail information for each
packet. It is very similar in functionality to
snoop, although perhaps providing more powerful
and diversified filters. At the time of this writing,
ethereal is beta software and its developers
indicate that it is far from complete. Although new features are
continuously being added, it already has enough functionality to be
useful. We use version 0.8.4 of
ethereal in this
book. Some of the functionality, as well as look-and-feel may have
changed by the time you read these pages.
In addition to providing powerful display filters,
ethereal provides a very nice Graphical User
Interface (GUI) which allows you to interactively browse the captured
data, viewing summary and detailed information for each packet. The
official home of the
ethereal software is
http://www.zing.org. You can
download the source and documentation from this site and build it
yourself, or follow the links to download precompiled binary packages
for your environment. You can download precompiled Solaris packages
from
http://www.sunfreeware.com.
In either case, you will need to install the
GTK+ Open Source Free Software GUI Toolkit as
well as the
libpcap packet capture library. Both
are available on the
ethereal website.
tethereal is the text-only functional equivalent
of
ethereal. They
both
share a large amount of the source code in order to provide the same
level of data capture, filtering, and packet decoding. The main
difference is the user interface:
tethereal does
not provide the nice GUI provided by
ethereal.
Due to its textual output,
tethereal is used
throughout this book.
[33]
Examples and discussions concerning
tethereal
also apply to
ethereal. Many of the concepts
will overlap those presented in the
snoop
discussion, though the syntax will be different.
In its simplest form,
tethereal captures and
displays all packets present on the network interface:
# tethereal
Capturing on hme0
caramba -> schooner NFS V3 GETATTR Call XID 0x59048f4a
schooner -> caramba NFS V3 GETATTR Reply XID 0x59048f4a
caramba -> schooner TCP 1023 > nfsd [ACK] Seq=2139539358 Ack=1772042332
Win=24820 Len=0
concam -> 224.12.23.34 UDP Source port: 32939 Destination port: 7204
mp-broadcast -> 224.12.23.34 UDP Source port: 32852 Destination port: 7204
narwhal -> 224.12.23.34 UDP Source port: 32823 Destination port: 7204
vm-086 -> 224.0.0.2 HSRP Hello (state Active)
caramba -> mickey YPSERV V2 MATCH Call XID 0x39c4533d
mickey -> caramba YPSERV V2 MATCH Reply XID 0x39c4533d
By default
tethereal displays only a summary of
the highest level protocol. The first column displays the source and
destination of the network packet.
tethereal
maps the IP address to the hostname when possible, otherwise it
displays the IP address. You can use the
-n
option to disable network object name resolution and have the IP
addresses displayed instead. Each line displays the packet type, and
the protocol-specific parameters. For example, the first line
displays an NFS Version 3 GETATTR (get attributes) request from
client
caramba to server
schooner with RPC transaction ID 0x59048f4a. The
second line reports
schooner
's reply to the GETATTR request.
You know that this is a reply to the previous request because of the
matching transaction IDs.
Use the
-w option to have
tethereal write the packets to a data file for
later display. As with
snoop, this allows you to
apply powerful filters to the data set to reduce the amount of noise
reported. Use the
-c option to set the number of
packets to read when capturing data:
# tethereal -w /tmp/capture -c 5
Capturing on hme0
10
Use the
-r option to read packets from a capture
file:
# tethereal -r /tmp/capture -t d
1 0.000000 caramba -> mickey PORTMAP V2 GETPORT Call XID 0x39c87b6e
2 0.000728 mickey -> caramba PORTMAP V2 GETPORT Reply XID 0x39c87b6e
3 0.00077 caramba -> mickey NFS V3 NULL Call XID 0x39c87b6f
4 0.000416 mickey -> caramba NFS V3 NULL Reply XID 0x39c87b6f
5 0.001957 caramba -> mickey PORTMAP V2 GETPORT Call XID 0x39c848db
tethereal reads the packets from the
/tmp/capture file specified by the
-r option. 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. The
-t d option instructs
tethereal to use delta timestamps, if not
specified,
tethereal reports timestamps relative
to the time elapsed between the first packet and the current packet.
Use the
-t a option to display the actual date
and time the packet was captured.
tethereal can
also read capture files generated by other network analyzers,
including
snoop's capture files.
As mentioned in the
snoop discussion, network
analyzers are most useful when you have the ability to filter the
information you need. One of
tethereal 's
strongest attributes is its rich filter set. Unlike
snoop,
tethereal uses
different syntax for capture and display filters. Display filters are
called read filters in
tethereal, therefore we
will use the
tethereal terminology during this
discussion. Note that a read filter can also be specified during
packet capturing, causing only packets that pass the read filter to
be displayed or saved to the output file. Capture filters are much
more efficient than read filters. It may be more difficult for
tethereal to keep up with a busy network if a
read filter is specified during
a live capture.
13.5.3. Capture filters
Packet capture and filtering is performed by the
Packet Capture
Library
(
libpcap). Use the
-f
option to set the capture filter expression:
# tethereal -f "dst host donald"
Capturing on hme0
schooner -> donald TCP nfsd > 1023 [PSH, ACK] Seq=1773285388 Ack=2152316770
Win=49640 Len=116
mickey -> donald UDP Source port: 934 Destination port: 61638
mickey -> donald UDP Source port: 934 Destination port: 61638
mickey -> donald UDP Source port: 934 Destination port: 61638
schooner -> donald TCP nfsd > 1023 [PSH, ACK] Seq=1773285504 Ack=2152316882
Win=49640 Len=116
The
dst host filter instructs
tethereal to only capture packets with a
destination address equal to
donald. You can
specify the IP address or the hostname, and
tethereal will use the name service switch to do
the conversion. Substitute
dst with
src and
tethereal captures
packets with a source address equal to
donald.
Simply specifying
host
donald captures packets with either source or
destination addresses equal to
donald.
Use protocol capture filters to instruct
tethereal to capture all network packets using
the specified protocol, regardless of origin, destination, packet
length, etc:
# tethereal -f "arp"
Sun_a0:33:90 -> ff:ff:ff:ff:ff:ff ARP Who has 131.40.51.7? Tell 131.40.51.125
Sun_b9:2b:f6 -> Sun_a0:33:90 ARP 131.40.51.223 is at 08:00:20:b9:2b:f6
00:90:2b:71:e0:00 -> ff:ff:ff:ff:ff:ff ARP Who has 131.40.51.77? Tell 131.40.51.17
The
arp filter instructs
tethereal to capture all of the ARP packets on
the network. Notice that
tethereal replaces the
Ethernet address prefix with the
Sun_ identifier
(08:00:20). The list of prefixes known to
tethereal can be found in
/
etc/manuf file located in the
tethereal installation directory.
Use the
and,
or, and
not logical operators to build complex and
powerful filters:
# tethereal -w /tmp/capture -f "host 131.40.51.7 and arp"
# tethereal -r /tmp/capture
Sun_a0:33:90 -> ff:ff:ff:ff:ff:ff ARP Who has 131.40.51.7? Tell 131.40.51.125
Sun_b9:2b:f6 -> Sun_a0:33:90 ARP 131.40.51.7 is at 08:00:20:b9:2b:f6
tethereal captures all ARP requests for the
131.40.51.7 address and writes the packets to the
/tmp/capture file. We should point out that the
source address of the first packet is not 131.40.51.7, and highlight
the fact that the destination address is the Ethernet broadcast
address. You may ask then, why is this packet captured by
tethereal if neither the source nor destination
address match the requested host? You can use the
-V option to analyze the contents of the
captured packet to answer this question:
# tethereal -r /tmp/ether -V
Frame 1 (60 on wire, 60 captured)
Arrival Time: Sep 25, 2000 13:34:08.2305
Time delta from previous packet: 0.000000 seconds
Frame Number: 1
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II
Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source: 08:00:20:a0:33:90 (Sun_a0:33:90)
Type: ARP (0x0806)
Address Resolution Protocol (request)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (0x0001)
Sender hardware address: 08:00:20:a0:33:90
Sender protocol address: 131.40.51.125
Target hardware address: ff:ff:ff:ff:ff:ff
Target protocol address: 131.40.51.7
...
(Contents of second packet have been omitted)
The
-V option displays the full protocol tree.
Each layer of the packet is printed in detail (for clarity, we omit
printing the contents of the second packet). The frame information is
added by
tethereal to identify the network
packet. Note that the frame information is not part of the actual
network packet, and is therefore not transmitted over the wire.
The Ethernet frame displays the broadcast destination address, and
the source MAC address. Notice how the 08:00:20 prefix is replaced by
the
Sun_ identifier. The Address Resolution
Protocol (ARP) part of the frame, indicates that this is a request
asking for the hardware address of 131.40.51.7. This explains why
tethereal captures the packet when the
host 131.40.51.7 and arp filter is specified.
Use the
not operator to specify the criteria of
packets that you wish to have excluded during capture. For example,
use the
not operator to capture all network
packets, except ARP related network traffic:
# tethereal -f "not arp"
Capturing on hme0
concam -> 224.12.23.34 UDP Source port: 32939 Destination port: 7204
donald -> schooner TCP 1023 > nfsd [ACK] Seq=2153618946 Ack=1773368360 Win=24820 Len=0
narwhal -> 224.12.23.34 UDP Source port: 32823 Destination port: 7204
donald -> schooner NFS V3 GETATTR Call XID 0x5904b03e
schooner -> caramba NFS V3 GETATTR Reply XID 0x5904b03e
This section discussed how to restrict the amount of information
captured by
tethereal. In the next section, you
see how to apply the more powerful read filters to find the exact
information you need. Refer to
tethereal
's documentation
for a complete set of capture filters.
13.5.4. Read filters
Capture filters provide limited means
of refining the amount of information
gathered. To complement them,
tethereal provides
a rich read (display) filter language used to build powerful filters.
Read filters further remove the noise from a packet trace to let you
see packets of interest. A packet is displayed if it meets the
requirements expressed in the filter. Read filters let you compare
the fields within a protocol against a specific value, compare fields
against fields, or simply check the existence of specified fields and
protocols.
Use the
-R option to specify a read filter. The
simplest read filter allows you to check for the existence of a
protocol or field:
# tethereal -r /tmp/capture -R "nfs"
3 0.001500 caramba -> mickey NFS V3 NULL Call XID 0x39c87b6f
4 0.001916 mickey -> caramba NFS V3 NULL Reply XID 0x39c87b6f
54 2.307132 caramba -> schooner NFS V3 GETATTR Call XID 0x590289e7
55 2.308824 schooner -> caramba NFS V3 GETATTR Reply XID 0x590289e7
56 2.309622 caramba -> mickey NFS V3 LOOKUP Call XID 0x590289e8
57 2.310400 mickey -> caramba NFS V3 LOOKUP Reply XID 0x590289e8
tethereal reads the capture file
/tmp/capture and displays all packets that
contain the NFS protocol.
You can specify a filter that matches the existence of a given field
in the network packet. For example, use the
nfs.name filter to instruct
tethereal to display all packets containing the
NFS
name field in either requests or replies:
# tethereal -r /tmp/capture -R "nfs.name"
56 2.309622 caramba -> mickey NFS V3 LOOKUP Call XID 0x590289e8
57 2.310400 mickey -> caramba NFS V3 LOOKUP Reply XID 0x590289e8
You can also specify the value of the field. For example use the
frame.number == 56 filter, to display packet
number 56:
# tethereal -r /tmp/capture -R "frame.number == 56"
56 2.309622 caramba -> mickey NFS V3 LOOKUP Call XID 0x590289e8
This is equivalent to
snoop's
-p option. You can also specify ranges of values
of a field. For example, you can print the first three packets in the
capture file by specifying a range for
frame.number:
# tethereal -r /tmp/capture -R "frame.number <= 3"
1 0.000000 caramba -> mickey PORTMAP V2 GETPORT Call XID 0x39c87b6e
2 0.000728 mickey -> caramba PORTMAP V2 GETPORT Reply XID 0x39c87b6e
3 0.001500 caramba -> mickey NFS V3 NULL Call XID 0x39c87b6f
You can combine basic filter expressions and field values by using
logical operators to build more powerful filters. For example, say
you want to list all NFS Version 3
Lookup and
Getattr operations. You know that NFS is an RPC
program, therefore you first need to determine the procedure number
for the NFS operations by finding their definition in the
nfs.h include file:
$ grep NFSPROC3_LOOKUP /usr/include/nfs/nfs.h
#define NFSPROC3_LOOKUP ((rpcproc_t)3)
$ grep NFSPROC3_GETATTR /usr/include/nfs/nfs.h
#define NFSPROC3_GETATTR ((rpcproc_t)1)
The two
grep operations help you determine that
the NFS
Lookup operation is RPC procedure number
3 of the NFS Version 3 protocol, and the NFS
Getattr operation is procedure number 1. You can
then use this information to build a filter that specifies your
interest in protocol NFS with RPC program Version 3, and RPC
procedures 1 or 3. You can represent this with the filter expression:
nfs and rpc.programversion == 3 and(rpc.procedure == 1 or rpc.procedure == 3)
The
tethereal invocation follows:
# tethereal -r /tmp/capture -R "nfs and rpc.programversion == 3 and \
(rpc.procedure == 1 or rpc.procedure == 3)"
54 2.307132 caramba -> schooner NFS V3 GETATTR Call XID 0x590289e7
55 2.308824 schooner -> caramba NFS V3 GETATTR Reply XID 0x590289e7
56 2.309622 caramba -> mickey NFS V3 LOOKUP Call XID 0x590289e8
57 2.310400 mickey -> caramba NFS V3 LOOKUP Reply XID 0x590289e8
The filter displays all NFS Version 3
Getattr
and all NFS Version 3
Lookup operations. Refer
to
tethereal 's documentation for a
complete description of the rich filters provided. In
Chapter 14, "NFS Diagnostic Tools", you will see how
to use
tethereal to
debug NFS-
related
problems.
| | |
13.4. NIS tools | | 14. NFS Diagnostic Tools |