If you really want to find the 'inode' of a file, instead of trying
to look at the filehandle, try to find a packet that contains the
attributes for that filehandle (nfs.fh.hash) since the attribute
structure contains the fileid which should map to the inode, unless
the nfs server is insane (or it has reiserfs as the backing filesystem
:-) )
((reiserfs doesnt use inodes. weird but they apparently get very
good performance))
On Tue, 5 Apr 2005 04:07:05 -0400, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> These fields all depend on only very specific types of filehandles
> which ethereal uses heuristics to discover.
>
>
> In NFS, the filehandle is just an opaque data structure with no defined
> form.
> Its only semantic is that it is a blob of data handed out by the
> server as associated to a file object and that if the client passes it
> back in some operation such as READ/WRITE etc that the operation will
> act on the previously identified file.
>
> As such, there are no fileid or inodes associated with a filehandle.
>
>
> However, many/most/all nfs server implementations DO encode specific
> values and structures inside the filehandle to optimize the
> performance of the server (and at the same time blow any existing
> security to hell and back).
> Some of the more common known encodings of data inside a filehandle is
> known by ethereal, and ethereal will try to inspect the data of the
> filehandle to try to guess which server generated it, and then guess
> what data it supposedly contain.
>
>
> For example ethereal will try toi guess which filehandles are
> generated by some sort of netapp device and if it thinks it might be
> possibly be a netapp filehandle it will set nfs.fh.fileid.
> This field is ONLY used for filehandles that ethereal for some reason
> thinks are created by a netapp box.
>
> Same thing applies for the other two fields, they are used IFF
> ethereal thinks the filehandle was either generated by the linus
> kernel nfs server or a classic svr4 server.
>
>
>
> Conclusion: dont use these fields in filters. Filter on the real
> filehandle or preferably the filehandle hash nfs.fh.hash instead.
>
>
>
> On Mon, 4 Apr 2005 18:53:04 +0530, Sudhanshu Gupta
> <sudhanshu.gupta@xxxxxxxxx> wrote:
> > Hello,
> >
> > I am facing some problem with the ethereal display filters.
> >
> > I created a regular file in a NFS mounted file system. I found out the
> > inode no of this newly created file. I have caputred the nfs packets
> > for this creat request with tpdump. I ran ethereal on this. I don't
> > see any packet, if I set any of the following display filters:
> >
> > - nfs.procedure_v3 == 8 && nfs.fh.fileid == <inode no>
> > - nfs.procedure_v3 == 8 && nfs.fh.fn == <inode no>
> > - nfs.procedure_v3 == 8 && nfs.fh.fn.inode == <inode no>
> >
> > Please let me know what is wrong with my display filter settings.
> >
> > Thanks,
> > Sudhanshu
> >
> > _______________________________________________
> > Ethereal-users mailing list
> > Ethereal-users@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-users
> >
>
