Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] nfs attrs

From: Guy Harris <guy@xxxxxxxxxxxx>
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.)