According to "Chris G. Demetriou" <cgd@pa.dec.com> :
> 
> If you're going to do the snooping from a NetBSD client, using
> tcpdump, I strongly suggest you apply the patch to file handle
> printing which is part of PR 4275.  Without it, the existing file
> handle printing code tends to lose ... a lot of information.  (With
> the patch, the file handle printing code spits out a bunch of hex
> digits for the file handle, rather than anything pretty.  However,
> when you're analyzing traffic oftentimes what you really want is all
> of the bits of the file handle, rather than tcpdump's
> possibly-incorrect interpretation of those bits.)
> 
I think I get the idea, presumably TCPDUMP does not interpret the file 
handle information accurately.  On the other hand, the "x" option to 
tcpdump will have the same effect as the fix, without suppressing 
TCPDUMP's bahaviour when it may be correct.  I appreciate that this 
will produce much more tedious output, but I'm not sure I'd trade the 
one for the other.

Back to the Stale NFS file handle problem, I really think there is 
something fishy going on.  The error number for the above message is
70, which seems to be the value returned at the end of the response 
packet from the Plan 9 NFS server.  I guess some digging there is 
called for.

On the other hand, I have no clue as to why NetBSD 1.2.1 and 1.3 both 
seem to have grave difficulties getting a response from the portmapper 
on the Plan 9 box, whereas 1.1 doesn't.  Any clues, or must I search 
the kernel sources for differences?

I'll report progress as I make any :-)
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.