On Feb 18, 2010, at 6:00 PM, Mag Gam wrote:
> This is great. Is there a filter I can use with wireshark for all the
> file/directory accesses?
Do you mean "a filter to use with tcpdump - or Wireshark, or TShark, or dumpcap, or... - when you're capturing the traffic", or "a filter to use when you've read the capture file into Wireshark"?
For the first case, if this is NFS-over-TCP, a capture filter of "port 2049" will capture NFS traffic but not other traffic. No capture filter is possible that will capture only particular types of NFS requests and replies (requests, a filter might be able to do *if* the RPC header is always the same length *and* the requests all fit in exactly one IP packet and start at the beginning of the TCP or UDP payload; replies, not possible, as replies don't include a field giving the NFS request type). If it's NFS-over-UDP, that will only capture the first fragment of a fragmented request or response.
For the second case, a display filter of "nfs" will show you only NFS traffic.
> And also, for the filehandle, is there a way to convert it into more understandable format?
What sort of format do you want? In NFS, a file handle is just an opaque blob of bytes, so, in the abstract, there *is* no more understandable format. If you happen to know what operating system the server is running, and it's one of the OSes whose file handles Wireshark understands, you can set the "Decode nfs fhandles as" preference for NFS to the type for that OS:
SVR4 - System V Release 4 systems (which mainly means "Solaris", these days)
KNFSD_LE - I think that's "Linux kernel NFS server, from a little-endian machine" (such as an x86 or x86-64 machine);
NFSD_LE - some userland Linux NFS server, little-endian?
KNFSD_NEW - some newer Linux kernel NFS server?
ONTAP_V3 - NetApp ONTAP version 3.x
ONTAP_V4 - NetApp ONTAP version 4.x (and later?)
ONTAP_GX_V3 - NetApp ONTAP GX 3.x?
and Wireshark will try to decode the file handle. That might still not be as understandable as you'd like, but there's no fix for that - file handles generally contain a numeric value that is a "file identifier" for the file, and that has nothing to do with the file's name, for example.
If the server isn't running one of those OSes, you're out of luck - unless somebody contributes code that knows about the format of the OS's file handles, Wireshark won't be able to do anything more than just show you the raw bytes.
