Description of problem: # tcpdump -vvvvvv -n -s 1500 ... 16:38:57.336507 arp reply 192.83.197.1 is-at 00:0e:a6:8d:2c:a7 16:39:14.935220 IP (tos 0x0, ttl 64, id 30439, offset 0, flags [+], proto: UDP (17), length: 1500) 192.83.197.8.3796435621 > 192.83.197.1.2049: 1472 write fh 150,140/3805627648 4096 (4096) bytes @ 0 <filesync> Notice the source port it prints is 3796435621. Thats pretty amazing concidering the port numbers top out at 64k. I suspect some format string problem is being uncovered by the amd64 64-bit code. Version-Release number of selected component (if applicable): tcpdump-3.9.4-8.1 How reproducible: very Steps to Reproduce: 1. tcpdump -vvvvvv -n -s 1500 2. look for port number > 64k Actual results: Ports over 64k printed Expected results: Ports with numbers 1-64k Additional info:
Can you send me a file created with tcpdump -w, which shows the large port number?
(In reply to comment #1) > Can you send me a file created with tcpdump -w, which shows the large port number? I've only seen the large port numbers occur with nfs over udp packets. Unfortunately, tcpdumps of nfs traffic is the one thing I feel very uncomfortable posting. Looking at the code in /usr/src/redhat/BUILD/tcpdump-3.9.4/tcpdump-3.9.4/print-nfs.c nfsreply_print and nfsreq_print, it appears that the large numbers that are printed in the port-number position are not the port numbers at all but the XID (some 32-bit nfs transaction ID number). Just to make it more confusing, the "port" number printed for the server's side of the address.port is indeed the nfs port. It is only the client's side that gets the XID printed where tcpdump normally prints the port number. This is a highly confusing interface design, and will probably continue to be flagged as a bug until it is changed. It isn't a coding error though.
Ok, thanks for the analysis. But I have to close it as NOTABUG since it's documented in the man page. Output of tcpdump is protocol dependent and for NFS requests and replies the transaction id is printed.