Date: Tue, 19 Dec 2006 21:30:45 GMT From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/105334: Error in output of tcpdump Message-ID: <200612192130.kBJLUjpB003635@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/105334; it has been noted by GNATS.
From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org>
To: Oliver Fromme <olli@lurza.secnetix.de>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: bin/105334: Error in output of tcpdump
Date: Tue, 19 Dec 2006 18:53:00 -0200
Hi Oliver,
On Mon, 27 Nov 2006 21:04:20 +0100 (CET)
Oliver Fromme <olli@lurza.secnetix.de> wrote:
> Then start the following daemons as root (in this order):
> # rpcbind
> # mountd
> # nfsd
> No options are required. Check /var/log/messages for errors.
> If you already had a mountd daemon running, you need to send
> it a SIGHUP so it wil re-read the /etc/exports file:
> # kill -HUP $(cat /var/run/mountd.pid)
>
> Now mount the exported directory to /mnt:
> # mount -t nfs -o ro 127.0.0.1:/usr/bin /mnt
>
> Use this command to watch NFS UDP traffic on localhost:
> # tcpdump -ni lo0 udp port 2049
Thanks for these easy steps. I could reproduce the problem, and discovered
that, oddly, what tcpdump prints is not the source port, it's an ID. Look:
18:20:07.299689 IP 127.0.0.1.1490240411 > 127.0.0.1.2049: 100 fsstat [|nfs]
18:20:07.299772 IP 127.0.0.1.2049 > 127.0.0.1.1490240411: reply ok 168 fsstat
[|nfs]
== src/contrib/contrib_tcpdump/print-nfs.c:420
void
nfsreq_print(register const u_char *bp, u_int length,
register const u_char *bp2)
{
...
rp = (const struct sunrpc_msg *)bp;
if (!nflag) {
snprintf(srcid, sizeof(srcid), "%u",
EXTRACT_32BITS(&rp->rm_xid));
strlcpy(dstid, "nfs", sizeof(dstid));
} else {
snprintf(srcid, sizeof(srcid), "%u",
EXTRACT_32BITS(&rp->rm_xid));
snprintf(dstid, sizeof(dstid), "%u", NFS_PORT);
}
print_nfsaddr(bp2, srcid, dstid);
...
==
The "else" branch is taken (because -n was passed to tcpdump), and in the
first snprintf you can see that "rp->rm_xid" is printed where one expects to
see source port.
A hack may workaround this, given that the header position is fixed and can
be recomputed, and then the source port can be printed instead of rm_xid. I
really don't know if this is what the author wanted, it doesn't make sense to
me to have a ID of some kind printed along with the IP address where one is
expecting the source port of the packet (POLA violation, perhaps?).
Moreover, I don't know who should tackle this PR (FreeBSD or tcpdump
developers?). :)
Sorry for the long delay to reply (Real Life Problems (tm)).
--
Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}>
Powered by FreeBSD
"Left to themselves, things tend to go from bad to worse."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612192130.kBJLUjpB003635>