かなり簡単な質問です...私はtcpdumpを実行し、サーバー/クライアント間のTCPパケットの内容を分析したいと思います。 「GETATTR」RPCが受信されるのを見ましたが、本当に良いです！ところで、RPCが生成されるファイルが何であるかを知りたいです。私はこれがパケットの内容にあると仮定します。 tcpdumpを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
ここ他のサイトではファイル名にマッピングできることを示しています。たぶんプラットフォームによって異なりますか？私はちょうどtcpdumpのための確実なオプションがないことを確認したいと思いました。
RH5 - カーネル 2.6.32-279.el6.x86_64 を実行しています。
答え1
あなたは見ることができますnfstraceのツールフラッグハブから：（https://github.com/epam/nfstrace）。キャプチャされたすべてのNFSv3 / NFSv4プロセスを追跡します。
答え2
さて、それで「解決方法」を見つけたようです。 NFSv3を使用してファイル名を取得することはできませんが、inodeは取得できます。
ワイヤーシャークを利用して、
編集 - >設定 - >プロトコル - > NFS - >すべてのボックスを選択し、「nfsハンドルを次にデコード：KNFSD_LE」に設定します。
救う。キャプチャとフィルタリングは、NFSプロトコルを介して行われます。
パケット検索GETATTR Reply (Call in #) Regular file mode: ???.
このzipファイルを開き、次の内容を展開します。
Network File System -> obj_attributes
値の確認ファイル番号、これはファイルのinode番号になります。
サーバーからnfs共有に移動し、
find . -inum inode
NFSv4 では、ファイル名で呼び出しを直接表示できます。
答え3
RedHat の NFS v3 実装では、ほとんどの操作に名前ではなくファイルハンドルを使用します。 Wiresharkのハンドルが表示されない場合は、見つかるまでパケットのさまざまな部分を展開し続けます。一部のパケットには宛先オブジェクトとその親ディレクトリへのハンドルが含まれているため、慎重に見てください。 NFS呼び出しでは、Wiresharkの概要「情報」行には通常、ハンドルの縮小バージョンであるハッシュ値が表示されます。問題は、ファイルハンドルが「他の情報」や問題のコンピュータへのアクセス（たとえば、他の人のパケットを分析する場合）なしでそれほど有用な情報ではないことです。
ハンドルまたはそのハッシュの以前のパケット発生を検索し、同じファイルハンドルが存在する場所を見つけて、ファイル名に関連付けることができることを願っています。たとえば、照会はファイルハンドルを含む応答を生成します。または、作成操作に応答して、作成されたばかりのオブジェクトへのハンドルが表示されます。あるいは、「readdirplus」シーケンスがあり、パケットが切り捨てられていない場合は、そこから情報を取得できます。
あるいは、もちろん、多くの場合、nfsマウントがしばらく使用され、クライアントが名前に関連付けられたハンドルを「学習」させた元の呼び出しがずっと前に消えた可能性があります。したがって、問題の再現とパケット収集の段階を制御および計画することができる場合は、nfsマウントなしで起動することが役に立ちます。その後、tcpdumpを起動します。その後、マウントしてください。その後、nfsの問題を再現します。これにより、すべてのファイルハンドルをファイル名に関連付けるパケットをキャプチャできます。