>Number:         4275
>Category:       bin
>Synopsis:       tcpdump doesn't do NFS file handles so well
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 15 00:35:03 1997
>Last-Modified:
>Originator:     Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release:        NetBSD-current as of today (10/14/97)
>Environment:
System: NetBSD brick.demetriou.com 1.2G NetBSD 1.2G (BRICK) #116: Wed Jul 16 14:03:06 PDT 1997 cgd@brick.demetriou.com:/usr/src/sys/arch/i386/compile/BRICK i386
(with a brand-new tcpdump)

>Description:
	tcpdump doesn't produce useful output when printing NFS file
	handles, at least for file handles from 4.4BSD-derived (or
	at least NetBSD and FreeBSD) NFS servers.  In particular, it
	appears to all map file handles into non-unique strings like
	"4,2/1" or "0,6/1931".  (Those are two real examples, the
	former from a FreeBSD server, the latter from a NetBSD server.)

	This makes using tcpdump output for some types of analysis
	of NFS traces pretty much impossible.

>How-To-Repeat:
	"tcpdump -vv -s 500" the traffic to/from a NetBSD or FreeBSD
	NFS server.

	Notice how file handles are printed.  For instance:

	17:17:32.653502 client.703848401 > server.nfs: 104 lookup fh 4,2/1 "utmp" (ttl 64, id 55047)
	17:17:32.654084 server.nfs > client.703848401: reply ok 236 lookup fh 4,2/1 REG 664 ids 0/45 sz 540 nlink 1 rdev 138/720991 fsid 8a000b005f nodeid b005f00000000 a/m/ctime 876869083.000000 876880032.000000 876880032.000000  post dattr: DIR 755 ids 0/0 sz 512 nlink 2 rdev 203/721014 fsid cb000b0076 nodeid b007600000000 a/m/ctime 876819857.000000 876851094.000000 876851094.000000  (ttl 64, id 26614)

	Note that the lookup fh (the directory) and the result of the lookup
	(the file) are reported to be the same.  "Wrong!"

>Fix:
	Below is a patch which simply prints out the file handle data.
	That's much more useful than incorrect, non-unique output, and
	should at least be an option, if not the default output style.

	The output from a later, modified tcpdump of the same lookup looks
	like:

	17:18:30.000049 client.29f3e253 > server.nfs: 104 lookup fh 02040000010000000c00000026b302009db37c330000000000000000 "utmp" (ttl 64, id 55727)
	17:18:30.000617 server.nfs > client.29f3e253: reply ok 236 lookup fh 02040000010000000c00000000b20200fa9a42340000000000000000 REG 664 ids 0/45 sz 540 nlink 1 rdev 138/720991 fsid 8a000b005f nodeid b005f00000000 a/m/ctime 876869083.000000 876880100.000000 876880100.000000  post dattr: DIR 755 ids 0/0 sz 512 nlink 2 rdev 203/721014 fsid cb000b0076 nodeid b007600000000 a/m/ctime 876819857.000000 876851094.000000 876851094.000000  (ttl 64, id 27171)

	Note that, in this case, the lookup fh and the returned fh are
	(correctly) different.  It's unfortunate that the output is so
	long and non-pretty, but ugly output is better than output which
	isn't correct.

*** print-nfs.c.BAK	Tue Oct 14 16:54:40 1997
--- print-nfs.c	Tue Oct 14 20:08:42 1997
***************
*** 689,694 ****
--- 689,704 ----
  static void
  nfs_printfh(register const u_int32_t *dp, const u_int len)
  {
+ #if 1
+ 	const unsigned char *cp = (const unsigned char *)dp;
+ 	int l = len;
+ 
+ 	printf(" fh ");
+ 	while (l--) {
+ 		printf("%02x%02x%02x%02x", cp[0], cp[1], cp[2], cp[3]);
+ 		cp += 4;
+ 	}
+ #else
  	my_fsid fsid;
  	ino_t ino;
  	char *sfsname = NULL;
***************
*** 713,718 ****
--- 723,729 ----
  			fsid.Fsid_dev.Major, fsid.Fsid_dev.Minor,
  			(long) ino);
  	}
+ #endif
  }
  
  /*
>Audit-Trail:
>Unformatted: