Wireshark mailing list archives

Re: nfs attrs


From: Guy Harris <guy () alum mit edu>
Date: Thu, 18 Feb 2010 20:26:20 -0800


On Feb 18, 2010, at 8:08 PM, Mag Gam wrote:

The OS i am using is Linux.

The information I am trying to capture is, "what user is trying to
access what file/directory" using NFS or Samba. Samba is pretty easy
but NFS is very hard to figure out whats going on.

(s/Samba/SMB/; SMB is the protocol, Samba is a server for the protocol, but not the only server that exists for it - 
not surprisingly, Microsoft doesn't use it as a server for any version of Windows.)

SMB's file operations take full pathnames.

NFS file operations take file names and a file handle for the containing directory.  That makes it harder.  Wireshark 
has some ability to try to determine the full pathnames for files being referred to, based on the data it sees in 
various requests (lookup, etc.).  Make sure the

        Snoop FH to filename mappings
        Snoop full path to filenames

preferences for NFS are both turned on.

I will bite the bullet and capture NFS traffic into a file.

Is it possible to do a display filter with 'tcpdump' on CLI? I don't
want to run out of memory when trying to read my dump file.

When you're capturing to a file in binary format, with "-w", tcpdump shouldn't consume any additional memory while it's 
capturing; if it does, that's a bug.  (Neither should TShark, if you're not using the "-S" flag.)  You might run out of 
*disk space* if you capture for a very long time; as per my earlier mail, if you're capturing NFS-over-TCP traffic, 
"tcp port 2049" should mean you'll capture only NFS-over-TCP traffic, and you can further restrict the capture if 
you're only interested in the traffic between two particular hosts.  For NFS-over-UDP, it's harder, thanks to IP 
fragmentation, which is likely for NFS read and readdir replies and write requests.  If you only care what files are 
being accessed, not what's being read from or written to the files, "udp port 2049" means you'll only capture the first 
fragment, so all you're likely to lose is the data being read or written in read and write requests *and* the directory 
contents for readdir and readdirplus requests.

Those filters would be capture filters, not display filters, however.  (Note that the capture filter syntax in tcpdump 
and Wireshark/TShark/dumpcap is the same; that's because they're implemented by the same code, namely the code in 
libpcap for filtering.)
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe


Current thread: