Confused tcpdump

[Dag-Erling Smørgrav]

Michael Proto <mike at jellydonut.org> writes:
> Dag-Erling Smørgrav <des at des.no> writes:
> > 15:50:42.622040 IP 10.0.0.10.871009576 > 10.0.0.4.2049: 192 lookup [|nfs]
> > 15:50:42.622386 IP 10.0.0.4.2049 > 10.0.0.10.871009576: reply ok 236 lookup [|nfs]
> >
> > I'm pretty sure 871009576 is not a valid port number...
> I've noticed this behavior since at least 4.3 as well, with the source
> port being some obscenely-high number, when examining UDP-based NFS
> traffic with tcpdump (32bit).

Somebody explained to me that this is in fact the NFS transaction ID:

       NFS Requests and Replies

       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.

DES
-- 
Dag-Erling Smørgrav - des at des.no