Using tcpdump to extract NFS RPC contents

rhel nfs tcp tcpdump

26,581

Solution 1

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.

Solution 2

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

26,581

l2mt

Updated on September 18, 2022

Comments

l2mt almost 2 years
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
- Drav Sloan almost 11 years
  
  have you tried -X which does a hexdump of the packet payload?
- l2mt almost 11 years
  
  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.
- BitsOfNix almost 11 years
  
  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.
- l2mt almost 11 years
  
  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.
- BitsOfNix almost 11 years
  
  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 almost 11 years
  
  and for NFSv3 I see file contents but no filename :S
l2mt almost 11 years

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