3

Fairly simple question... I'm running tcpdump and trying to analyze the contents of the TCP packets between server/client. I see the "GETATTR" RPC being received, which is great! However, I want to know the file for which the RPC is being made. I'm assuming this is in the packet content. When I print the tcpdump as ASCII.

From server:
tcpdump -vvv -s 200 port 2049 
14:45:38.408949 IP (tos 0x0, ttl 64, id 58408, offset 0, flags [DF], proto TCP (6), length 296)
myserver.nfs > myclient.2469839164: reply ok 240 getattr NON 3 ids 0/3 sz 0

Here and other sites show that it is possible to map to filenames. Maybe it's platform dependent? I just want to make sure there isn't an obvious option to tcpdump that I am missing.

I'm running RH5 - Kernel 2.6.32-279.el6.x86_64

  • have you tried -X which does a hexdump of the packet payload? – Drav Sloan Sep 12 '13 at 15:16
  • Yep - That's not very helpful, unless I'm missing something... Using the "-A" option just converts that to ASCII chars. I'm not totally up to snuff on NFS RPC, but apparently the request is in some binary format that something (tcpdump?) should be able to decipher. That's my hope anyway. I'm playing around with wireshark right now. – Jmoney38 Sep 12 '13 at 15:27
  • 1
    Not sure if it will help but from the RPC specification forthe NFSv3: ietf.org/rfc/rfc1813.txt it says " object The file handle of an object whose attributes are to be retrieved." SO I guess you will need to map the file handle from the tcpdump to the OS. – BitsOfNix Sep 12 '13 at 16:54
  • Right, I've seen some discussion about filehandles and inode results, but from what I'm getting on RH, I don't see anything that looks like a FH or inode. What I'm starting to conclude is that RH handles the RPC implementation differently. – Jmoney38 Sep 12 '13 at 16:58
  • What operation are you trying to do on the file? For instance, if I do vi filename, I can see a NFS call Open DH: hex value <filename>. NFSv4 after the GETATTR – BitsOfNix Sep 12 '13 at 18:24
2

Ok, So I think I managed to find a "workaround". You won't be able to get the filename using NFSv3 but you will be able to ge the inode.

Using Wireshark,

Go to Edit -> Preferences -> Protocols -> NFS -> check all boxes and set "Decode nfs handles as: KNFSD_LE.

Save it. Now capture and filter by NFS protocol.

Search the packet GETATTR Reply (Call in #) Regular file mode: ???.

Open this packed and expand the following:

Network File System -> obj_attributes 

check value fileid, this will be the inode number of the file.

on the server go to the nfs share and

find . -inum inode

With NFSv4 you see a call with the filename directly.

  • 1
    I can't run the GUI, unfortunately. I'm only working with tshark. But with your help, I managed to get some inodes! For future reference: tshark -V -d tcp.port==2049,rpc host 192.168.210.194 -o 'nfs.file_name_snooping:TRUE' -o 'nfs.file_full_name_snooping:TRUE' -o 'nfs.default_fhandle_type:KNFSD_LE' -s 300 – Jmoney38 Sep 12 '13 at 19:49
2

You can take a look at nfstrace tool on github: (https://github.com/epam/nfstrace). It traces all captured NFSv3/NFSv4 procedures.

0

RedHat's (and any) NFS v3 impementation will indeed use a file handle on most operations, instead of a name. If you don't see the handle with wireshark, keep expanding parts of the packet until you find it. Some packets will contain a handle for the target object and for it's parent directory, so look at it carefully. On NFS CALLs, wireshark's summary "Info" line will often show a hash which is a shrunken down version of the handle. The problem is that without "other information" or access to the machine in question (for example, if you are analyzing someone else's packets), the file handle is not a very helpful piece of information.

You can search the packets which came before for the handle or it's hash, and hope that you can find some place where the same file handle is present in a way that associates it with a filename. For example, a lookup will result in a reply that contains the file's handle. Or the reply of a create operation will show the handle of the object which was just created. Or if a "readdirplus" sequence is present and packets were not truncated, you likely can get the information from there.

Or course, in many cases, the nfs mount has been in use for a while, and the original call which caused the client to "learn" the handle which goes with the name might be long gone. So if you are able to control and plan out the steps for problem reproduction and packet gathering, it can be helpful to begin without the nfs mount present. Then start tcpdump. Then perform the mount. Then reproduce the nfs problem. That way, you are sure to capture packets which will connect all file handles with file names.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.