Managing NFS and NIS, 2nd Edition - Mike Eisler [202]
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.
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: