Thanks for your prompt responses. Ronnie, I understood my mistake that
I was trying to set the filter on file handle fields. It worked when i
tried following filter:
nfs.procedure_v3 == 8 && nfs.fattr3.fileid == <inode no>
Sudhanshu
On Apr 5, 2005 1:40 PM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> 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
> > >
> >
>
