print-nfs prints beyond end of string about tcpdump HOT 1 CLOSED

Submitted by guy_harris

Logged In: YES
user_id=541179

"fn_printn()" takes as its third argument a "const char *",
not an "int", so "snaplen" would be the wrong argument to
pass to it. (As you're using Linux, your compiler is
probably GCC, in which case you should create a ".devel"
file in your tcpdump source directory, and re-run the
configure script; that'll cause some additional warning
flags to be used, which should cause the compiler to print a
warning about incorrect calls such as that.)

However, there's a TCHECK2() call before the fn_printn()
call, so if not all the name was captured in the request,
the TCHECK2() call should fail (jumping to "trunc:") before
fn_printn() even gets called.

It might have tripped over the fact that TTEST2() (and
macros that eventually call it, such as TCHECK2() doesn't,
in 3.7.1, handle the case where the length is so large
that "snapend - l" underflows, but that shouldn't happen
with correctly-formed NFS requests.

Nevertheless, I'd suggest trying the current CVS version
(snapshots of which can be downloaded from the tcpdump.org
site), as that particular bug is fixed in the current CVS
version, so that'd at least determine whether that was the
problem or not. (If the offending NFS request was sent to
the machine on which you're running tcpdump, the copy given
to tcpdump might well be malformed - the Linux NFS code
has been known to mangle some NFS file names "in place", for
convenience when dissecting the NFS request or reply, in
such a way that programs capturing with a capture socket,
such as tcpdump or other libpcap-based programs, see the
mangled packet, not the packet as it arrived at the
machine. Sigh....)

from tcpdump.