Date: Mon, 7 Apr 2008 18:44:24 GMT From: antoine@FreeBSD.org To: olli@secnetix.de, antoine@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/105334: Error in output of tcpdump(1) Message-ID: <200804071844.m37IiOlF090439@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
Synopsis: Error in output of tcpdump(1) State-Changed-From-To: open->feedback State-Changed-By: antoine State-Changed-When: Mon Apr 7 18:35:23 UTC 2008 State-Changed-Why: >From the tcpdump man page: %%% Sun NFS (Network File System) requests and replies are printed as: src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.6709: reply ok 40 readlink "../var" sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150 In the first line, host sushi sends a transaction with id 6709 to wrl (note that the number following the src host is a transaction id, not the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a readlink (read symbolic link) on file handle (fh) 21,24/10.731657119. (If one is lucky, as in this case, the file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number.) Wrl replies `ok' with the contents of the link. In the third line, sushi asks wrl to lookup the name `xcolors' in directory file 9,74/4096.6878. Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol spec. %%% So what you see is the transaction id and not a source port. If you want to see the port you can use tcpdump -q. Do you agree that this PR can be closed? http://www.freebsd.org/cgi/query-pr.cgi?pr=105334
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804071844.m37IiOlF090439>