Managing NFS and NIS, 2nd Edition - Mike Eisler [214]
11 0.012102 zeus -> rome TCP 33168 > 49699 [ACK] Seq=3939269367
Ack=1251769973 Win=24776 Len=0
12 0.018302 zeus -> rome MOUNT V1 EXPORT Reply XID 0x398f20d9
13 0.018332 rome -> zeus TCP 49699 > 33168 [ACK] Seq=1251769973
Ack=3939269463 Win=24820 Len=0
14 0.018588 rome -> zeus TCP 49699 > 33168 [FIN, ACK] Seq=1251769973
Ack=3939269463 Win=24820 Len=0
15 0.019245 zeus -> rome TCP 33168 > 49699 [ACK] Seq=3939269463
Ack=1251769974 Win=24820 Len=0
16 0.020104 zeus -> rome TCP 33168 > 49699 [FIN, ACK] Seq=3939269463
Ack=1251769974 Win=24820 Len=0
17 0.020143 rome -> zeus TCP 49699 > 33168 [ACK] Seq=1251769974
Ack=3939269464 Win=24820 Len=0
18 0.020661 rome -> zeus PORTMAP V2 GETPORT Call XID 0x398f0440
19 0.024550 zeus -> rome PORTMAP V2 GETPORT Reply XID 0x398f0440
20 0.024731 rome -> zeus MOUNT V3 NULL Call XID 0x398f0441
21 0.026323 zeus -> rome MOUNT V3 NULL Reply XID 0x398f0441
22 0.026881 rome -> zeus MOUNT V3 MNT Call XID 0x398f0442
23 0.179757 zeus -> rome MOUNT V3 MNT Reply XID 0x398f0442
The explanation given in the snoop section describing each packet applies to the tethereal capture file as well. The main difference is that listing the XID next to the operation type is less intuitive than expanding the arguments to the call as performed by snoop. We suspect this will be addressed in the future. You can see that the reason for failure is not obvious by just looking at this output format.
Fortunately, tethereal has extensive filtering capabilities and we can request all mount operations that failed. Using the mount.status filter, we determine that packet 23 returned a failure. We can then print the protocol tree for packet 23 alone and verify that indeed it failed with ERR_ACCESS:
rome# tethereal -r /tmp/ethereal.cap -R "mount.status != 0"
23 0.179757 zeus -> rome MOUNT V3 MNT Reply XID 0x398f0442
rome# tethereal -r /tmp/ethereal.cap -V -R "frame.number == 23"
...
Remote Procedure Call
XID: 0x398f0442 (965674050)
Message Type: Reply (1)
Program: MOUNT (100005)
Program Version: 3
Procedure: MNT (1)
Reply State: accepted (0)
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Mount Service
Program Version: 3
Procedure: MNT (1)
Status: ERR_ACCESS (13)
For simplicity, only the RPC and Mount portions of the packet are shown. The RPC header decodes the transaction ID, message type indicating this to be a reply, program, and version number as well as the procedure invoked. The credential verifier is also decoded indicating that the server used no verifier in its reply (since the call did not specify it to begin with). A nice feature of snoop, that tethereal does not yet have, is the ability to indicate the frame for which this is a reply.
As expected, the status field of the mount service reply reports an error. Packet 12 contains the results of the export information request:
rome# tethereal -r /tmp/ethereal.cap -V -R "frame.number == 12"
...
Remote Procedure Call
Last Fragment: Yes
Fragment Length: 92
XID: 0x398f20d9 (965681369)
Message Type: Reply (1)
Program: MOUNT (100005)
Program Version: 1
Procedure: EXPORT (5)
Reply State: accepted (0)
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Accept State: RPC executed successfully (0)
Mount Service
Program Version: 1
Procedure: EXPORT (5)
Data (68 bytes)
0 0000 0001 0000 000b 2f65 7870 6f72 742f ......../export/
10 656e 6700 0000 0000 0000 0001 0000 000c eng.............
20 2f65 7870 6f72 742f 686f 6d65 0000 0001 /export/home....
30 0000 0006 7665 726f 6e61 0000 0000 0000 ....verona......
40 0000 0000 ....
The Data field of the Mount packet shows a hex dump of the export list. The interpreted text value is in the far right column. We can see how the export list is encoded into the packet as a set of exported directories , each followed by the list of hosts (or group of hosts) that they give access to.
Useful filters
Read filters help you remove the noise from a packet trace and let you see only the packets that interest you. If a packet meets