Network analyzers (Managing NFS and NIS, 2nd Edition)

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

# 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.

[33]In our examples, we reformat the output that tethereal generates by adding or removing white spaces to make it easier to read.

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